Föderationsprotokolle und Bereitstellung

OIDC, OAuth und PKCE

Registrierte OIDC-Clients verwenden Browserautorisierung, Kontenauswahl, Zustimmung und Bedingungen, sofern eingerichtet. Geräteautorisierung ist eine eigene Schnittstelle und ersetzt keine Clientregistrierung. PKCE und höhere Assurance hängen von Client- und Mandantenrichtlinie ab. PAR, Private-Key-JWT, mTLS, DPoP und FAPI-Profile sind bedingt; ihr Vorhandensein im Quellcode bedeutet nicht, dass sie aktiviert sind.

1. Registrieren Sie für den Client den genauen Aussteller, Redirect und die Antwortkonfiguration.
2. Schließen Sie Zustimmung und Kontenauswahl ab und prüfen Sie Identität und Audience.
3. Bestätigen Sie PKCE oder Assurance in der Richtlinie; schwächen Sie die Prüfung bei einer Ablehnung nicht ab.

SAML und Remote-Abmeldung

SAML-Routen für Service- und Identity-Provider stellen Metadaten und browserbasierte Assertion-Abläufe bereit. Konfigurieren Sie die Verbindung über die SAML-Verwaltung. Prüfen Sie mit dem Partner Aussteller, Audience, Antwortziel, Signatur und Zeitbedingungen. Abmeldung ist getrennt: Ein lokaler Widerruf beweist nicht, dass jede Sitzung oder jedes Cookie des Dienstanbieters gelöscht wurde.

1. Vergleichen Sie Verbindungsmetadaten, Signaturschlüssel und Endpunkte mit den Partnerdaten.
2. Testen Sie eine signierte Assertion und prüfen Sie Mandant, Subject, Mitgliedschaft und Gültigkeit.
3. Nutzen Sie unterstützte Abmeldefunktionen und unterscheiden Sie lokalen Widerruf von bestätigter Remote-Abmeldung.

SCIM und Verzeichnissynchronisierung

Bereitstellung ist von interaktiver Föderation getrennt. SCIM-Schema und Abgleich ergänzen Verzeichnisconnectoren mit registriertem kundenbetriebenem Agenten. Importe erhalten Mandantenherkunft und stellen Konflikte in Quarantäne; eine E-Mail-Adresse allein verknüpft keine Konten. Der Server liefert keine Kunden-Agentensoftware mit.

1. Registrieren Sie das Mandantenziel und ordnen Sie unterstützte Attribute und unveränderliche Identitätskennungen zu.
2. Führen Sie eine kontrollierte Synchronisierung aus und prüfen Sie Ergebnisse und Quarantänen im Mandantenablauf.
3. Stellen Sie den kompatiblen Agenten separat bereit und registrieren Sie ihn, bevor Sie Connectorarbeit einreihen.

CAS, WS-Federation und RADIUS

CAS erfordert eine ausdrückliche Aktivierung. WS-Federation und WS-Trust bleiben deaktiviert, sofern sie nicht durch zulässige Registrierung oder Richtlinie aktiviert wurden; Prüfungen für Realm, Audience, Antwort, Mitgliedschaft, Signatur und Ablauf bleiben verpflichtend. RADIUS nutzt einen optionalen signierten Agenten und keinen Website-Listener. Die gepflegte Referenz bevorzugt RADIUS/1.1 über TLS oder DTLS; älteres UDP ist nur für private Netzwerke vorgesehen.

1. Prüfen Sie vor CAS- oder WS-Federation-Tests Aktivierung und Clientregistrierung.
2. Bestätigen Sie für RADIUS Kundenagent, Mandantenconnector und zulässigen Transport.
3. Klären Sie fehlende Aktivierung oder Registrierung, statt zum Umgehen der Richtlinie das Protokoll zu wechseln.

Registrierung und Zugangsdaten

Eine Clientregistrierung muss im zuständigen Mandanten und in der zugehörigen Anwendung bleiben. Hinweise zu dynamischer Registrierung, Private-Key-JWT, mTLS und FAPI beschreiben bedingte Kontrakte und keine allgemeine Aktivierung. Belassen Sie private Schlüssel bei ihren Eigentümern und rotieren oder widerrufen Sie Zugangsdaten über die passende Verwaltung. Agentenschlüssel sind keine OAuth-Clientzugangsdaten.

1. Erfassen Sie Eigentümer, Mandant, Redirect oder Metadaten, Bereiche und Zugangsdart.
2. Speichern Sie ausgegebene Geheimnisse geschützt und rotieren oder widerrufen Sie sie über die Verwaltung.
3. Erzeugen Sie bei Agentenregistrierung den privaten Schlüssel kundenseitig und übermitteln Sie dessen CSR.

Kontrakt und Fehlerbehebung

Unter /api/auth/management/openapi.json finden Sie aktuelle Verwaltungsvorgänge, Felder und Sicherheitsanforderungen. Gepflegte Protokollnotizen beschreiben spezielle Connector- und Assurance-Abläufe. Häufige Fehler sind falscher Mandant, nicht registrierter Redirect, veraltete Metadaten oder Zertifikate, deaktiviertes Profil, ungültige Signatur, SCIM-Quarantäne oder widerrufener Agent. Beheben Sie die passende Vertrauensgrenze, statt Prüfungen abzuschalten.

1. Prüfen Sie OpenAPI-Schema und Sicherheitsanforderungen des Vorgangs.
2. Vergleichen Sie sichere Fehlerdetails und registrierte Werte mit aktuellen Anbietermetadaten.
3. Testen Sie den Ablauf erneut und bestätigen Sie Identität oder Synchronisierungsstatus vor dem Rollout.

Häufig gestellte Fragen

Verwandte Seiten

• Single Sign-on und Identitäten
• SSO-Verwaltung
• Identitätsgovernance und privilegierter Zugriff
• Privater Anwendungszugriff