OpenID konfigurieren Single-Sign-On in der benutzerdefinierten Anwendung verbinden

Online bearbeiten

VerifyVerwenden Sie „ OpenID Connect“ für Single Sign-On, damit Anwendungen die Identität ihrer Benutzer auf der Grundlage der von durchgeführten Authentifizierung überprüfen können. Benutzer müssen sich nicht für einen Account bei der Zielanwendung anmelden. Die Benutzer werden zur Verify Anmeldung weitergeleitet. Verify überprüft die Identität der Benutzer, übermittelt die Informationen über ein ID-Token und bestätigt gegenüber der vertrauenden Partei, dass die Benutzer zum Zugriff auf die Ressource und zu deren Nutzung berechtigt sind. https://<tenant-host>/oidc/endpoint/default/.well-known/openid-configurationDiese Anwendung nutzt den „ OpenID “-Connect-Anbieter mit dem Discovery-Endpunkt.

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 Verwaltungskonsole und die andere für die Verwaltungskonsole der Zielanwendung.
- Melden Sie sich als Administrator bei der IBM® Verify Verwaltungskonsole an.
- Melden Sie sich bei der Verwaltungskonsole der Zielanwendung mit Ihrem Administratoraccount an.
Sie müssen die grundlegenden Informationen für die Anwendungsinstanz auf der Registerkarte „Allgemein“ einrichten. Siehe „Grundlegende Anwendungsdetails festlegen “.

Informationen zu dieser Task

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

Konfigurieren Sie Verify und die vertrauende Partei so, dass sie miteinander kommunizieren können. Um das Single-Sign-On für „ OpenID Connect“ zu aktivieren, müssen Sie Folgendes angeben:

Verify mit bestimmten Daten der vertrauenden Partei.
Die vertrauende Partei mit bestimmten Daten von Verify.

Sie können Web- und mobile Anwendungen als vertrauenswürdige Parteien für „ OpenID Connect“ konfigurieren IBM Verify Access .

Vorgehensweise

Wechseln Sie zur Registerkarte „Anmeldung “.
OpenID Verbinden 1.0Wählen Sie im Menü Anmeldemethode die Option.

Geben Verify Sie grundlegende Informationen über die vertrauende Partei an.


