Konfigurieren von Single Sign-On in der Anwendung „ OpenID Connect“

Online bearbeiten

IBM® VerifyVerwenden Sie „ OpenID Connect“, um Anwendungen die Identitätsprüfung ihrer Benutzer auf der Grundlage des Authentifizierungs-Callbacks von zu ermöglichen. Außerdem müssen sich Nutzer nicht für ein Konto bei der Anwendung registrieren. Die Benutzer werden zur Verify Anmeldung weitergeleitet. Verify überprüft die Identitäten der Benutzer, sendet die Informationen über ein ID-Token und bestätigt dem vertrauenden Dritten (der Relying Party), dass die Benutzer berechtigt sind, auf die Ressource zuzugreifen und sie zu verwenden. Diese Anwendung nutzt den neuen „ OpenID “-Connect-Anbieter mit dem Discovery-Endpunkt: https://<tenant-host>/oauth2/.well-known/openid-configuration.

Vorbereitende Schritte

  • Zur Ausführung dieser Task müssen Sie über Verwaltungsberechtigung verfügen.
  • Öffnen Sie mindestens zwei Browserfenster, um die Konfiguration auszuführen. Eine für die Verify Verwaltungskonsole und die andere für die Verwaltungskonsole der Zielanwendung.
    • Melden Sie sich bei der Verify Verwaltungskonsole an.
    • Melden Sie sich mit Ihrem Administratorkonto an der Administrationskonsole der Zielanwendung an.
  • Sie müssen die Basisinformationen für die Anwendungsinstanz auf der Registerkarte Allgemein konfigurieren. Siehe „Grundlegende Anwendungsdetails festlegen “.

Informationen zu dieser Task

VerifyWählen Sie bei der Überprüfung einer Anwendung die Vorlage „ OpenID Connect“ aus, um eine Anwendung so zu konfigurieren, dass sie als „ OpenID Connect“-Vertrauenspartei oder als Client-Anwendung fungiert, die die Benutzerauthentifizierung an Connect delegiert.

Konfigurieren Sie Verify und die Relying Party für die Kommunikation miteinander. Zum Aktivieren von Single Sign-on für OpenID Connect müssen Sie Folgendes angeben:

  • Verify mit bestimmten Daten der Relying Party.
  • Die Relying Party mit bestimmten Daten von Verify.

Sie können IBM Verify Access und mobile Anwendungen als Relying Partys von OpenID Connect konfigurieren.

