OpenID Connect-Anforderungszuordnung für Zustimmungsanforderungen

Online bearbeiten

In einem OAuth- und Open ID Connect-Berechtigungsablauf kann Benutzern eine Eingabeaufforderung für eine Zustimmung angezeigt werden, von der eine Berechtigung angefordert wird.

Im Rahmen eines Berechtigungsablaufs kann eine Berechtigung zur Ausführung der folgenden Aktionen angefordert werden.
  • Daten aus dem Profil des Benutzers gemeinsam nutzen, z. B. die E-Mail-Adresse. Diese Anforderung kann optional durch Informationen ergänzt werden, die den Zweck angeben, für den die Daten gemeinsam genutzt werden.
  • Aktionen im Namen des Benutzers ausführen, z. B. das Fahrzeug des Benutzers starten und an einem kalten Tag heizen oder eine Zahlung einleiten.
In der Regel fordern Anwendungen die Aktion in Form des scope Parameters an. Manchmal kann es jedoch vorkommen, dass die Anfrage geändert werden muss. Beispiel:
  • Überprüfen Sie stets den Autorisierungsstatus des Nutzers im Hinblick auf die Nutzungsvereinbarung.
  • Bestimmte scope-Werte basierend auf der Authentifizierungssitzung des Benutzers herausfiltern.
  • Fügen Sie weiteren Kontext hinzu, aus dem hervorgeht, warum Daten angefordert werden, ob sie entweder in scope codiert sind (z. B. email_for_billing) oder als Teil eines anderen Anforderungsparameters (z. B. authorization_details) verfügbar sind.

Dieser Änderungstyp kann mithilfe der angepassten Regel des Zustimmungsanforderungsparameters erreicht werden. Siehe r_attr_functions.html. Die Regel kann mit einer einfachen einzeiligen Ausdruckssprache oder als erweitertes mehrzeiliges YAML-basiertes Dokument geschrieben werden. Informationen hierzu finden Sie unter Steuerprogramm für mehrzeilige Regeln.

Verfügbare Eingabeobjekte

Da diese angepasste Regel nach der Authentifizierung, aber vor der Autorisierung ausgeführt wird, enthalten die verfügbaren Informationen nicht alle möglichen Domänenobjekte. Sie sind auf die folgenden Typen beschränkt:

HTTP-Anforderungskontext
Wenn sich ein Benutzer an Verify anmeldet, kann in der Regel zur Anforderungszuordnung auf den Kontext der eingehenden HTTP-Anforderung zugegriffen werden. Alle OAuth-Anforderungsparameter, wie claims oder scope, sind in dieser Version von requestContext verfügbar. Der allgemeine Aufbau und die Verwendung von requestContext werden im Abschnitt „ HTTP -Request-Kontext“ des Dokuments „ r_attr_functions.html “ beschrieben.
Zur Vereinfachung des Zugriffs werden bestimmte Werte vorab in requestContext berechnet. Der claims Anfrageparameter wird wie im folgenden Beispiel als JSON dargestellt.
{
    "id_token": { 
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    },
    "userinfo": {
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    }
}

Da der Zugriff auf diese JSON-Datei umständlich sein kann, weist der in requestContext verwendete Schlüssel das Format claims_claimType_claimName auf. claimType ist entweder userinfo oder idtoken. Beachten Sie den fehlenden Unterstrich. Im vorherigen Beispiel kann der Wert claim_name mithilfe von requestContext.getValue('claims_idtoken_claim_name') abgerufen werden.

In ähnlicher Weise wird scope berechnet und durch ein Leerzeichen getrennt, um ein Zeichenfolgearray zu erstellen.

Identitätsquellenberechtigungsnachweis

Wenn sich ein Benutzer an Verify anmeldet, werden die Attribute der Berechtigungsnachweise der Identitätsquelle zur Anmeldesitzung hinzugefügt; auf diese kann in der Regel zur Anforderungszuordnung zugegriffen werden.

Das Domänenobjekt idsuser ist als Zuordnung mit einem Zeichenfolgeschlüssel und einem Zeichenfolgearraywert verfügbar. Beispiel:
{
  "realmName": ["cloudIdentityRealm"],
  "displayName": ["Jessica J. Hill"],
  "phone": ["+12324321234"]
}
Weitere Informationen finden Sie unter r_attr_functions.html.
Weitere Funktionen und Operatoren

Die Zuordnungsregel enthält Standardoperatoren und -funktionen. Der HTTP-Client ist auch für abgehende Anforderungen verfügbar. Weitere unterstützte Funktionen sind Hashing und Zeitmarken. Siehe die entsprechenden Abschnitte im „ r_attr_functions.html “.

Objekt zurückgeben

Es wird erwartet, dass die angepasste Regel ein Array zurückgibt, das Zeichenfolgen oder Objekte enthält. Die Zeichenfolgen sind Bereiche, während die Objekte Bereiche mit zusätzlichen Informationen sind, um sie einem Datenschutzzweck zuzuordnen. Siehe .. /tasks/t_manage_purposes.html.