Feld	Beschreibung
Anwendungs-URL	Es handelt sich um die Single-Sign-On-Initialisierungs- URL, die für die Anmeldung bei der vertrauenden Partei „ OpenID Connect“ verwendet wird. Die Anwendung nutzt diesen Link URL, um das ID-Token anzufordern Verify , das die Benutzerdaten enthält. Wenn Nutzer über diese URL URL auf die Anwendung zugreifen, werden sie zur Verify Authentifizierung 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	VerifyEs gibt den Mechanismus an, mit dem die vertrauende Partei das ID-Token abrufen kann. Verify unterstützt die folgenden Förderarten: Berechtigungscode Hinweis: Der Autorisierungscode ist als Standard-Berechtigungstyp voreingestellt, wobei auch PKCE standardmäßig ausgewählt ist. Implizit Geräteablauf Hinweis: Wenn Sie „Geräteübertragung“ auswählen, können Sie auch einen QR-Code erstellen. Kontextbasierte Berechtigung JWT-Träger `JWT bearer default identity sourceJWKS URI`Hinweis: Wenn Sie „JWT Bearer“ auswählen, haben Sie die Möglichkeit,, `JWT bearer user identification` und zu konfigurieren. Weitere Informationen zur Verwendung des JWT-Bearer-Zugriffstyp finden Sie unter „Zugriffstypen “. 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örderarten“ finden Sie einen kurzen Überblick über die unterstützten Förderarten und können feststellen, welche Förderart für den Antrag ausgewählt werden sollte.
Client ID	Es handelt sich um die eindeutige öffentliche Kennung, die der Client-Anwendung zugewiesen wird, die als vertrauende Partei von „ OpenID Connect“ fungiert. Der Berechtigungsserver verwendet diese Informationen, um die Relying Party und die Berechtigungsanforderung zu identifizieren. Diese Informationen werden automatisch generiert, nachdem Sie die benutzerdefinierte „ OpenID Connect “-Anwendung gespeichert haben. Sie müssen diese Informationen der vertrauenden Partei zur Verfügung stellen, wenn Sie sich in der Verwaltungskonsole der Anwendung als „ OpenID -Connect“-Anbieter konfigurieren Verify . 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 „Client Secret“ ausgeblendet und die folgenden Algorithmen werden aus den Optionen für den 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, nachdem Sie die benutzerdefinierte „ OpenID Connect “-Anwendung gespeichert haben. Sie müssen diese Informationen der vertrauenden Partei zur Verfügung stellen, wenn Sie sich in der Verwaltungskonsole der Anwendung als „ OpenID -Connect“-Anbieter konfigurieren Verify .
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. Weitere Informationen zu JWT mit Client-Secret und JWT mit privatem Schlüssel finden Sie unter „JWT mit Client-Secret und JWT mit privatem Schlüssel erstellen “.
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 die Callback-Adresse URL; die Adresse, an Verify die die Authentifizierungsantwort an die vertrauende Partei gesendet wird. VerifyBenutzer werden auf diese Seite URL weitergeleitet, nachdem sie sich angemeldet und autorisiert haben. 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 Domain kann einen Platzhalterwert enthalten. Obwohl Platzhalter im URI-Pfad nicht unterstützt werden, ist das Zeichen „*“ ein gültiges Zeichen im URI-Pfad und wird als literaler String 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 aus, um den geheimen Clientschlüssel anzuzeigen.
Wählen Sie aus, um den geheimen Clientschlüssel auszublenden.
Wählen Sie diese Option, um die Client-ID oder den geheimen Schlüssel in die Zwischenablage zu kopieren.
Wählen Sie diese Option aus, um die geänderten Client-Geheimnisse anzuzeigen.
- Wählen Sie ein oder mehrere aktualisierte Client-Geheimnisse aus der Liste aus und klicken Sie auf „Löschen“, um sie zu löschen.
Wählen Sie 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 „Aktuelles Geheimnis beibehalten “, um das aktuelle Client-Geheimnis zur Liste der rotierten Client-Geheimnisse hinzuzufügen.
- Wenn das Kontrollkästchen „Aktuelles Geheimnis beibehalten“ aktiviert ist, wählen Sie die Beschreibung des Client-Geheimnisses und die Ablaufzeit (in der lokalen Zeit des Browsers) aus. Wenn keine Ablaufzeit ausgewählt wird, gilt die in den Anwendungseinstellungen festgelegte Lebensdauer des rotierten Geheimnisses des Mandanten.
- Rotierte Client-Geheimnisse werden gehasht und können nicht mehr im Klartext abgerufen werden, können jedoch bis zum gewählten Ablaufdatum weiterhin verwendet werden.
- Nach der Bestätigung wird das Client-Geheimnis sofort aktualisiert. Das neue Client-Geheimnis wird auf dem Bildschirm angezeigt.

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 undurchsichtige Zeichenfolge generiert wird, was`Default`Einstellung oder 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	VerifyName des Attributs, das die vertrauende Partei verwendet und von [Name] verlangt. Die folgenden Attributnamen dürfen 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 Client-Anwendung ein Aktualisierungstoken anfordern und verwenden kann, um vom Autorisierungsserver des Identitätsanbieters „ OpenID Connect“ ein neues Zugriffstoken zu erhalten. Verwenden Sie diese Option nur, wenn die Anwendung beabsichtigt, das Zugriffstoken zur Ausführung von Vorgängen über Verify APIs zu nutzen. 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 die Ablaufzeit des Aktualisierungstokens so fest, dass der Benutzer den vollständigen Single-Sign-On-Vorgang nach Verify Ablauf einer bestimmten Zeit erneut durchführt. 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.

Legen Sie die Signatur- und Verschlüsselungsoptionen für das ID-Token fest. Die vertrauende Partei nutzt die Signatur, um die Integrität und Authentizität der im Token enthaltenen Benutzerangaben sowie des Identitätsanbieters „ OpenID Connect“, der das Token signiert hat, zu überprüfen. Das Token kann so verschlüsselt werden, sodass es nur von der Relying Party entschlüsselt werden kann.