Vorgehensweise

  1. Wechseln Sie zur Registerkarte „Anmeldung “.
  2. Geben Sie "Mit Basisinformationen verifzieren" für die Relying Party 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.

    OpenID Connect unterstützt die folgenden Förderarten:
    • Berechtigungscode
    • Implizit
    • Geräteablauf
    • Berechtigungsnachweise des Clients
    • "Berechtigungscode" und "Implizit" (Hybridablauf)
    • Kennwortberechtigungsnachweise für Ressourceneigner (ROPC)
    • Tokenaustausch
    • JWT-Träger
    • Kontextbasierte Berechtigung

    Sie müssen mindestens einen Erteilungstyp auswählen. 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.
    Antworttypen Die Antworttypen teilen dem Autorisierungsserver mit, welcher Autorisierungsablauf gewünscht ist.
    Hinweis: Wenn Sie eine bestehende Anwendung bearbeiten, für die keine Antworttypen konfiguriert sind, werden standardmäßig alle zutreffenden Antworttypen für die aktivierten Bewilligungsarten verwendet.
    OpenID Connect unterstützt die folgenden Antworttypen:
    • none
    • code
    • token
    • id_token
    • code token
    • code id_token
    • token id_token
    • code token id_token

    Wenn der Antworttyp code oder none ausgewählt ist, ist der Antwortmodus query aktiviert. Andernfalls wird der query Antwortmodus zurückgesetzt und deaktiviert.
    Antwortmodi Der Antwortmodus gibt an, wie der Berechtigungsserver Ergebnisparameter vom Berechtigungsendpunkt zurückgibt.
    OpenID Connect unterstützt die folgenden Antwortmodi:
    • Abfrage
    • Fragment
    • Formular POST
    • JWT abfragen
    • JWT-Fragment
    • Formular-POST-JWT
    Client ID

    Es handelt sich um die eindeutige öffentliche Kennung, die der Client-Anwendung zugewiesen wird, bei der es sich um die vertrauende Partei „ OpenID Connect“ handelt. Der Berechtigungsserver verwendet diese Informationen, um die Relying Party und die Berechtigungsanforderung zu identifizieren.

    Diese Informationen werden automatisch generiert, nachdem Sie die Anwendung „ OpenID Connect“ gespeichert haben. 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 jedes Mal, wenn sie ein Zugriffstoken anfordert.
    Öffentlicher Client (kein geheimer Clientschlüssel)

    Gibt an, dass der Client nicht über einen geheimen Schlüssel verfügt, der von der Anwendung bereitgestellt werden muss

    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.

    Der geheime Schlüssel des Clients darf nur der Clientanwendung und dem Authorisierungsserver bekannt sein.

    Hinweis: Wenn Sie diese Option auswählen, wird das Feld für den Client-Schlüssel ausgeblendet.
    Clientschlüssel

    Diese Daten werden zusammen mit der Client-ID verwendet, um die Relying Party zu authentifizieren und einen Berechtigungscode für ein ID-Token auszutauschen.

    Diese Informationen werden automatisch generiert, nachdem Sie die Anwendung „ OpenID Connect“ gespeichert haben. Sie müssen diese Informationen der Relying Party bereitstellen, wenn Sie Verify als OpenID Connect-Provider in der Administrationskonsole der Anwendung konfigurieren.
    Weiterleitungs-URIs*

    Dies ist die Callback-URL, also die Adresse, von der Verify seine Authentifizierungsantwort an die Relying Party sendet.

    VerifyBenutzer werden auf diese Seite URL weitergeleitet, nachdem sie sich angemeldet und autorisiert haben.

    Sie müssen mindestens einen URI angeben.

    Sie können maximal 400 URIs hinzufügen.

    Diese Informationen erhalten Sie von der vertrauenden Partei, wenn Sie einen Autorisierungsanbieter oder einen „ OpenID Connect “-Anbieter auf dessen Website konfigurieren.
    Clientauthentifizierungsmethode
    Verify unterstützt die folgenden Clientauthentifizierungsmethoden:
    • Standard
    • Geheimer Clientschlüssel - Basis
    • Geheimer Clientschlüssel - POST
    • Privater Schlüssel - JWT
    • Gegenseitiges TLS
    Hinweis: Die Standardmethode für die Client-Authentifizierung ist „default “.

    Wird 'Standard' übernommen, sind 'Geheimer Clientschlüssel - Basis' und 'Geheimer Clientschlüssel - POST' zulässig. Wenn es sich bei diesem Client um einen öffentlichen Client handelt, sind 'Geheimer Clientschlüssel - Basis' und 'Geheimer Clientschlüssel - POST' nicht zulässig. Wenn die Relying Party dies unterstützt, verwenden Sie den privaten JWT-Schlüssel oder Mutual TLS für die Konfiguration. Weitere Informationen zur Client-Authentifizierung bei „Mutual TLS “ finden Sie unter OpenID. Verbinden Sie die Client-Authentifizierung bei „Mutual TLS “ mit dem zertifikatsgebundenen Zugriffstoken.

    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 'Privater Schlüssel - JWT' ausgewählt ist.
    Algorithmus zur Signierung von Client-Assertions*

    *Diese Option wird nur angezeigt, wenn die JWT -Client-Authentifizierungsmethode mit privatem Schlüssel ausgewählt ist.
    TLS-Clientauthentifizierungsattribut Das Zertifikatsattribut, das für die Authentifizierung verwendet wird. Diese Option wird nur angezeigt, wenn die Clientauthentifizierungsmethode "Mutual TLS" ausgewählt ist.
    • Registrierter Name des Zertifikatsinhabers
    • SAN DNS
    • SAN-URI
    • SAN-IP
    • SAN-E-Mail-Adresse
    TLS Wert des Attributs zur Client-Authentifizierung* Der Wert des Attributs im Zertifikat, das für die Authentifizierung verwendet wird. Diese Option wird nur angezeigt, wenn die Clientauthentifizierungsmethode "Mutual TLS" 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.
    Push-Operation für Berechtigungsanforderung (PAR) erforderlich Eine PAR ermöglicht Clients, die Nutzdaten einer Berechtigungsanforderung über eine direkte Anforderung an den Berechtigungsserver zu übertragen und stellt einen Anforderungs-URI zur Verfügung, der als Referenz für die Daten in einem nachfolgenden Aufruf an den Berechtigungsendpunkt verwendet wird.
    Den Austausch von Zugriffstoken für eine SSO-Sitzung zulassen Austausch von Zugriffstoken für die SSO-Sitzung.
    • Zulassen: Zugriffstoken können gegen eine SSO-Sitzung eingetauscht werden.
    • Token zulassen und widerrufen: Zugriffstoken können für eine SSO-Sitzung ausgetauscht werden, das Token wird jedoch widerrufen.
    • Ablehnen: Zugriffstoken können nicht gegen eine SSO-Sitzung eingetauscht werden.
    • Standard: In den allgemeinen Einstellungen der OIDC-Anwendung wird festgelegt, ob Zugriffstoken für eine SSO-Sitzung ausgetauscht werden können.
    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 Kopieren Sie diese Option, um die Client-ID oder den geheimen Schlüssel in die Zwischenablage zu kopieren.
    • Wählen Liste 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 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 „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.
  3. Konfigurieren Sie die JWT-Einstellungen.
    Tabelle 1. JWT-Einstellungen
    Feld Beschreibung
    JWKS-URI Der URI, unter dem die Relying Party ihre öffentlichen Schlüssel im JWKS-Format (JWKS = JSON Web Keys Set) veröffentlicht. Dieser URI wird für die JWT-Signaturprüfung oder -Verschlüsselung 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. Sie he „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.
    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.
    JWT-Bearer-Benutzeridentifikation Nur für den JWT-Bearer-Zugriffstyp 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 „sub“ kann „des Benutzers“ID, Username„das“ oder „der“ seinExternal ID.
    Standard-Identitätsquelle für JWT-Bearer-Zugriffsanfragen Nur für den JWT-Bearer-Zugriffstyp verfügbar. Wenn im JWT kein Realm angegeben ist, wird standardmäßig der Realm der Identitätsquelle verwendet, zu der der durch den Sub identifizierte Benutzer gehört. Wenn dieJWT bearer user identification Option aktiviert istUser ID, findet diese Einstellung keine Anwendung.
  4. Konfigurieren Sie die Einstellungen des Request-Objekts.
    Tabelle 2. Objekteinstellungen abrufen
    Feld Beschreibung
    Nur Parameter für Anforderungsobjekte Alle Anforderungsparameter müssen im Anforderungsobjekt enthalten sein.
    Signaturalgorithmus Der Algorithmus, bei dem von Verify erwartet wird, dass das Anforderungsobjekt signiert wird.
    Wählen Sie einen der folgende Hashalgorithmen aus, um die Signatur zu verifizieren:
    • RS256
    • RS384
    • RS512
    • PS256
    • PS384
    • PS512
    • ES256
    • ES384
    • ES512
    Ablaufanforderung erforderlich Das Anfrageobjekt muss die Eigenschaft „expiry“'exp' enthalten.
    Gültigkeit (Sek.) Die Höchstdauer (in Sekunden), für die das Anforderungsobjekt gültig sein kann. Dies wird berechnet, indem man das Ablaufdatum'exp' vom „Not-Before“-Zeitstempel'nbf' im Anfrageobjekt abzieht.
    Anforderungs-URIs Die URL einer Ressource, die ein Anforderungsobjekt enthält. Nur hier registrierte Anforderungs-URIs sind während der Autorisierungsanforderung zulässig.
  5. 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 3. Token-Einstellungen
    Feld Beschreibung
    Ablauf des Zugriffstokens (Sek.)

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

    Legen Sie einen Ablaufzeitpunkt für das Zugriffstoken fest, um die Zeit zu begrenzen, in der ein Angreifer mit dem gestohlenen Token auf die Ressource zugreifen kann, wenn die 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 das Format des Zugriffstokens an. Die folgenden Optionen sind verfügbar:
    • Standard
    • JWT
    Zielgruppen Gibt die Ziele an, die die Empfänger des Tokens sind. Diese Werte sind in deraud Anforderung für JWT-formatierte Token und in der Introspection-Nutzlast entweder als einzelne Zeichenkette oder als Array von Zeichenketten aufgeführt.
    Aktualisierungstoken generieren

    Gibt an, ob die Client-Anwendung ein Aktualisierungstoken anfordern und verwenden kann, um ein neues Zugriffstoken vom Autorisierungsserver des Identitätsanbieters „ OpenID Connect“ 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 relevant, wenn "Implizit" der einzige Erteilungstyp ist, den Sie ausgewählt haben.
    Ablauf des Aktualisierungstokens (Sek.)

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

    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.
  6. Geben Sie die Signatur für das ID-Token und die Verschlüsselungsoptionen an. Die Relying Party verwendet die Signatur, um die Integrität und Authentizität der im Token enthaltenen Benutzeranforderungen und des OpenID Connect-Identitätsproviders, der das Token signiert hat, zu überprüfen. Das Token kann verschlüsselt werden, sodass es nur von der Relying Party entschlüsselt werden kann.
    Tabelle 4. Optionen für Signatur und Verschlüsselung
    Feld Beschreibung
    Signaturalgorithmus

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

    Wählen Sie einen der folgende Hashalgorithmen aus, um die Signatur zu verifizieren:
    • RS256
    • PS256
    • ES256
    • RS384
    • PS384
    • ES384
    • RS512
    • PS512
    • ES512
    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.
    Signaturzertifikat

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

    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 für die authentifizierte Verschlüsselung des Klartexts verwendet wird, um den verschlüsselten Text und den Authentifizierungstag zu erzeugen.
    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.
  7. Konfigurieren Sie die Einstellungen für den Besitznachweis. Weitere Informationen finden Sie unter „Nachweis des Besitzes“ ( DPoP ).
    Tabelle 5. Einstellungen für den Besitznachweis
    Feld Beschreibung
    Zertifikatgebundene Zugriffstoken Gibt an, ob die generierten Token an ein Zertifikat gebunden sind. Weitere Informationen zu zertifikatsgebundenen Zugriffstoken finden Sie unter „OpenID Connect – gegenseitige Authentifizierung von Clients und zertifikatsgebundene Zugriffstoken“ ( TLS ).
    DPoP-gebundene Zugriffstoken durchsetzen Gibt an, ob für Token-Anfragen der Header „ DPoP “ erforderlich ist.
    JTI des DPoP-JWT validieren Gibt an, ob das JTI im JWT „ DPoP “ für die einmalige Verwendung validiert ist.
    Signaturalgorithmus für DPoP-JWT

    Der erwartete Signaturalgorithmus für das JWT „ DPoP “.

    Wählen Sie aus den folgenden Algorithmen:

    • RS256

    • RS384

    • RS512

    • PS256

    • PS384

    • PS512

    • ES256

    • ES384

    • ES512
  8. Geben Sie die Konfigurationsoptionen für den JWT-gesicherten Autorisierungsantwortmodus (JARM) an. Die vertrauende Partei verwendet die Signatur, um die Integrität und Authentizität der in der JWT-Antwort enthaltenen Tokens zu überprüfen. Das JWT kann zudem so verschlüsselt werden, dass nur die vertrauende Partei es entschlüsseln kann.
    Tabelle 6. JWT-gesicherter Autorisierungsantwortmodus
    Feld Beschreibung
    Signaturalgorithmus Der Algorithmus, den Verify zum Signieren der JWT-Antwort verwendet. Der Algorithmus muss mit dem übereinstimmen, den die vertrauende Partei bei Verify registriert hat.
    Wählen Sie aus den folgenden Hash-Algorithmen:
    • RS256
    • PS256
    • ES256
    • RS384
    • PS384
    • ES384
    • RS512
    • PS512
    • ES512
    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.
    Signaturzertifikat Diese Option wird nur angezeigt, wenn Sie einen der Signaturalgorithmen RS, ES oder PS ausgewählt haben. Verwenden Sie dieses Zertifikat, um die JWT-Antwort beim Single Sign-On zu signieren.

    Die Standardauswahl bezieht sich auf das standardmäßige 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-OAPE-256
    Inhaltsalgorithmus Der Inhaltsverschlüsselungsalgorithmus, der für die authentifizierte Verschlüsselung des Klartexts verwendet wird, um den verschlüsselten Text und den Authentifizierungstag zu erzeugen.
    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.
  9. Konfigurieren Sie die Einstellungen für den Token-Austausch.
    Tabelle 7. Token-Börse
    Feld Beschreibung
    Subjekt-Token Der Token-Typ des betreffenden Tokens, der die Identität der Partei angibt, in deren Namen das Token angefordert wird.
    Akteur-Token Der Token-Typ des Akteur-Tokens, der die Identität der Partei angibt, an die die Zugriffsrechte des ausgestellten Tokens delegiert werden.
    Angefordertes Token

    Die Art von Token, deren Generierung im Rahmen des Token-Austauschs beantragt werden kann.

    Transaktionstoken : Das einmalig verwendbare Sicherheitstoken enthält kontextbezogene Informationen zu einer bestimmten Transaktion, Aktion, Ressource oder Anfrage und ermöglicht so eine detaillierte Autorisierung für diesen speziellen Vorgang. Wenn Sie das Token auswählen, wird die Kachel „Transaktionskontext“ angezeigt, über die Sie den Kontext mithilfe eines CELx-Ausdrucks festlegen können. Weitere Informationen finden Sie unter „Transaktions-Token “.
    Hinweis: Das Transaktionstoken ist eine auf Anfrage verfügbare Funktion, VDEV-186514: Securing AI Agents. Um diese Funktion anzufordern, wenden Sie sich bitte an Ihren Vertriebsmitarbeiter bei IBM oder an Ihren Ansprechpartner bei IBM und teilen Sie ihm mit, dass Sie diese Funktion nutzen möchten. Sie können auch ein Support-Ticket mit der Funktionsnummer erstellen, sofern Sie die entsprechende Berechtigung haben. IBM Verify Mit Probeabonnements können keine Support-Tickets erstellt werden.
    Clientgruppen Die Liste der Clientgruppen von „ OpenID Connect“. Die von diesem Client generierten Token können als Referenz-Token für den Token-Austausch innerhalb derselben Gruppe verwendet werden. Ist diese Liste leer, kann jeder Client die von diesem Client generierten Token als Subjekt-Token für den Token-Austausch verwenden.
    Aktor-Token erforderlich Als Teil der Token-Austausch-Anfrage muss ein Akteurstoken angegeben werden. Diese Maßnahme setzt das Delegationsszenario durch und verhindert das Identitätsübernahmeszenario.
    Transaktionskontext Das Feld „Transaktionskontext“ ist nur sichtbar, wenn das Feld „Angefordertes Token“ auf „Transaktionstoken“ gesetzt ist. Dieses Feld ist für andere Token-Typen nicht relevant. Weitere Informationen finden Sie unter „Transaktions-Token “.
  10. Konfigurieren Sie die Gerätefluss-Einstellungen.
    Tabelle 8. Geräteablauf
    Feld Beschreibung
    QR-Code für Geräteablauf generieren Gibt an, ob zusammen mit dem Benutzercode ein QR-Code generiert wird.
  11. Konfigurieren Sie Anforderungs- und Antwortzuordnungen für jeden der Endpunkte.
    1. Konfigurieren Sie die Anforderungs- und Antwortzuordnung für den Berechtigungsendpunkt.
    2. Konfigurieren Sie die Antwortzuordnung für den Tokenendpunkt.
    3. Konfigurieren Sie das Introspect-Mapping, um Attribute hinzuzufügen und zu ändern, die vom Introspect-Endpunkt zurückgegeben werden.
      Siehe „ OpenID “: Zuordnung von Connect-Introspect, ID-Token und Benutzerinformationen.
    4. Konfigurieren Sie die Zuordnung der Benutzerinformationen und der ID-Token-Attribute, um Attribute hinzuzufügen und zu ändern, die vom userinfo Endpunkt zurückgegeben und im ID-Token enthalten sind.
      Siehe „ OpenID “: Zuordnung von Connect-Introspect, ID-Token und Benutzerinformationen.
  12. Wählen Sie die Identitätsanbieter und die Richtlinie aus, die festlegen, wie Benutzer auf die Anwendung zugreifen können.
    1. Wählen Sie die Identitätsanbieter aus, die für die Anmeldung bei dieser Anwendung verwendet werden können.
      Standardmäßig ist der Zugriff von allen für den Mandanten konfigurierten Identitätsanbietern des Unternehmens zugelassen. Um die Identitätsanbieter einzuschränken, die für die Anmeldung bei der Anwendung verwendet werden können, wählen Sie „Bestimmte unterstützte Identitätsanbieter auswählen “. Aktivieren Sie die Kontrollkästchen für die Identitätsanbieter, über die Sie die Anmeldung zulassen möchten.
    2. Wählen Sie die Richtlinie aus, die festlegt, wie Benutzer auf die Anwendung zugreifen können.
      Sie können die zugewiesene Standardzugriffsrichtlinie weiterhin verwenden. Alternativ können Sie das Kontrollkästchen deaktivieren und die Bearbeiten Schaltfläche klicken, um aus der Liste der vordefinierten Zugriffsrichtlinien auszuwählen. Weitere Informationen finden Sie unter „Zugriffsrichtlinien “.Wenn eine Zugriffsrichtlinie ausgewählt wurde, können Sie diese auf die API-Berechtigungsarten anwenden, indem Sie das Kontrollkästchen für die jeweilige Berechtigungsart aktivieren.
  13. Wählen Sie aus, ob die Benutzerzustimmung angefordert werden soll.
    Die Anforderung für die Benutzerzustimmung kann zu OpenID Connect-Anwendungen hinzugefügt werden. Wenn der Standardwert Zustimmung anfordern ausgewählt bleibt, wird der Benutzer zur expliziten Zustimmung zu Geltungsbereichen und anderen Transaktionsinformationen aufgefordert. Bei Auswahl von Keine Zustimmung anfordern wird keine Zustimmung erfasst, aber die Berechtigungsanforderung ist erfolgreich. Wenn die Option „Nur um nicht erteilte Einwilligungen bitten“ ausgewählt ist, wird der Benutzer nur dazu aufgefordert, seine Einwilligung für diejenigen Punkte zu erteilen, für die noch keine Einwilligung vorliegt.
  14. Schränken Sie angepasste Geltungsbereiche ein.
    Benutzerdefinierte Zugriffsbereiche können von einem OIDC-/OAuth -Client in den unterstützten OIDC -/ OAuth -Berechtigungsablä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.
  15. Details zur Berechtigungsbeschränkung
    Autorisierungsdaten können von einem OIDC-/ OAuth -Client in den unterstützten OIDC-/ OAuth -Autorisierungsabläufen angefordert werden. Wenn die Option „Autorisierungsdetails einschränken“ aktiviert ist, sind die am Ende des Ablaufs gewährten Autorisierungsdetails auf diejenigen beschränkt, die in diesem Abschnitt angegeben sind. Wenn die Option „Autorisierungsdetails einschränken“ deaktiviert ist, werden alle angeforderten Autorisierungsdetails gewährt, sobald der Ablauf abgeschlossen ist.
    1. Stellen Sie sicher, dass das Kontrollkästchen „Autorisierungsdetails einschränken“ aktiviert ist.
    2. Prüfen Sie, ob die Option „Unbekannte Autorisierungsdaten ignorieren“ aktiviert ist.
    3. Geben Sie den Namen der Berechtigungsart ein oder wählen Sie ihn aus, die Sie erteilen möchten. Sie können eine zusätzliche benutzerdefinierte Regel bearbeiten und definieren, um Anfragen anhand einer Eigenschaft in den JSON-Autorisierungsdetails zu filtern. Wenn beispielsweise der Autorisierungsdetailtyp lautet resource_access und eine location Eigenschaft enthält, kann die Anfrage nur genehmigt werden, wenn der Standort Japan ist. In diesem Fall würde die Regel lauten: requestContext.ad.location == 'Japan'.
    4. Klicken Sie auf „Hinzufügen“ und wiederholen Sie den vorherigen Schritt für jede Art von Berechtigungsangabe, die Sie erteilen möchten.
  16. Ordnen Sie dem Anmeldetoken API-Nutzungsrechte 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 Nichtbenutzerberechtigungen aus, die Sie dem Anmeldetoken gewähren möchten.
      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 “.
  17. Wählen Sie „Speichern “.

Nächste Schritte