Obsługa wielu OIDC i dostępu nazwanego

01

1. Zalecany model

Docelowy wzorzec architektoniczny, a nie funkcja automatyczna każdej wersji: aplikacje ufają pojedynczej domenie klienta w Keycloak, która pośredniczy w tożsamościach klienta, DERS i ewentualnie partnera wdrożeniowego. Właściciel domeny, wsparcie brokera i odpowiedzialność operacyjna są potwierdzane przez konkretne wdrożenie.

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. Dlaczego centralna bramka logowania

Keycloak pełni tutaj rolę pośrednika: aplikacje znają tylko jeden zaufany punkt logowania, podczas gdy pracownicy klienta, DERS i partnera nadal logują się przy użyciu kont swojej organizacji.

• Aplikacje uwierzytelniają logowanie w jednolity sposób i nie muszą znać każdego dostawcy tożsamości osobno.
• Klient może zmienić swój system logowania domowego bez konieczności ponownego instalowania wszystkich aplikacji.
• DERS lub partnerzy korzystają z własnego, wieloskładnikowego lub bezhasłowego logowania i własnego systemu zarządzania kontami w swojej organizacji.
• Zasady konwersji grup zarządzanych na role aplikacji pozostają pod kontrolą konkretnej instalacji.
• Audyt zachowa pochodzenie tożsamości. Dwa konta z tym samym adresem e-mail nie są automatycznie uznawane za należące do tej samej osoby.

03

3. Utworzenie dostawcy tożsamości klienta

1. Zastąp adres URL wystawcy/odkrycia, identyfikator klienta, klucze tajne, dozwolone adresy URI przekierowań i reguły TLS.
2. Dopuszczaj tylko niezbędne zakresy i roszczenia: stabilny temat, nazwę wyświetlaną, ewentualnie zweryfikowany adres e-mail i zatwierdzone grupy.
3. Skonfiguruj procedurę pierwszego logowania bez możliwości automatycznego łączenia konta wyłącznie na podstawie adresu e-mail.
4. Przypisz zatwierdzone grupy do podstawowych ról aplikacji; role procesów są przypisywane zgodnie z zasadami konkretnego procesu.
5. Przetestuj logowanie, wylogowywanie, zmianę grupy, blokowanie konta i użytkowników bez dozwolonej roli.

04

4. Utwórz DERS/partnera IdP w celu zapewnienia wsparcia

1. Użyj osobnego aliasu brokera i osobnego klienta dla konkretnego środowiska klienta.
2. Zezwól tylko na nazwane konta służbowe; wyłącz konta współdzielonego wsparcia i konta administratora.
3. Wymagaj uwierzytelniania wieloskładnikowego (MFA) lub klucza dostępu u macierzystego dostawcy tożsamości (IdP) i przekaż poziom uwierzytelniania, jeśli jest on częścią umowy.
4. Wywnioskuj podejście na podstawie grupy docelowej dla konkretnego klienta i środowiska, a nie na podstawie ogólnego zatrudnienia w DERS/partnerze.
5. Zmapuj najniższą wymaganą rolę, określ limit czasu i audyt podwyższonych uprawnień.
6. Po zakończeniu interwencji należy sprawdzić usunięcie grupy, zakończenie sesji i unieważnienie tokena odświeżania.

05

5. Automatyczny cykl życia bez tworzenia konta lokalnego

• Przy pierwszym logowaniu konto może zostać automatycznie utworzone przez zaufanego wystawcę i stabilny podmiot.
• Rola jest tworzona na podstawie zarządzanego roszczenia/grupy, a nie na podstawie tekstu swobodnego lub samej domeny e-mail.
• Zmiana lub usunięcie dostawcy tożsamości źródłowej nastąpi najpóźniej w zdefiniowanym czasie sesji/tokena.
• Jeśli wymagane jest natychmiastowe usunięcie bez konieczności logowania użytkownika, należy zastosować wylogowanie za pomocą kanału zwrotnego, SCIM lub innego obsługiwanego kanału cyklu życia; samo pośrednictwo OIDC nie gwarantuje tego.
• Regularne testy pozwolą zweryfikować dezaktywację, wygaśnięcie sesji, zmianę roli i kontrolę oryginalnej tożsamości.

06

6. Co musi zawierać audyt

• wystawca i podmiot oryginalnego dostawcy tożsamości jako niezmienna para
• wewnętrzny identyfikator użytkownika, nazwa wyświetlana i organizacja
• grupa źródłowa/roszczenie i wynikająca z tego rola aplikacji
• czas logowania, poziom uwierzytelnienia i identyfikator sesji
• każde zwiększenie autoryzacji, jego powód, zatwierdzenie i wygaśnięcie
• działania w procesie pod określoną tożsamością, a nie pod kontem integracyjnym

07

7. Test akceptacyjny

1. Użytkownik klienta mający odpowiednią grupę loguje się i widzi tylko swój zakres.
2. Użytkownik klienta niemający grupy może się zalogować, ale nie otrzyma uprawnień do procesu lub zgodnie z polityką zostanie mu odmówiony dostęp.
3. Wyznaczony pracownik DERS/partnera otrzyma wyłącznie zakres obsługiwany przez określone środowisko.
4. Drugi pracownik bez specjalnej grupy docelowej nie uzyska dostępu.
5. Usunięcie grupy spowoduje utratę dostępu w zadeklarowanym czasie.
6. Audyt pozwoli na odróżnienie dwóch osób o tym samym imieniu i nazwisku lub adresie e-mail od różnych wystawców.