Oracle Cloud Infrastructure - Dokumentation

Identitätsprovider verwalten

Sie können die föderierte Anmeldung zwischen einer Identitätsdomain und einem externen Identitätsprovider einrichten. Dadurch können Benutzer sich mit vorhandenen Anmeldedaten und Kennwörtern, die vom Identitätsprovider verwaltet werden, anmelden und auf Oracle Cloud Infrastructure-Ressourcen zugreifen.

Erforderliche Policy oder Rolle

Um Identitätsdomain-Sicherheitseinstellungen und Identitätsprovider zu verwalten, benötigen Sie eine der folgenden Zugriffsberechtigungen:
  • Berechtigung als Mitglied der Administratorengruppe
  • Berechtigung der Rolle "Identitätsdomainadministrator" oder "Sicherheitsadministrator"
  • Berechtigung als Mitglied einer Gruppe, der die Berechtigung manage identity-domains erteilt wurde

Weitere Informationen zu Policys und Rollen finden Sie unter Administratorengruppe, Policy und Administratorrollen, Administratorrollen und Policys.

Identitätsprovider und Serviceprovider

Identitätsprovider und Serviceprovider.

Ein Identitätsprovider (auch als Authentifizierungsstelle bezeichnet), bietet die externe Authentifizierung für Benutzer, die sich mit den Zugangsdaten ihres externen Providers bei einer Identitätsdomain anmelden möchten. Während eine Identitätsdomain als Identitätsprovider für einen externen Serviceprovider verwendet werden kann, ist die Identitätsdomain in diesem Kontext der Serviceprovider, da sie Benutzer, die auf die Identitätsdomain zugreifen, mit einem Identitätsprovider authentifiziert. Ganz allgemein können Sie sich auch Oracle Cloud Infrastructure als Serviceprovider vorstellen, der die Services und Ressourcen bereitstellt, auf die Benutzer zugreifen möchten.

Beispiel: Ihre Organisation möchte, dass Benutzer sich mit ihren Zugangsdaten von Microsoft Active Directory Federation Services (AD FS) bei Oracle Cloud-Services anmelden und Zugriff darauf erhalten. In diesem Fall fungiert Microsoft AD FS als Identitätsprovider (IdP) und die Identitätsdomain als Serviceprovider (SP). MS AD FS authentifiziert den Benutzer und gibt ein Token mit Identitäts- und Authentifizierungsinformationen an die Identitätsdomain zurück (z.B. Benutzername und E-Mail-Adresse des Benutzers). Dieses Sicherheitstoken wird digital vom IdP signiert. Der SP verifiziert die Signatur im Token und richtet dann anhand der Identitätsinformationen eine authentifizierte Session für den Benutzer ein. Dieser Vorgang wird als föderiertes Single Sign-On bezeichnet. Dabei muss ein Benutzer Zugangsdaten in einer Domain angeben, um Zugriff auf eine andere Domain zu erhalten.

Informationen zum Föderieren einer Microsoft Active Directory-Bridge finden Sie unter Microsoft Active Directory-(AD-)Bridge einrichten.

Digitale Zertifikate

Ein digitales Zertifikat ist sozusagen ein elektronischer Pass, der einer Person, einem Computer oder einer Organisation den sicheren Austausch von Informationen über das Internet mithilfe von Public-Key-Kryptografie ermöglicht. Ein digitales Zertifikat kann als Public-Key-Zertifikat bezeichnet werden.

Wie ein Pass liefert ein digitales Zertifikat identifizierende Informationen, ist fälschungssicher und kann verifiziert werden, da es von einer offiziellen, vertrauenswürdigen Stelle ausgestellt wird. Das Zertifikat kann den Namen des Zertifikatsinhabers, eine Seriennummer, Ablaufdatumsangaben, eine Kopie des Public Keys des Zertifikatinhabers (zum Verschlüsseln von Nachrichten und Verifizieren digitaler Signaturen) sowie die digitale Signatur der ausstellenden CA enthalten, damit der Empfänger die Echtheit des Zertifikats verifizieren kann.

Um die Signaturen externer Identitätsprovider zu verifizieren, speichert der Serviceprovider Kopien der Signaturzertifikate. Wenn der Serviceprovider eine signierte Nachricht von einem Identitätsprovider empfängt, muss das Zertifikat als gültig verifiziert werden, bevor das gespeicherte Zertifikat zur Verifizierung der Signatur verwendet wird. Die Zertifikatsvalidierung umfasst die Prüfung, ob das Zertifikat abgelaufen ist. Nachdem das Zertifikat validiert wurde, wird es zur Verifizierung der Signatur in der Nachricht verwendet.

