Unterstützung für mehrere OIDC- und benannte Zugriffe

01

1. Empfohlenes Modell

Das angestrebte Architekturmuster ist keine automatische Funktion jeder Version: Anwendungen vertrauen einem einzigen Kundenbereich in Keycloak, der die Identitäten des Kunden, des DERS und gegebenenfalls des Implementierungspartners verwaltet. Bereichsinhaber, Broker-Support und operative Verantwortung werden durch die jeweilige Bereitstellung festgelegt.

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. Warum ein zentrales Anmelde-Gateway?

Keycloak fungiert hier als Vermittler: Anwendungen kennen nur einen vertrauenswürdigen Anmeldepunkt, während sich Mitarbeiter des Kunden, von DERS und des Partners weiterhin mit dem Konto ihrer eigenen Organisation anmelden.

• Anwendungen authentifizieren Anmeldungen auf einheitliche Weise und müssen nicht jeden Identitätsanbieter separat kennen.
• Ein Kunde kann sein Heim-Login-System ändern, ohne alle Anwendungen neu aufbauen zu müssen.
• DERS oder ein Partner verwendet innerhalb seiner Organisation ein eigenes Multi-Faktor- oder passwortloses Anmeldeverfahren sowie eine eigene Kontoverwaltung.
• Die Regeln für die Umwandlung verwalteter Gruppen in Anwendungsrollen unterliegen weiterhin der Kontrolle der jeweiligen Installation.
• Die Prüfung gewährleistet die Wahrung der Identität. Zwei Konten mit derselben E-Mail-Adresse werden nicht automatisch als dieselbe Person betrachtet.

03

3. Einrichtung eines Kunden-IdP

1. Ersetzen Sie die Aussteller-/Discovery-URL, die Client-ID, das Geheimnis oder die Schlüssel, die zulässigen Umleitungs-URIs und die TLS-Regeln.
2. Erlauben Sie nur die notwendigen Berechtigungen und Ansprüche: stabiles Subjekt, Anzeigename, gegebenenfalls verifizierte E-Mail-Adresse und genehmigte Gruppen.
3. Richten Sie einen Erstanmeldungsprozess ein, der keine automatische Kontoverknüpfung ausschließlich anhand der E-Mail-Adresse ermöglicht.
4. Genehmigte Gruppen werden grundlegenden Anwendungsrollen zugeordnet; Prozessrollen werden gemäß den Regeln des jeweiligen Prozesses zugewiesen.
5. Testen von Login, Logout, Gruppenwechsel, Kontosperrung und Benutzern ohne zulässige Rolle.

04

4. Einrichtung eines DERS/Partner-IdP zur Unterstützung

1. Verwenden Sie für eine spezifische Kundenumgebung einen separaten Broker-Alias ​​und einen separaten Client.
2. Nur namentlich genannte Arbeitskonten zulassen; gemeinsam genutzte Support- oder Administratorkonten deaktivieren.
3. Verlangen Sie MFA oder Passkey im Heim-IdP und bestehen Sie die Authentifizierungsstufe, wenn dies Teil des Vertrags ist.
4. Leiten Sie den Ansatz aus der Zweckgruppe für den jeweiligen Kunden und das jeweilige Umfeld ab, nicht aus der allgemeinen Beschäftigung bei DERS/Partner.
5. Ermitteln Sie die niedrigste erforderliche Rolle; legen Sie ein Zeitlimit fest und prüfen Sie erhöhte Berechtigungen.
6. Nach Abschluss des Eingriffs überprüfen Sie die Entfernung der Gruppe, die Beendigung der Sitzung und die Ungültigmachung des Aktualisierungstokens.

05

5. Automatischer Lebenszyklus ohne Erstellung eines lokalen Kontos.

• Beim ersten Login kann automatisch ein Konto von einem vertrauenswürdigen Aussteller und einem stabilen Subjekt erstellt werden.
• Die Rolle wird aus einem verwalteten Anspruch/einer Gruppe erstellt; nicht aus Freitext oder der E-Mail-Domäne selbst.
• Eine Änderung oder Entfernung des Quell-IdP wird spätestens zum Zeitpunkt der definierten Sitzungs-/Token-Zeit wirksam.
• Falls eine sofortige Entfernung ohne Benutzeranmeldung erforderlich ist, ergänzen Sie diese durch einen Backchannel-Logout, SCIM oder einen anderen unterstützten Lifecycle-Kanal; die alleinige Vermittlung über OIDC gewährleistet dies nicht.
• Ein regelmäßiger Test überprüft die Deaktivierung, den Ablauf der Sitzung, den Rollenwechsel und die ursprüngliche Identität.

06

6. Was muss im Audit enthalten sein?

• Aussteller und Subjekt des ursprünglichen IdP als unveränderliches Paar
• interne Benutzerkennung, Anzeigename und Organisation
• Quellgruppe/Anspruch und daraus resultierende Anwendungsrolle
• Anmeldezeitpunkt, Authentifizierungsstufe und Sitzungskennung
• jede Erhöhung der Berechtigung, deren Grund, Genehmigung und Ablaufdatum
• Aktionen im Prozess unter einer benannten Identität, nicht unter einem Integrationskonto

07

7. Abnahmetest

1. Ein Kunde mit der richtigen Gruppenzugehörigkeit meldet sich an und sieht nur seinen eigenen Bereich.
2. Ein Kunde ohne Gruppenzugehörigkeit kann sich zwar anmelden, erhält aber keine Prozessberechtigungen oder wird gemäß den Richtlinien abgewiesen.
3. Ein namentlich genannter DERS/Partner-Mitarbeiter erhält nur den unterstützten Leistungsumfang einer bestimmten Umgebung.
4. Ein zweiter Mitarbeiter ohne Zugehörigkeit zu einer speziellen Zweckgruppe erhält keinen Zugang.
5. Das Entfernen einer Gruppe führt zum Verlust des Zugriffs zum angegebenen Zeitpunkt.
6. Im Rahmen der Prüfung werden zwei Personen mit gleichem Namen oder gleicher E-Mail-Adresse von verschiedenen Ausstellern unterschieden.