Der folgende Code ist ein Beispiel für ein Rückgabeobjekt. marketingWenn der Benutzer dem ersten Anforderungsobjekt zustimmt, wird eine Einwilligung für das email Attribut erstellt. Außerdem wird der Geltungsbereich personal:email gewährt und die Anforderung personal_email_allowed wird dem ID-Token hinzugefügt.

[
	{
		"purpose": "marketing",
		"attribute": "email",
		"accessType": "read",
		"value": "jhill@ibm.com",
		"custom": {
			"type": "personal"
		},
		"claims": {
			"personal_email_allowed": true
		},
		"scope": "personal:email"
	},
    {
        "purpose": "defaultEULA"
    },
	"profile",
	"email"
] + requestContext.scope
Hinweis:

Die hier aufgeführte Liste ersetzt die angeforderten Geltungsbereiche vollständig und wird zum Erstellen der Zustimmungsseite verwendet. Siehe „Single Sign-On für OpenID -Seiten anpassen “. Wenn Sie den Benutzer um weitere Zustimmung bitten möchten, müssen Sie requestScope.scope wie im Beispiel zum Hinzufügen und Entfernen von Gültigkeitsbereichen erläutert anhängen.

Im Beispiel kann das Array zwei Typen aufweisen - den OAuth-Gültigkeitsbereich als Zeichenfolge und ein Objekt, das über mehr Kontext verfügt und dessen Ergebnis ein Datensatz mit einer differenzierteren Zustimmungsberechtigung ist. Diese Eigenschaften sind die Eigenschaften, die im Objekt zulässig sind.

Eigenschaft Typ Erforderlich? Beschreibung
purpose Zeichenfolge Ja ../tasks/t_manage_purposes.html
attribute Zeichenfolge Abhängig vom Zweck Attribute verwalten
accessType Zeichenfolge Abhängig vom Zweck Der Zugriffstyp wird mit dem Datenschutzzweck konfiguriert. Wird kein Wert angegeben, wird standardmäßig default verwendet.
value Zeichenfolge Nein Gibt eine spezifischere Zustimmungsanforderung an. Beispiel: Zustimmung für eine bestimmte E-Mail.
custom JSON-Objekt. Der Typ des JSON-Eigenschaftswerts ist eine Zeichenfolge. Nein Alle zusätzlichen Kontextinformationen, die der Zustimmung hinzugefügt werden sollen. Diese Eigenschaft kann auf der Einwilligungsseite in Form von Vorlagenmakros angezeigt werden.
claim JSON-Objekt. Der Typ des JSON-Eigenschaftswerts ist eine Zeichenfolge. Nein Wenn die Anforderung autorisiert ist, werden dem ausgegebenen ID-Token entsprechende Ansprüche hinzugefügt.
scope Zeichenfolge Nein Wenn die Anforderung berechtigt ist, wird dieser Wert den erteilten Bereichen hinzugefügt.
required Boolesch Nein Wenn required auf „true“ gesetzt ist, muss der Benutzer zustimmen. Diese Einwilligung ist nicht erforderlich, wenn in den Datenschutzbestimmungen angegeben ist, dass die Einwilligung unter keinen Umständen akzeptiert werden kann.
autoGrant Boolesch Nein Wenn autoGrant auf „true“ gesetzt ist, wird der Benutzer nicht um seine Zustimmung gebeten, und der Einwilligungspunkt wird automatisch genehmigt.
global Boolesch Nein Wenn global auf „true“ gesetzt ist, gilt die erfasste Einwilligung global für alle Anwendungen. Diese Eigenschaft ist für Zustimmungselemente relevant, wie beispielsweise Nutzungsbedingungen, denen der Benutzer nur einmal zustimmt.
audience Zeichenfolge Nein Wird die Anfrage genehmigt, wird dieser Wert zusammen mit der in der Anwendung konfigurierten Zielgruppenliste und der Standard-Client-ID zu den genehmigten Zielgruppen hinzugefügt.
Beispiel für das Hinzufügen und Entfernen von Bereichen
In diesem Beispiel wird ein neues Objekt für eine Zustimmungsanforderung hinzugefügt und ein Bereich entfernt.
[
   {
       "purpose": "defaultEula",
       "scope": "eula:default"
   }
] + requestContext.scope.filter(x, x != "badscope")

Diese Regel erteilt dem Bereich eula:default die Autorisierung und ordnet ihn der EULA-Zustimmung zu. Außerdem filtert sie badscope aus den angeforderten Bereichen heraus.

Die Zustimmungsseite kann so angepasst werden, dass die Details der Zustimmungsanforderung angezeigt werden, die über diese Zuordnungsregel hinzugefügt wurden. Ein Beispiel finden Sie unter „ OpenID : Zuordnung von Connect-Anfragen zur Open-Banking-Intent-ID“.