Tabelle 2. Optionen für Signatur und Verschlüsselung
Feld	Beschreibung
Signaturalgorithmus	Der Algorithmus, der Verify zum Signieren des ID-Tokens verwendet wird. VerifyDer Algorithmus muss mit dem übereinstimmen, den die vertrauende Partei registriert 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.

Ordnen Sie die Benutzerattribute zu, die Verify unterstützt und der vertrauenden Partei über das ID-Token bereitstellt.

Verify könnte das Standard-JSON-Claims-Schema um zusätzliche Attribute wie Mitarbeiterrolle, Vorgesetzter und Abteilung erweitern.

Hinweis: Die folgenden Attribute sind standardmäßig bereits zum ID-Token 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 man sie einer Attributquelle zuordnet, die so konfiguriert ist, dass sie keinen Wert zurückgibt.

Der Abschnitt „Attributzuordnungen“ umfasst die folgenden Elemente, die in Tabelle 3 beschrieben sind.

Kontrollkästchenoption zum Senden aller bekannten Benutzerattribute
Möglichkeit, Attributnamen und die dazugehörige Attributquelle in Verify. hinzuzufügen

Tabelle 3. Attributzuordnungen
Information	Beschreibung
Alle bekannten Benutzerattribute im ID-Token senden	Wenn diese Option ausgewählt ist, werden alle bekannten Attribute der Benutzeranmeldedaten, die über die Identitätsquelle des „ OpenID Connect“-Anbieters verfügbar sind, automatisch in das ID-Token aufgenommen. Bekannte Benutzerberechtigungsattribute umfassen: Standardattribute Diese Attribute stammen aus dem Verify Cloud-Verzeichnis, das die integrierten Attribute enthält, die unter „Verzeichnis > Attribute“ angezeigt werden. Erweiterte Attribute Diese Attribute stammen vom Identitätsanbieter „ SAML Enterprise“, 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	VerifyName des Attributs, das die vertrauende Partei verwendet und von [Name] verlangt. Die folgenden Attributnamen dürfen 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. `sub`Wenn der Attributname lautet, ändert diese Attributzuordnung den Wert von `sub` in der Introspection-Antwort, dem JWT-Zugriffstoken, der Userinfo-Antwort und dem ID-Token.
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. Hinweis: Wenn für den Quellwert des Attributs „Untagged“ 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.

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 auf klicken, um aus der Liste der vordefinierten Zugriffsrichtlinien auszuwählen. Wenn eine Zugriffsrichtlinie ausgewählt ist, können Sie diese auf API-Berechtigungsarten anwenden, indem Sie das Kontrollkästchen für die jeweilige Berechtigungsart aktivieren. Weitere Informationen finden Sie unter „Zugriffsrichtlinien “.
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 „Verwalten von Anwendungsberechtigungen “.
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.
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 Standard-Gültigkeitsbereiche openid, profile, email, phone, und address können nicht eingeschränkt werden.
1. Stellen Sie sicher, dass das Kontrollkästchen „Benutzerdefinierte Bereiche einschränken“ aktiviert 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.
Optional: Weisen Sie dem Anmeldetoken API-Berechtigungen zu.
'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 „Standardberechtigungen für Benutzertoken“ aktivieren oder das Kontrollkästchen „API-Zugriff einschränken“ deaktivieren, wird eine Reihe von Standardberechtigungen für Benutzertoken gewährt.
3. Wählen Sie „Speichern “.
Wählen Sie „Speichern “.

Nächste Schritte

Stellen Sie der vertrauenden Partei die Informationen zur Verify Verfügung, die erforderlich sind, um die Konfiguration der Anmeldung über „ OpenID Connect“ zwischen Verify [Name] und der vertrauenden Partei abzuschließen. Siehe die in der Benutzerschnittstelle zur Verfügung gestellten Anweisungen.
Fügen Sie Benutzer- oder Gruppennutzungsrechte hinzu, um Zugriff auf die konfigurierten Anwendungen zu ermöglichen. Siehe „Verwalten von Anwendungsberechtigungen“ (durch den Administrator oder den Anwendungsinhaber).
Setzen Sie die Zwei-Faktor-Authentifizierung durch, um die Sicherheitssteuerung von Benutzern zu verbessern, wenn sie sich bei den konfigurierten Anwendungen anmelden. Siehe „Konfigurieren von Authentifizierungsfaktoren “.