OpenID Connect-SSO in der angepassten Anwendung konfigurieren

Online bearbeiten

Verwenden Sie OpenID Connect für Single Sign-on, damit Anwendungen die Identität ihrer Benutzer basierend auf der von Verifydurchgeführten Authentifizierung überprüfen können. Benutzer müssen sich nicht für einen Account bei der Zielanwendung anmelden. Die Benutzer werden zur Anmeldung an Verify umgeleitet. Verify überprüft die Identitäten der Benutzer, sendet die Informationen über ein ID-Token und bestätigt der Relying Party , dass die Benutzer berechtigt sind, auf die Ressource zuzugreifen und sie zu verwenden. Diese Anwendung verwendet den OpenID Connect-Provider mit dem Erkennungsendpunkt https://<tenant-host>/oidc/endpoint/default/.well-known/openid-configuration.

Vorbereitende Schritte

Hinweis: Eine Alternative zu dieser Aufgabe finden Sie unter Dynamische Client-Registrierung.
  • Zur Ausführung dieser Task müssen Sie über Verwaltungsberechtigung verfügen.
  • Öffnen Sie mindestens zwei Browserfenster, um die Konfiguration durchzuführen. Eine für die Verify -Administrationskonsole und die andere für die Administrationskonsole der Zielanwendung.
    • Melden Sie sich an der IBM® Verify -Administrationskonsole als Administrator an.
    • Melden Sie sich bei der Verwaltungskonsole der Zielanwendung mit Ihrem Administratoraccount an.
  • Sie müssen die Basisinformationen für die Anwendungsinstanz auf der Registerkarte Allgemein einrichten. Siehe „Grundlegende Anwendungsdetails festlegen “.

Informationen zu dieser Task

Vordefinierte Verify -Anwendungsvorlagen verfügen nicht über die Anmeldeoption OpenID Connect . Verwenden Sie die Vorlage „Benutzerdefinierte Anwendung“, um eine Anwendung so zu konfigurieren, dass sie als OpenID Connect-Vertrauende Partei oder Client-Anwendung fungiert, die die Benutzerauthentifizierung an Verifydelegiert.

Konfigurieren Sie Verify und die Relying Party für die Kommunikation miteinander. Um die einmalige Anmeldung mit OpenID Connect zu aktivieren, müssen Sie Folgendes bereitstellen:
  • Verify mit bestimmten Daten von der Relying Party.
  • Die Relying Party mit bestimmten Daten aus Verify.

Sie können IBM Verify Access und mobile Anwendungen als OpenID Connect Relying Partyskonfigurieren.

