Více OIDC a jmenovitý přístup podpory

01

1. Doporučený model

Cílový architektonický vzor, nikoli automatická vlastnost každého release: aplikace důvěřují jednomu zákaznickému realm v Keycloaku, který brokeruje identity zákazníka, DERS a případně implementačního partnera. Vlastníka realm, podporu brokeru a provozní odpovědnost potvrzuje konkrétní nasazení.

Aplikace SIFYBOX
  issuer: https://<KEYCLOAK_FQDN>/realms/<CUSTOMER_REALM>
  client: <SIFYBOX_CLIENT_ID>

Keycloak — broker identity
  1. customer-idp
     issuer: https://<CUSTOMER_IDP>/...
     uživatelé: zaměstnanci zákazníka

  2. support-idp
     issuer: https://<DERS_OR_PARTNER_IDP>/...
     uživatelé: jmenovití pracovníci podpory

Jednoznačný auditní klíč
  external_identity = <issuer> + "|" + <subject>

Autorizace
  skupina/claim z domovského IdP
    -> mapper v Keycloaku
    -> omezená aplikační role
    -> procesní oprávnění v konkrétní instalaci

02

2. Proč centrální přihlašovací brána

Keycloak zde funguje jako prostředník: aplikace znají jen jeden důvěryhodný přihlašovací bod, zatímco zaměstnanci zákazníka, DERS i partnera se dál hlásí účtem své vlastní organizace.

• Aplikace ověřují přihlášení jednotným způsobem a nemusejí zvlášť znát každého poskytovatele identity.
• Zákazník může změnit svůj domovský přihlašovací systém bez přestavby všech aplikací.
• DERS nebo partner používá ve své organizaci vlastní vícefaktorové či bezheslové přihlášení a vlastní správu účtů.
• Pravidla pro převod řízených skupin na aplikační role zůstávají pod kontrolou konkrétní instalace.
• Audit zachová původ identity. Dva účty se stejným e-mailem se automaticky nepovažují za jednoho člověka.

03

3. Založení zákaznického IdP

1. Vyměnit issuer/discovery URL, client ID, secret nebo klíče, povolené redirect URI a pravidla TLS.
2. Povolit jen nutné scopes a claims: stabilní subject, zobrazované jméno, případně ověřený e-mail a schválené skupiny.
3. Nastavit first-login flow bez možnosti samovolně propojit účet jen podle e-mailu.
4. Namapovat schválené skupiny na základní aplikační role; procesní role se přidělují podle pravidel konkrétního procesu.
5. Otestovat přihlášení, odhlášení, změnu skupiny, blokaci účtu a uživatele bez povolené role.

04

4. Založení DERS/partner IdP pro podporu

1. Použít samostatný broker alias a samostatný klient pro konkrétní zákaznické prostředí.
2. Povolit pouze jmenovité pracovní účty; zakázat sdílené účty typu support nebo admin.
3. Vyžadovat MFA nebo passkey v domovském IdP a předat úroveň autentizace, pokud je součástí kontraktu.
4. Přístup odvodit z účelové skupiny pro konkrétního zákazníka a prostředí, ne z obecného zaměstnání u DERS/partnera.
5. Mapovat nejnižší potřebnou roli; zvýšené oprávnění časově omezit a auditovat.
6. Po skončení zásahu ověřit odebrání skupiny, ukončení relace a zneplatnění refresh tokenu.

05

5. Automatický životní cyklus bez lokálního zakládání účtů

• První přihlášení může účet vytvořit automaticky z důvěryhodného issueru a stabilního subjectu.
• Role vzniká z řízeného claimu/skupiny; ne z volného textu nebo e-mailové domény samotné.
• Změna nebo odebrání ve zdrojovém IdP se projeví nejpozději po definované době relace/tokenu.
• Pokud je požadováno okamžité odebrání bez přihlášení uživatele, doplňte back-channel logout, SCIM nebo jiný podporovaný lifecycle kanál; samotné OIDC brokerování to nezaručuje.
• Pravidelný test ověří deaktivaci, expiraci relace, změnu role a audit původní identity.

06

6. Co musí být v auditu

• issuer a subject původního IdP jako neměnná dvojice
• interní identifikátor uživatele, zobrazované jméno a organizace
• zdrojová skupina/claim a výsledná aplikační role
• čas přihlášení, úroveň autentizace a identifikátor relace
• každé zvýšení oprávnění, jeho důvod, schválení a konec platnosti
• akce v procesu pod jmenovitou identitou, nikoli pod účtem integrace

07

7. Akceptační test

1. Zákaznický uživatel se správnou skupinou se přihlásí a vidí jen svůj rozsah.
2. Zákaznický uživatel bez skupiny se přihlásit může, ale nedostane procesní oprávnění nebo je odmítnut podle politiky.
3. Jmenovitý pracovník DERS/partnera získá jen podporovaný rozsah konkrétního prostředí.
4. Druhý pracovník bez účelové skupiny přístup nezíská.
5. Odebrání skupiny zneplatní přístup v deklarovaném čase.
6. Audit rozliší dva lidi se stejným jménem nebo e-mailem z různých issuerů.