Damit dieser Vorgang erfolgreich verläuft, muss der in das Zertifikat eingebettete Public Key dem Private Key entsprechen, mit dem der Identitätsprovider die Nachricht signiert hat.

Was geschieht, wenn das Zertifikat eines Identitätsproviders abläuft?

Wenn das Signaturzertifikat eines Identitätsproviders abläuft und er sein Signaturschlüsselpaar ändert, wenn er das Zertifikat erneuert, verläuft die Signaturvalidierung nicht erfolgreich. Die Identitätsdomain kann dann keine Single Sign-On-(SSO-)Vorgänge für die Benutzer dieses Identitätsproviders abschließen. Daher sollten Sie Zertifikate von Identitätsprovidern in Kürze ablaufen, um sie zu ersetzen. Typischer Prozess:
  1. Rufen Sie das neue Signaturzertifikat vom Identitätsprovider ab. Dieses kann vom Identitätsprovider für Selfservicedownloads veröffentlicht werden. Eventuell müssen Sie sich auch an den Identitätsprovideradministrator wenden.
  2. Laden Sie das neue Signaturzertifikat in die Identitätsdomainkonfiguration für den Identitätsprovider.
  3. Wenn der Identitätsprovider außerdem das Private/Public-Key-Paar für die Signatur übertragen hat (anstatt nur ein neues Zertifikat für das vorhandene Schlüsselpaar auszustellen), müssen Sie die Konfiguration des Identitätsproviders aktualisieren, um Nachrichten mit den neuen Schlüsseln zu signieren. Auch dieser Vorgang kann per Selfservice möglich sein oder eine Koordination mit dem Identitätsprovideradministrator erfordern.
Hinweis

Wenn der Identitätsprovider über sein Signaturschlüsselpaar überträgt, verläuft SSO während des Zeitraums zwischen Schritt 2 und Schritt 3 oben nicht erfolgreich. Aus diesem Grund wird die Zertifikatsaktualisierung normalerweise zwischen dem Identitätsprovider und Identitätsdomainadministratoren koordiniert.

SAML-Just-in-Time-Provisioning

Das SAML-Just-In-Time-(JIT-)Provisioning automatisiert die Erstellung von Benutzeraccounts, wenn der Benutzer zum ersten Mal SSO ausführt und noch nicht in der Identitätsdomain vorhanden ist. Neben der automatischen Benutzererstellung ermöglicht JIT das Erteilen und Entziehen von Gruppenmitgliedschaften im Rahmen des Provisionings. JIT kann so konfiguriert werden, dass bereitgestellte Benutzer aktualisiert werden, damit die Benutzerattribute im Serviceprovider-(SP-)Speicher mit den Attributen im Identitätsprovider-Benutzerspeicher synchron gehalten werden können.

Vorteile

Vorteile von JIT:
  • Der Footprint von Benutzeraccounts in der Identitätsdomain ist auf Benutzer begrenzt, die sich tatsächlich über föderiertes SSO anmelden, und gilt nicht für alle Benutzer im IdP-Benutzerverzeichnis.
  • Geringerer Verwaltungsaufwand, da Accounts auf Anforderung im Rahmen des SSO-Prozesses erstellt werden und die Identitätsprovider- und Serviceprovider-Benutzerspeicher nicht manuell synchronisiert werden müssen.
  • Für neue Benutzer, die später zum Identitätsprovider-Benutzerspeicher hinzugefügt werden, müssen Administratoren keine entsprechenden Serviceprovideraccounts manuell erstellen (Benutzer sind immer synchron).

Funktionsweise

Es gibt vier Laufzeitabläufe für JIT-Provisioning:
Situation bei der Anmeldung: Ablauf
Der Benutzer ist im SP vorhanden, und JIT-Provisioning ist aktiviert. Normaler SSO-Ablauf.
Der Benutzer ist nicht im SP vorhanden, und JIT-Provisioning ist nicht aktiviert. Normaler SSO-Fehlerablauf.
Der Benutzer ist nicht im SP vorhanden, und die JIT-Benutzererstellung ist aktiviert. Der Benutzer wird erstellt und mit den SAML-Assertion-Attributen gefüllt, wie in der JIT-Konfiguration zugeordnet.
Der Benutzer ist im SP vorhanden, und die JIT-Aktualisierung ist aktiviert. Benutzerattributwerte werden mit den SAML-Assertion-Attributen aktualisiert, wie in der JIT-Konfiguration zugeordnet.