Vorgehensweise

  1. Navigieren Sie zur Registerkarte Anmelden .
  2. Wählen Sie unter Anmeldemethode OpenID Connect 1.0aus.
  3. Geben Sie Verify grundlegende Informationen zur Relying Partyan.
    Feld Beschreibung
    Anwendungs-URL

    Es ist die Single-Sign-On-Initialisierung URL, die verwendet wird, um sich bei OpenID Verbinden vertrauende Partei anzumelden.

    Die Anwendung verwendet URL, um Verify nach dem ID-Token zu fragen, das die Benutzerdetails enthält.

    Wenn Benutzer über URL auf die Anwendung zugreifen, werden sie zur Authentifizierung an Verify weitergeleitet.

    Sie können diese Informationen von der Relying Party abrufen, wenn Sie einen Berechtigungsprovider oder OpenID Connect-Provider an der Site der Relying Party konfigurieren.

    Typen der Berechtigungserteilung

    Sie gibt den Mechanismus an, den die Relying Party verwenden kann, um das ID-Token aus Verifyabzurufen.

    Verify unterstützt die folgenden Erteilungstypen:
    • Berechtigungscode
      Hinweis: Der Berechtigungscode ist als Standardberechtigungserteilungstyp vorausgewählt, wobei PKCE ebenfalls standardmäßig ausgewählt ist.
    • Implizit
    • Geräteablauf
      Hinweis: Bei Auswahl von 'Geräteablauf' können Sie auch einen QR-Code generieren.
    • Kontextbasierte Berechtigung
    • JWT-Träger
      Hinweis: Wenn Sie den JWT-Träger auswählen, haben Sie die Möglichkeit, JWKS URI, JWT bearer user identification und JWT bearer default identity sourcezu konfigurieren. Weitere Informationen zur Verwendung des JWT-Bearer-Grant-Typs finden Sie unter Grant-Typen.
    • Jede Kombination aus 'Berechtigungscode', 'Implizit, 'Geräteablauf' und 'ROPC'.

    Sie müssen mindestens einen Erteilungstyp auswählen. Wenn ROPC der einzige ausgewählte Erteilungstyp ist, wird der Abschnitt Zugriffsrichtlinien nicht angezeigt. Unter „Förderungsarten“ finden Sie einen schnellen Vergleich der unterstützten Förderungsarten und können festlegen, welche Förderungsart für den Antrag eingestellt werden soll.
    Client ID

    Dies ist die eindeutige öffentliche ID, die der Clientanwendungzugeordnet ist. Dies ist die OpenID Connect -Relying-Party. Der Berechtigungsserver verwendet diese Informationen, um die Relying Party und die Berechtigungsanforderung zu identifizieren.

    Diese Informationen werden automatisch generiert, wenn Sie die angepasste OpenID Connect -Anwendung speichern. Sie müssen diese Informationen der Relying Party bereitstellen, wenn Sie Verify als OpenID Connect-Provider in der Administrationskonsole der Anwendung konfigurieren.

    Die Relying Party verwendet die Client-ID bei jeder Anforderung eines Zugriffstokens.
    Geheimer Kubernetes-Schlüssel Die YAML-Datei für geheime Kubernetes-Schlüssel wird für die Verbindung zu Red Hat OpenShift verwendet. Sie müssen die YAML-Datei für geheime Kubernetes-Schlüssel herunterladen, um die Metadaten abzurufen.
    Öffentlicher Client (kein geheimer Clientschlüssel)

    Gibt an, dass der Client über keinen geheimen Schlüssel verfügt, der von der Anwendung zur Verfügung gestellt werden muss.

    Hinweis: Bei Auswahl dieser Option wird das Feld Geheimer Clientschlüssel ausgeblendet und die folgenden Algorithmen werden aus den Optionen für Signaturalgorithmus entfernt:
    • HS256
    • HS384
    • HS512

    Generieren Sie einen geheimen Clientschlüssel nur, wenn der Clienttyp vertraulich ist. Die Client-ID und der geheime Schlüssel sind bei vertraulichen Clients sicher und diese Berechtigungsnachweise werden nicht berechtigten Parteien nicht angezeigt.

    Ein geheimer Clientschlüssel darf nur der Clientanwendung und dem Berechtigungsserver bekannt sein.
    Clientschlüssel

    Diese Daten werden zusammen mit der Client-ID zur Authentifizierung der Relying Party und für den Austausch eines Berechtigungscodes gegen ein ID-Token verwendet.

    Diese Informationen werden automatisch generiert, wenn Sie die angepasste OpenID Connect -Anwendung speichern. Sie müssen diese Informationen der Relying Party bereitstellen, wenn Sie Verify als OpenID Connect-Provider in der Administrationskonsole der Anwendung konfigurieren.
    Clientauthentifizierungsmethode

    Gibt die Authentifizierungsmethode für Endpunkte (z. B. Tokenendpunkt) an, die die Clientauthentifizierung erfordern.

    Verify unterstützt die folgenden Clientauthentifizierungsmethoden:
    • Standard
    • Geheimer Clientschlüssel - Basis
    • Geheimer Clientschlüssel - POST
    • Geheimer Clientschlüssel - JWT
    • Privater Schlüssel - JWT

    Wird 'Standard' übernommen, sind 'Geheimer Clientschlüssel - Basis' und 'Geheimer Clientschlüssel - POST' zulässig. Falls von der Relying Party unterstützt, verwenden Sie 'Privater Schlüssel - JWT' als Konfiguration.
    Clientzusicherungs-JTI validieren

    Gibt an, ob der JTI im Clientzusicherungs-JWT bezüglich einmaliger Verwendung validiert wird. Diese Option wird nur angezeigt, wenn die Clientauthentifizierungsmethode 'Geheimer Clientschlüssel - JWT' oder 'Privater Schlüssel - JWT' ausgewählt ist.
    Zulässige Signaturprüfungsschlüssel

    Die Signaturprüfungsschlüssel-IDs, die verwendet werden können, um das Clientzusicherungs-JWT zu verifizieren. Diese Option wird nur angezeigt, wenn die Clientauthentifizierungsmethode 'Privater Schlüssel - JWT' ausgewählt ist.
    PKCE-Verifizierung erforderlich PKCE dient zum Mindern von Attacken zum Abfangen von Berechtigungscodes. Es erfordert eine Codeanforderung, bevor der Berechtigungscodefluss fortgesetzt werden kann. Diese Option wird nur angezeigt, wenn der Berechtigungscodeerteilungsablauf ausgewählt ist.
    Umleitungs-URIs

    Es handelt sich um URL, die Adresse, an die Verify seine Authentifizierungsantwort an die vertrauende Partei sendet.

    Benutzer werden zu URL weitergeleitet, nachdem sie von Verify authentifiziert und autorisiert wurden.

    Sie müssen mindestens einen URI angeben. Wenn der Callback-URI die Domäne der Anwendung ist, kann es sich um die Domäne des Tenants handeln.
    Hinweis: Die Domäne kann einen Platzhalterwert haben. Obwohl Platzhalterzeichen im URI-Pfad nicht unterstützt werden, ist das Zeichen "*" ein gültiges URI-Pfadzeichen und wird als Literalzeichenfolge behandelt.

    Sie können maximal 400 URIs hinzufügen.

    Sie können diese Informationen von der Relying Party abrufen, wenn Sie einen Berechtigungsprovider oder OpenID Connect-Provider an der Site der Relying Party konfigurieren.
    JWKS-URI Der URI, an dem die Relying Party ihren öffentlichen Schlüssel im JSON Web Key-Format (JWKS-Format) publiziert. Dieser URI wird für die JWT-Signaturprüfung verwendet. Das System kann einen JWKS-URI, der nicht erreichbar ist oder nicht reagiert, zurückweisen. Das System kann die JWKS-URL auch zurückweisen, wenn das JWKS zu groß ist. Wenn die Relying Party keinen JWKS-URI publiziert, kann dem System ein öffentlicher Schlüssel in Form eines X509-Zertifikats hinzugefügt werden. Siehe Zertifikate verwalten. Der Anzeigename, der dem öffentlichen Zertifikat zugeordnet ist, ist der Wert des Headers für die Schlüssel-ID (kid = key id) des JWT.
    Benutzer-ID des JWT-Trägers

    Nur für den Erteilungstyp 'JWT-Träger' verfügbar.

    		 Diese Konfiguration gibt dem System an, wie das JWT-Trägersubjekt (sub) zu interpretieren ist, um den Benutzer zu identifizieren, der diesem JWT-Trägertoken zugeordnet ist. Das untergeordnete Element kann User ID, Username oder External ID sein.
    Standardidentitätsquelle des JWT-Trägers

    Nur für den Erteilungstyp 'JWT-Träger' verfügbar.

    		 Wenn das JWT das Realm nicht angibt, ist dies das Standardidentitätsquellenrealm, zu dem der durch das Subjekt (sub) angegebene Benutzer gehört. Wenn für die Option JWT bearer user identification der Wert User ID festgelegt wurde, ist diese Einstellung nicht anwendbar.
    Wenn Sie eine vorhandene Anwendung bearbeiten, können Sie die folgenden Optionen für den geheimen Clientschlüssel verwenden:
    • Wählen Sie Anzeigen aus, um den geheimen Clientschlüssel anzuzeigen.
    • Wählen Sie Ausblenden aus, um den geheimen Clientschlüssel auszublenden.
    • Wählen Sie, um die Client-ID oder den Kopieren geheimen Schlüssel in die Zwischenablage zu kopieren.
    • Wählen Sie Liste aus, um gedrehte Client-Geheimnisse anzuzeigen.
      • Wählen Sie ein oder mehrere rotierte Client-Geheimnisse aus der Liste aus, und klicken Sie auf Löschen, um sie zu löschen.
    • Wählen Sie Neu generieren aus, um einen neuen geheimen Clientschlüssel zu generieren. Verwenden Sie diese Option, wenn Sie vermuten, dass die Geheimhaltung des geheimen Clientschlüssels nicht mehr gewährleistet ist. Wenn Sie den geheimen Clientschlüssel nicht neu generieren, müssen Sie den geheimen Clientschlüssel in allen OAuth-Clients für die Anwendung aktualisieren.
      • Aktivieren Sie das Kontrollkästchen für Aktuelles Geheimnis beibehalten, um das aktuelle Client-Geheimnis in die Liste der rotierenden Client-Geheimnisse aufzunehmen.
      • Wenn das Kontrollkästchen Aktuelles Geheimnis beibehalten aktiviert ist, wählen Sie die Beschreibung des Client-Geheimnisses und die Ablaufzeit (in Browser-Lokalzeit). Wenn keine Ablaufzeit ausgewählt wird, gilt die in den Anwendungseinstellungen festgelegte Lebensdauer des rotierenden Geheimnisses des Mandanten.
      • Rotierte Client-Geheimnisse werden gehasht und können nicht mehr im Klartext abgerufen werden, aber sie können noch bis zum gewählten Ablaufdatum verwendet werden.
      • Nach der Bestätigung wird das Kundengeheimnis sofort gedreht. Das neue Kundengeheimnis wird auf dem Bildschirm angezeigt.
  4. Konfigurieren Sie den Ablauf des Zugriffstokens und des Aktualisierungstokens, um die Dauer des unbefugten Zugriffs zu begrenzen, wenn diese Tokens gestohlen werden.

    Das Zugriffstoken wird verwendet, um die Berechtigung zum Zugriff auf die geschützte Ressource zu erteilen. Nachdem das Zugriffstoken abgelaufen ist, wird die Berechtigung entzogen.

    Tabelle 1. Token-Einstellungen
    Feld Beschreibung
    Ablauf des Zugriffstokens (Sek.)

    Legt die Dauer (angegeben in Sekunden) fest, nach der das Zugriffstoken abläuft.

    Legen Sie den Ablauf des Zugriffstokens fest, um die Zeit zu begrenzen, die ein Angreifer mit dem gestohlenen Token auf die Ressource zugreifen kann, wenn die Sicherheit der Clientanwendung beeinträchtigt ist.

    Es sind nur positive ganze Zahlen zulässig.

    Der Standardwert ist 7200 Sekunden. Der zulässige Mindestwert ist 1 Sekunde und der Maximalwert 2147483647 Sekunden.
    Format des Zugriffstokens Gibt an, ob das Zugriffstoken als nicht transparente Zeichenfolge erzeugt wird. Dies ist dieDefaultoder im JWT-Format.
    Zielgruppen Gibt die Ziele an, die die Empfänger des Tokens sind. Diese Werte werden in der aud-Anforderung für auf der Basis von JWT formatierte Token und in den Introspektionsnutzdaten als einzelne Zeichenfolge oder als Array von Zeichenfolgen aufgelistet.
    Zuordnung der Introspektionsattribute Diese Attributzuordnungsliste wird verwendet, um Ansprüche in die Introspektionsnutzdaten und das Zugriffstoken im JWT-Format einzuschließen.
    Attributname Der Name des Attributs, das die Relying Party verwendet und von Verifyerfordert. Die folgenden Attributnamen können nicht verwendet werden: aud, exp, groupIds, groupUids, at_hash, c_hash, rt_hash, s_hash, iat, iss, nonce, sub, client_id, grant_id, grant_type und scope.
    Attribute

    Listet alle Attributquellen auf, die Sie für jeden Typ unter „Verzeichnis > Attribute“ definiert haben.

    Der Wert Ihrer ausgewählten Attributquelle wird als der Attributwert für den definierten Attributnamen der Relying Party im ID-Token zugeordnet.
    Aktualisierungstoken generieren

    Gibt an, ob die Clientanwendung ein Aktualisierungstoken anfordern und verwenden kann, um ein neues Zugriffstoken vom Berechtigungsserver des OpenID Connect -Identitätsprovidersabzurufen.

    Verwenden Sie diese Option nur dann, wenn die Anwendung beabsichtigt, das Zugriffstoken für die Ausführung von Operationen mit Verify -APIs zu verwenden.

    Ein neues Zugriffstoken muss nur angefordert werden, wenn das vorherige abgelaufen ist.

    Diese Option ist nicht zutreffend, wenn "Implizit" als Erteilungstyp ausgewählt wurde.
    Ablauf des Aktualisierungstokens (Sek.)

    Legt die Dauer (angegeben in Sekunden) fest, nach der das Aktualisierungstoken abläuft. Diese Einstellung legt fest, wie oft sich der Benutzer erneut authentifizieren kann.

    Legen Sie den Ablauf des Aktualisierungstokens fest, um sicherzustellen, dass der Benutzer nach einiger Zeit erneut versucht, die vollständige SSO-Operation für Verify auszuführen.

    Diese Option wird nur angezeigt, wenn Aktualisierungstoken generieren aktiviert wurde.

    Ein Aktualisierungstoken wird verwendet, um ein neues Zugriffstoken abzurufen, um weiterhin auf die geschützte Ressource zugreifen zu können.

    Es sind nur positive ganze Zahlen zulässig.

    Der Standardwert ist 604800 Sekunden. Der zulässige Mindestwert ist 1 Sekunde und der Maximalwert 2147483647 Sekunden.
    Lebensdauer des Aktualisierungstokens verlängern Mit dieser Option wird angegeben, ob die Lebensdauer des Aktualisierungstokens verlängert wird, wenn ein Aktualisierungstoken verwendet wird, um eine neue Gruppe von Tokens abzurufen. Wird dieses Kontrollkästchen ausgewählt, wird die mit Ablauf des Aktualisierungstokens festgelegte Lebensdauer bei jeder Aktualisierung der Aktualisierungstokens verlängert. Wird das Kontrollkästchen nicht ausgewählt, läuft das erneuerte Aktualisierungstoken ab, wenn der ursprüngliche Ablauf des Aktualisierungstokens erreicht wird.
  5. Geben Sie die ID-Tokensignatur und Verschlüsselungsoptionen an. Die Relying Party verwendet die Signatur, um die Integrität und Authentizität der Benutzeranforderungen zu überprüfen, die im Token enthalten sind, und den OpenID Connect -Identitätsprovider , der das Token signiert hat. Das Token kann so verschlüsselt werden, sodass es nur von der Relying Party entschlüsselt werden kann.
    Tabelle 2. Signatur- und Verschlüsselungsoptionen
    Feld Beschreibung
    Signaturalgorithmus

    Der Algorithmus, den Verify zum Signieren des ID-Tokensverwendet. Der Algorithmus muss mit dem übereinstimmen, den die Relying Party bei Verifyregistriert hat.

    Wählen Sie einen der folgende Hashalgorithmen aus, um die Signatur zu verifizieren:
    • HS256
    • HS384
    • HS512
    • ES256
    • ES384
    • ES512
    • PS256
    • PS384
    • PS512
    • RS256 (Standardwert)
    • RS384
    • RS512
    Hinweis:
    • Wenn der Signaturalgorithmus ES256 ausgewählt ist, muss das Zertifikat ECDSA mit P-256 sein.
    • Wenn der Signaturalgorithmus ES384 ausgewählt ist, muss das Zertifikat ECDSA mit P-384 sein.
    • Wenn der Signaturalgorithmus ES512 ausgewählt ist, muss das Zertifikat ECDSA mit P-521 sein.
    • Die HS-Algorithmen werden nicht angezeigt, wenn Sie angeben, dass kein geheimer Clientschlüssel generiert werden soll.
    Signaturzertifikat

    Diese Option wird nur angezeigt, wenn Sie einen der RS-, ES- oder PS-Signaturalgorithmen ausgewählt hatten.

    Verwenden Sie dieses Zertifikat, um das ID-Token während der einmaligen Anmeldung zu signieren.

    Die Standardauswahl bezieht sich auf das Standard-Persönliche Zertifikat, das Sie unter „Sicherheit > Zertifikate > Persönliche Zertifikate“ konfiguriert haben.
    Verschlüsselungsalgorithmus Der Verschlüsselungsalgorithmus, der verwendet wird, um den Wert des Inhaltsverschlüsselungsschlüssels (CEK) zu verschlüsseln oder zu bestimmen.
    Die folgenden Algorithmen werden unterstützt:
    • RSA-OAEP
    • RSA-OAEP-256
    Inhaltsalgorithmus Der Inhaltsverschlüsselungsalgorithmus, der zum Ausführen der authentifizierten Verschlüsselung des Klartextes verwendet wird, um den verschlüsselten Text und den Authentifizierungstag zu generieren.
    Die folgenden Algorithmen werden unterstützt:
    • A128GCM
    • A192GCM
    • A256GCM
    Verschlüsselungsschlüssel Der Zertifikatskennsatz oder die Schlüssel-ID des Schlüssels für die Verschlüsselung.
  6. Ordnen Sie der Relying Party über das ID-Tokendie Benutzerattribute zu, die Verify unterstützt und bereitstellt.
    Verify könnte das Standard-JSON-Claims-Schema um zusätzliche Attribute wie Mitarbeiterrolle, Vorgesetzter und Abteilung erweitern.
    Anmerkung: Die folgenden Attribute wurden dem ID-Token standardmäßig hinzugefügt: userType, uniqueSecurityName, displayName, realmName, name, preferred_username, jti, at_hash, ext. Einige dieser Attribute können aus dem ID-Token entfernt werden, indem sie einer Attributquelle zugeordnet werden, die so konfiguriert ist, dass kein Wert zurückgegeben wird.
    Der Abschnitt Attributzuordnungen besteht aus den folgenden Elementen, die in Tabelle 3beschrieben sind:
    • Kontrollkästchenoption zum Senden aller bekannten Benutzerattribute
    • Option zum Hinzufügen von Attributnamen und ihrer entsprechenden Attributquelle in Verify.
    Tabelle 3. Attributzuordnungen
    Information Beschreibung
    Alle bekannten Benutzerattribute im ID-Token senden

    Wenn diese Option ausgewählt ist, werden alle bekannten Benutzerberechtigungsattribute, die aus der Identitätsquelle des OpenID Connect-Providers verfügbar sind, automatisch in das ID-Tokeneingeschlossen.

    Bekannte Benutzerberechtigungsattribute umfassen:
    Standardattribute
    Diese Attribute stammen aus dem Verify Cloud Directory, das die integrierten Attribute enthält, die unter Verzeichnis > Attribute angezeigt werden.
    Erweiterte Attribute
    Diese Attribute stammen von dem SAML Enterprise-Identitätsanbieter, den Sie unter Authentifizierung > Identitätsanbieter konfiguriert haben.

    Definieren Sie andernfalls nur die spezifischen Attribute, die die Relying Party im ID-Token erfordert. Geben Sie den Attributnamen und die Attributquelle an.
    Attributname Name des Attributs, das die Relying Party verwendet und von Verifyerfordert.Die folgenden Attributnamen können nicht verwendet werden: aud, exp, groupIds, groupUids, at_hash, c_hash, rt_hash, s_hash, iat, iss, nonce, client_id, grant_id, grant_type und scope. Wenn der Attributname subist, ändert diese Attributzuordnung den Wert von sub in der Introspektionsantwort, dem JWT-Zugriffstoken, der Benutzerinformationsantwort und dem ID-Token.
    Attribute

    Listet alle Attributquellen auf, die Sie für jeden Typ in Verzeichnis > Attribute definiert haben.

    Der Wert Ihrer ausgewählten Attributquelle wird als der Attributwert für den definierten Attributnamen der Relying Party im ID-Token zugeordnet.

    Hinweis: Wenn Attribut ohne Kennung für den Attributquellenwert angezeigt wird, liegt dies daran, dass der Zweck des Attributs geändert wurde. Vorhandene Anwendungen, die das Attribut verarbeiten, können das Attribut weiterhin verwenden, bis Sie der Anwendung die Verwendung eines anderen Attributs für diesen Zweck zuordnen. Wenn beispielsweise das Kontrollkästchen Einmalige Anmeldung (SSO) für ein vorhandenes Attribut abgewählt wird, können Anwendungen, die dieses Attribut für SSO bereits verarbeiten, das Attribut weiterhin für SSO verwenden. Dasselbe Verhalten gilt für die Bereitstellungsattributszuordnungen, wenn der Zweck Bereitstellung entfernt wird.
  7. Wählen Sie die Identitätsquellen und die Richtlinie aus, die festlegen, wie Benutzer auf die Anwendung zugreifen können.
    1. Wählen Sie die Identitätsquellen aus, mit denen eine Anmeldung bei dieser Anwendung möglich ist.

      Die Standardeinstellung ist, dass der Zugriff von allen für den Tenant konfigurierten Unternehmensidentitätsquellen zugelassen wird. Um die Identitätsquellen einzuschränken, die für die Anmeldung bei der Anwendung verwendet werden können, wählen Sie Bestimmte unterstützte Identitätsquellen auswählen aus. Wählen Sie die Kontrollkästchen für die Identitätsquellen aus, über die die Anmeldung ermöglicht werden soll.

    2. Wählen Sie die Richtlinie aus, die festlegt, wie Benutzer auf die Anwendung zugreifen können.
      Sie können weiterhin die zugeordnete Standardzugriffsrichtlinie, Zugriff über alle Geräte ermöglichen, verwenden. Alternativ können Sie das Kontrollkästchen deaktivieren und Bearbeiten auswählen, um aus der Liste der vordefinierten Zugriffsrichtlinien auszuwählen. Bei Auswahl einer Zugriffsrichtlinie können Sie die Zugriffsrichtlinie auf API-Erteilungstypen anwenden, indem Sie das Kontrollkästchen für jeden Erteilungstyp auswählen. Weitere Informationen finden Sie unter Zugangsrichtlinien.
  8. Wählen Sie aus, ob die Benutzerzustimmung angefordert werden soll.
    Die Benutzerzustimmungsanforderung kann OpenID Connect-Anwendungen hinzugefügt werden. Sie ist für alle Erteilungstypen mit Ausnahme der Kennwortberechtigungsnachweise für Ressourceneigner (ROPC) verfügbar. Wenn ROPC der einzige Erteilungstyp ist, der für die Anwendung ausgewählt ist, ist die Option Benutzerzustimmung ausgeblendet. Wenn der Standardwert, Zustimmung anfordern, ausgewählt bleibt, wird der Benutzer explizit zur Zustimmung zu Geltungsbereichen und API-Zugriffsnutzungsrechten aufgefordert. Der Benutzer kann die Berechtigung für den API-Zugriff erteilen oder verweigern. Für vorhandene OpenID Connect-Anwendungen wird keine Zustimmung angefordert. Sie müssen diese Anwendungen bearbeiten, wenn Benutzerzustimmung angefordert werden soll. Siehe Verwaltung von Anwendungsgenehmigungen.

    Nachdem die Anwendung erstellt wurde, wird das Feld Zustimmungstyp mit dem Wert Erweitert unter Zustimmung anfordern angezeigt. Der Wert Erweitert gibt an, dass die Benutzerzustimmungen in DPCM gespeichert werden. In älteren angepassten OIDC-Anwendungen wird dieses Feld angezeigt, nachdem die Zustimmungen nach DPCM migriert wurden.

  9. Optional: Benutzerdefinierte Bereiche einschränken.
    Angepasste Geltungsbereiche können von einem OIDC-/OAuth-Client in den unterstützten OIDC-/OAuth-Erteilungsabläufen angefordert werden. Wenn Angepasste Geltungsbereiche einschränken aktiviert ist (dies ist die Standardeinstellung), werden die Geltungsbereiche, die dem Client am Ende des Ablaufs erteilt werden, auf die in diesem Abschnitt angegebenen Geltungsbereiche beschränkt. Wenn Angepasste Geltungsbereiche einschränken inaktiviert ist, werden alle angeforderten angepassten Geltungsbereiche erteilt, wenn der Ablauf endet.
    Hinweis: Die Standardbereiche openid, profile, email, phoneund address können nicht eingeschränkt werden.
    1. Stellen Sie sicher, dass das Kontrollkästchen Angepasste Geltungsbereiche beschränken ausgewählt ist.
    2. Geben Sie den Namen des angepassten Geltungsbereichs, der erteilt werden soll, und eine Beschreibung ein.
      Der Geltungsbereichsname bezieht sich auf den OAuth2-/OIDC-Geltungsbereich, der von einer Relying Party/einem Relying Client angefordert wird. Die Beschreibung ist eine aussagefähige Erläuterung für den Geltungsbereich.
      Eine weitere Gruppe von Geltungsbereichsfeldern wird angezeigt.
    3. Wiederholen den vorherigen Schritt für jeden angepassten Geltungsbereich, der erteilt werden soll.
  10. Optional: Gewähren Sie dem Anmeldetoken API-Berechtigungen.
    'API-Zugriff einschränken' ist die Standardeinstellung für neue Anwendungen. Die Anwendung verfügt über keine Anmeldetokennutzungsrechte. Um Nutzungsrechte für den API-Zugriff zuzuordnen, führen Sie die folgenden Schritte aus.
    1. Wählen Sie das Bearbeitungssymbol aus.
      Der Assistent 'API-Client bearbeiten' wird gestartet.
    2. Wählen Sie die Benutzer- und Nicht-Benutzer-Berechtigungen aus, die dem Anmeldetoken zugeordnet werden sollen.
      Wenn Sie das Kontrollkästchen API-Zugriff einschränken abwählen, wird dem Token ein Gruppe von Standardnutzungsrechten zugeordnet. Siehe Standard-Anmeldetoken-API-Berechtigungen.
    3. Wählen Sie Speichern.
  11. Wählen Sie Speichern.

Nächste Schritte