Geltungsbereiche

Mit dem Geltungsbereichsparameter kann das Zugriffstoken verschiedene Zugriffsebenen für mehrere IAM-Identitätsdomain-APIs erteilen.

Geltungsbereiche bieten eine Möglichkeit, ein Set aus Ressourcen und Vorgängen genauer zu definieren, die ein Zugriffstoken zulässt. Geltungsbereiche stellen das Intent dar. Wenn ein Client ein Zugriffstoken anfragt, geben die angeforderter Geltungsbereiche die Art der Funktion an, mit der ein Client die Darstellung des Zugriffstokens nutzen möchte.

Darüber hinaus verwenden verschiedene Anwendungstypen unterschiedliche Zugriffstokenberechtigungen. Vertrauenswürdige Anwendungen (wie Backend-Services) können Zugriffstoken direkt im Namen von Benutzern anfordern. Webanwendungen müssen in der Regel zuerst die Identität des Benutzers validieren und optional die Zustimmung des Benutzers einholen.

Verwenden Sie den Geltungsbereich urn:opc:idm:__myscopes__, wenn Sie ein Zugriffstoken abrufen müssen, das alle zugelassenen Identitätsdomaingeltungsbereiche enthält. Zugriffstoken werden zurückgegeben, die alle anwendbaren Identitätsdomaingeltungsbereiche enthalten, basierend auf den Berechtigungen, die durch die Identitätsdomainanwendungsrollen dargestellt werden, die dem anfordernden Client erteilt wurden, und dem Benutzer, der durch die Anforderung des Clients angegeben wird (sofern vorhanden). Dieser Geltungsbereich wird keiner Identitätsdomainadministratorrolle direkt erteilt.

Verwenden Sie den Geltungsbereich urn:opc:idm:role.<r_name> (Beispiel: urn:opc:idm:role.User%20Administrator), wenn Sie ein Zugriffstoken abrufen müssen, das die anwendbaren Geltungsbereiche einer bestimmten Rolle enthält, vorausgesetzt, dem Client und dem Benutzer wird die spezifische Rolle erteilt. Beispiel: So fordern Sie ein Zugriffstoken mit einem rollenbasierten Geltungsbereich von Benutzeradministrator und Anwendungsadministrator an:

Anforderungsbeispiel

curl -i
-H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
--request POST https://<domainURL>/oauth2/v1/token 
-d 'grant_type=password&username=<user-name>&password=<example-password>&client_id=<client-id>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<client-assertion>&scope=urn:opc:idm:role.User%2520Administrator urn:opc:idm:role.Application%2520Administrator'

Das generierte Zugriffstoken würde die anwendbaren Geltungsbereiche für den Benutzeradministrator und den Anwendungsadministrator enthalten, solange sowohl dem Client als auch dem Benutzer diese Rollen erteilt werden. Beispiel: Ein Client hat Role1, Role2 und Role3. Ein Benutzer hat Role1, Role2 und Rolle 4. Die in der Anforderung für das Zugriffstoken enthaltenen Geltungsbereiche sind Role1 und Role3. Das generierte Zugriffstoken enthält nur Geltungsbereiche für Role1.

Geltungsbereichansprüche können mehrere durch Leerzeichen getrennte Geltungsbereiche aufweisen. Wenn ein Geltungsbereichsname ein Leerzeichen enthält, kann der Server die richtige Geltungsbereichsgrenze nicht bestimmen. Dies kann passieren, wenn ein Rollenname im Geltungsbereich verwendet wird. Im Anforderungsbeispiel weisen die Rollen "Benutzeradministrator" und "Anwendungsadministrator" Leerzeichen auf, die URL-codiert wurden: scope=urn:opc:idm:role.User%2520Administrator urn:opc:idm:role.Application%2520Administrator.

Um Speicherplatzprobleme bei Rollennamen zu vermeiden, müssen Sie die Rollennamen zweimal mit URL-Codierung codieren:

Beispiel-Java-Code

String scope = "scope=urn:opc:idm:role." + URLEncoder.encode(URLEncoder.encode("User Administrator", "UTF-8"), "UTF-8");
scope = scope + " urn:opc:idm:role." + URLEncoder.encode(URLEncoder.encode("Application Administrator", "UTF-8"), "UTF-8");

Keine Geltungsbereiche für eine App definiert

Wenn keine Geltungsbereiche für eine Anwendung definiert sind (z.B. wenn der Benutzer sich einfach anmelden und ein OAuth-Zugriffstoken anfordern soll), können die folgenden Geltungsbereiche in browserbasierten Anmeldeablaufanforderungen an den /oauth2/v1/authorize-Endpunkt angegeben werden:

scope=openid: Das resultierende Zugriffstoken kann mit /oauth2/c1/userinfo verwendet werden, das die Bare-Mindestbenutzerinformationen bereitstellt.
scope=openid approles groups: Das resultierende Zugriffstoken kann mit /oauth2/v1/userinfo verwendet werden, um die Rollen und Gruppen des Benutzers abzurufen.

Vertrauensbereiche verwenden

Vertrauensbereiche definieren, wie ein OAuth-Client auf Ressourcen zugreift. Mit Trust-Geltungsbereichen kann eine vertrauenswürdige oder vertrauliche Clientanwendung ein Zugriffstoken anfordern, das Zugriff auf eine der Ressourcen innerhalb einer Identitätsdomain (Account), auf andere Ressourcen basierend auf definierten Tags (Tags) oder nur auf Services erteilt, bei denen eine explizite Verknüpfung zwischen dem Client und dem Service (Explicit) vorhanden ist.

Hinweis

Die Option zum Definieren des Parameters trustScope ist nur für vertrauenswürdige und vertrauliche Clientanwendungen verfügbar. Die Option ist für öffentliche Clientanwendungen nicht verfügbar.

Verwenden Sie die folgenden Richtlinien, wenn Sie einen Trust Scope verwenden:

Note

The trustScope attributes of Account, Tags, and Explicit are named All (for Account), Tagged (for Tags), and Specific (for Explicit) in the identity domain Console.

Verwenden Sie nur den Geltungsbereich urn:opc:resource:consumer::all in der Anforderung. Ein Fehler wegen eines ungültigen Geltungsbereichs wird zurückgegeben, wenn Sie versuchen, sowohl den Geltungsbereich urn:opc:resource:consumer::all als auch einen anderen Geltungsbereich in dieselbe Anforderung aufzunehmen, wie urn:opc:idm:__myscopes__.
Wenn Sie ein Zugriffstoken mit dem Geltungsbereich urn:opc:resource:consumer::all anfordern, wird kein Zugriffstoken zurückgegeben, das Zugriff auf die Admin-APIs der Identitätsdomains bietet. Sie müssen weiterhin den Geltungsbereich: urn:opc:idm:__myscopes__ verwenden, um auf die Admin-APIs zuzugreifen. Siehe Bereiche.
Der von der Client-App angeforderte Geltungsbereich sollte immer vorhanden und entweder direkt oder hierarchisch zu den definierten zulässigen Geltungsbereichen der Clients übereinstimmen, um dem Client den Zugriff auf die Ressource zu ermöglichen.
Der Wert trustScope von Explicit wird standardmäßig vertrauenswürdigen und vertraulichen Clientanwendungen zugewiesen. Ihre Clientanwendung kann ein Zugriffstoken mit Berechtigungen anfordern, die auf einer expliziten Verknüpfung zwischen dem Client und den Zielservices basieren. Um die Option All oder Tagged zu verwenden, müssen Sie die Clientanwendung entweder mit dem trustScope-Wert All oder Tags. aktualisieren.
Bei Identitätspropagierungstokenanforderungen mit dem Geltungsbereich urn:opc:resource:consumer::all enthält das resultierende Zugriffstoken nicht den Geltungsbereich urn:opc:resource:consumer::all.

Die folgenden Links enthalten weitere Informationen zu jeder trustScope, die verfügbar ist:

Geltungsbereich des Account Trust verwenden

Mit dem Account-Vertrauensgeltungsbereich kann eine vertrauenswürdige oder vertrauliche Clientanwendung ein Zugriffstoken abrufen, das Zugriff auf einen der Services in derselben Identitätsdomain erteilt, ohne dass eine explizite Verknüpfung mit den Zielservices erforderlich ist.

So verwenden Sie den Account Trust Scope:

Weisen Sie den Wert Account dem Parameter trustScope für die entsprechende vertrauenswürdige Clientanwendung zu.

Hinweis

Das Attribut trustScope von Account wird in der Identitätsdomainkonsole als Alle bezeichnet.
Fordern Sie ein Zugriffstoken mit dem vertrauenswürdigen oder vertraulichen Client sowie den Geltungsbereich urn:opc:resource:consumer::all. an Das Zugriffstoken in der Antwort enthält die Zielgruppe urn:opc:resource:scope:account und den Geltungsbereich urn:opc:resource:consumer::all, die Zugriff auf einen der Services in derselben Domain erteilen, ohne dass eine explizite Verknüpfung mit den Zielservices erforderlich ist.

Hinweis

Der angeforderte Geltungsbereich muss immer vorhanden sein und entweder direkt oder hierarchisch mit den definierten zulässigen Geltungsbereichen des Clients übereinstimmen, um dem Client den Zugriff auf die Ressource zu ermöglichen.

Fein granulierte Bereiche verwenden

Zusätzlich zum Geltungsbereich urn:opc:resource:consumer::all können Sie auch die folgenden fein granulierten Geltungsbereiche angeben:

urn:opc:resource:consumer:paas::read
urn:opc:resource:consumer:paas:stack::all
urn:opc:resource:consumer:paas:analytics::read

Der angeforderte Geltungsbereich der Client-App muss entweder direkt oder hierarchisch mit mindestens einem der zulässigen Geltungsbereiche des Clients übereinstimmen, damit der Client auf die Ressource zugreifen kann. Beispiel: Eine Client-App verwendet den Geltungsbereich urn:opc:resource:consumer:paas:analytics::read in ihrer Anforderung für den Zugriff auf eine Ressource. Wenn der Geltungsbereich direkt mit einem definierten zulässigen Geltungsbereich übereinstimmt, lautet die Zielgruppe im zurückgegebenen Zugriffstoken urn:opc:resource:scope:account und der Geltungsbereich urn:opc:resource:consumer:paas:analytics::read..

Wenn der vom Client definierte zulässige Geltungsbereich urn:opc:resource:consumer:paas::read lautet, kann die Clientanwendung hierarchisch auf die Ressource zugreifen, wenn der Client einen der folgenden Geltungsbereiche anfordert: urn:opc:resource:consumer:paas::read oder urn:opc:resource:consumer:paas:analytics::read. Wenn der angeforderte Geltungsbereich jedoch urn:opc:resource:consumer:paas:analytics::write, lautet, darf der Client nicht auf die Ressource zugreifen, da dieser keiner der von der Clientanwendung definierten zulässigen Geltungsbereiche ist

Anforderungs- und Antwortbeispiele

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele für die Clientzugangsdaten und die Zuweisungsabläufe für Ressourceneigentümer.

Beispiel für Clientzugangsdaten-Ablaufanforderung

curl -i 
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg=' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST 'https://<domainURL>/oauth2/v1/token' 
-d 'grant_type=client_credentials&scope=urn:opc:resource:consumer::all' -k

Antwortbeispiel

{
"access_token":"eyJ4NX....Zh3ieBlQ", 
"token_type":"Bearer", 
"expires_in":3600
}

Hinweis

Das Zugriffstoken enthält die Zielgruppe urn:opc:resource:scope:account und den Geltungsbereich urn:opc:resource:consumer::all.

Beispiel für die Ablaufanforderung des Ressourcenverantwortlichen

curl -i 
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg=' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST  https://<domainURL>/oauth2/v1/token' 
-d 'grant_type=password&scope=urn:opc:resource:consumer::all&username=admin@example.com&password=PasswordExample1'-k

Antwortbeispiel

{
"access_token":"eyJ4NX...71aImeBsU",
"token_type":"Bearer", 
"expires_in":3600
}

Anforderungs- und Antwortbeispiele mit einem vollqualifizierten Geltungsbereich

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele mit einem vollqualifizierten Geltungsbereich.

Anforderungsbeispiel

curl -i 
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg=' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST 'https://<domainURL>/oauth2/v1/token' 
-d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'

Antwortbeispiel

{
"access_token":"eyJ4NXzF.....rT5SH7sUw", 
"token_type":"Bearer",
"expires_in":3600 
}

Beispiel für eine Ablaufanforderung des Ressourcenverantwortlichen mit der Anforderung eines Aktualisierungstokens

Um zusätzlich zum Zugriffstoken ein Aktualisierungstoken zu generieren, verwenden Sie den Geltungsbereich urn:opc:resource:consumer::all offline_access in der Anforderung.

curl -i 
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg=' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST https://<domainURL>/oauth2/v1/token' 
-d 'grant_type=password&scope=urn:opc:resource:consumer::all  offline_access&username=admin@example.com&password=PasswordExample1'-k

Antwortbeispiel

{
"access_token":"eyJ4...pNYM0M", 
"token_type":"Bearer", 
"expires_in":3600,
"refresh_token":"AQIDBAUi....djF9NCA=" 
}

Vertrauensbereich für Tags verwenden

Mit dem Tags-Vertrauensbereich kann eine vertrauenswürdige oder vertrauliche Clientanwendung ein Zugriffstoken abrufen, das basierend auf den definierten Tags Zugriff auf andere Ressourcen erteilt.

So verwenden Sie den Tags Trust Scope:

Weisen Sie den Wert Tags dem Parameter trustScope zu, damit die Clientanwendung auf Tags aus anderen Anwendungen zugreifen kann.

Hinweis

Das Attribut trustScope von Tags wird in der Identitätsdomainkonsole als Tagged bezeichnet.
Definieren Sie das key:value-Paar für den Parameter AllowedTags.

Hinweis

Bei diesen Schritten wird davon ausgegangen, dass die entsprechende Ressourcen-App key:value-Paare für das Attribut Tags definiert hat und dass mindestens ein key:value-Paar aus der Liste des Attributs allowedTags der Client-App mit einem key:value-Paar des Attributs Tags der Ressourcen-App übereinstimmt.
Fordern Sie ein Zugriffstoken mit dem vertrauenswürdigen oder vertraulichen Client sowie den Geltungsbereich urn:opc:resource:consumer::all. an Das Zugriffstoken in der Antwort enthält die Zielgruppe urn:opc:resource:scope:tag=<base64 encoded JSON> und den Geltungsbereich urn:opc:resource:consumer::all. Dieser erteilt Zugriff auf Ressourcen-Apps mit Tags, die mit den in der Client-App angegebenen zulässigen Tags übereinstimmen.

Fein granulierte Bereiche verwenden

Zusätzlich zum Geltungsbereich urn:opc:resource:consumer::all können Sie auch die folgenden fein granulierten Geltungsbereiche angeben:

urn:opc:resource:consumer:paas::read
urn:opc:resource:consumer:paas:stack::all
urn:opc:resource:consumer:paas:analytics::read

Der angeforderte Geltungsbereich der Client-App muss entweder direkt oder hierarchisch mit mindestens einem der zulässigen Geltungsbereiche des Clients übereinstimmen, damit der Client auf die Ressource zugreifen kann. Beispiel: Eine Client-App verwendet den Geltungsbereich urn:opc:resource:consumer:paas:analytics::read in ihrer Anforderung für den Zugriff auf eine Ressource. Wenn der Geltungsbereich direkt mit einem definierten zulässigen Geltungsbereich übereinstimmt, lautet die Zielgruppe im zurückgegebenen Zugriffstoken urn:opc:resource:scope:tag=<base64 encoded JSON> und der Geltungsbereich urn:opc:resource:consumer:paas:analytics::read.

Anforderungs- und Antwortbeispiele

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele für den Clientzugangsdatenfluss mit dem Geltungsbereich urn:opc:resource:consumer::all.

Anforderungsbeispiel

curl -i
-H 'Authorization: Basic MjA3Mz....zllNjI2' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST 'https://tenant101.idcs.internal.oracle.com:8943/oauth2/v1/token'
-d 'grant_type=client_credentials&scope=urn:opc:resource:consumer::all'

Antwortbeispiel

{
"access_token""eyJ4NX....ZbDtAw", 
"token_type":"Bearer", "expires_in":3600
}

Hinweis

Das Zugriffstoken enthält die Zielgruppe urn:opc:resource:scope:tag=<base64 encoded JSON> und den Geltungsbereich urn:opc:resource:consumer::all. Im Folgenden finden Sie ein Beispiel für eine entschlüsselte Zielgruppe:

aud:["urn:opc:resource:scope:tag=eyAidGFncyI6WyB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiZ3JlZW4ifSAsICB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiYmx1ZSJ9IF19"]

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele für den Clientzugangsdatenfluss mit einem vollqualifizierten Geltungsbereich.

Anforderungsbeispiel

curl -i
-H 'Authorization: Basic MzRjYz....Q3OWVk' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST 'https://<domainURL>/oauth2/v1/token'
-d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'

Antwortbeispiel

{
"access_token""eyJ4NXzF.....rT5SH7sUw", 
"token_type":"Bearer",
"expires_in":3600 
}

Expliziten Trust-Geltungsbereich verwenden

Der Trust-Geltungsbereich Explicit definiert den Trust-Geltungsbereich nur für die Services, bei denen eine explizite Verknüpfung zwischen dem Client und dem Zielservice vorhanden ist.

Sie müssen nichts tun, um den Explicit Trust Scope zu verwenden, da dies der Standard ist, der einer vertrauenswürdigen und vertraulichen Clientanwendung zugewiesen ist. Um die Option Account oder Tags zu verwenden, müssen Sie die Clientanwendung mit dem trustScope-Wert Account oder Tags. aktualisieren

Hinweis

Das Attribut trustScope von Explicit wird in der Identitätsdomain als Spezifisch bezeichnet.

Siehe Accountvertrauensgeltungsbereich verwenden und Tagsvertrauensgeltungsbereich verwenden.

Anforderungs- und Antwortbeispiele

Die Anforderungs- und Antwortbeispiele zeigen den Ablauf der Clientzugangsdaten mit einem vollqualifizierten Geltungsbereich.

Anforderungsbeispiel

curl -i 
-H 'Authorization: Basic MzRjYz....Q3OWVk' 
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' 
--request POST 'https://<domainURL>/oauth2/v1/token' 
-d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'

Antwortbeispiel

{
"access_token""eyJ4NXzF.....rT5SH7sUw", 
"token_type":"Bearer",
"expires_in":3600 
}

Explizite Vertrauensbereiche aus mehreren Ressourcen verwenden

Der Trust-Geltungsbereich Explicit definiert den Trust-Geltungsbereich nur für die Services, bei denen eine explizite Verknüpfung zwischen dem Client und dem Zielservice vorhanden ist. Sie können mehrere Geltungsbereiche angeben, die zu verschiedenen Ressourcen in einer einzelnen Autorisierungsanforderung oder Tokenanforderung gehören, und im Gegenzug mehrere Zugriffstoken abrufen, wobei jeder Geltungsbereich die Geltungsbereiche für jede Ressource enthält.

So verwenden Sie dieses Feature:

Sie müssen den neu definierten Geltungsbereich urn:opc:resource:multiresourcescope in der Autorisierungsanforderung oder Tokenanforderung angeben. Tokenanforderungen sind nicht erfolgreich, wenn mehrere Geltungsbereiche, die zu verschiedenen Ressourcen gehören, ohne diesen Geltungsbereich angegeben werden.
Der OAuth-Client muss in der Lage sein, die Tokenantwort zu parsen, die mehrere Zugriffstoken enthält, und jedes Token für den Zugriff auf jeden Ressourcenservice verwenden.

Hinweis

Sie können dieses Feature mit allen Berechtigungstypen außer dem impliziten Ablauf verwenden. Siehe Impliziter Berechtigungstyp.

Weitere Informationen zu den expliziten Vertrauensbereichen finden Sie unter Expliziten (spezifischen) Vertrauensbereich verwenden.

Anforderungs- und Antwortbeispiele

Die Anforderungs- und Antwortbeispiele zeigen den Ablauf der Clientzugangsdaten mit einem vollqualifizierten Geltungsbereich.

Anforderungsbeispiel

https://<domainURL>/oauth2/v1/authorize?
      client_id=<client-id>&
      response_type=code&
      redirect_uri=<redirect-url>&
      scope=http://abccorp.com/scope1 http://123corp.com/scope1 openid urn:opc:resource:multiresourcescope

curl -i
-H 'Authorization: Basic MzgzZTU4Z….NTM3YjFm' \
--request POST 'https://<domainURL>/oauth2/v1/token' \
-d 'grant_type=authorization_code' \
-d 'code=AgAgYjc1MzgzNWM2NGQxNDA5…YcxU_XdtfLWXUp1Vn4a5uIHiOn4='

curl -i
-H 'Authorization: Basic MzgzZTU4Z….NTM3YjFm' \
--request POST 'https://<domainURL>/oauth2/v1/token' \
-d 'grant_type=client_credentials' \
-d 'scope=http://abccorp.com/scope1 http://123corp.com/scope1 urn:opc:resource:multiresourcescope

Antwortbeispiel

{
    "tokenResponses":[
        {
            "access_token": "eyJ4NXQjUzI1NiI6InZBV3RzNEo1clE1Z.....1iZDc2NjFjMWJiZjA0OGNhOTkyMWNlN2Q4MThkNDY0YSIsImp0aSI6Ijg53ZFOT2FxyZYjocCnm1b1w",
            "token_type": "Bearer",
            "expires_in": 3600
        },
        {
            "access_token": "eyJ4NXQjUzI1NiI6InZBV3RzNEo1clE1Z.....HplcmtUNjdsU19SjZlYjc5ZDgzMTVhYjQ0ODBiNDlkMjU3NzdkZWMzMDE2In0.k4QShMbO5aPGmYyKo",
            "token_type": "Bearer",
            "expires_in": 3000
        }
    ],
    "id_token": "eyJ4NXQjUzI1NiI6InZBV3RzNEo1clE1ZHplc.....mtUNjdsU19SYjhQTWoYDSVhTUmDl8zK3a9vk7cowIW2hr3smwtcsvfsbrewwtbnCrGerp7v4CUcVYlSw" 
}

Oracle Cloud Infrastructure - Dokumentation

Geltungsbereiche

Vertrauensbereiche verwenden

Geltungsbereich des Account Trust verwenden

Vertrauensbereich für Tags verwenden

Expliziten Trust-Geltungsbereich verwenden

Explizite Vertrauensbereiche aus mehreren Ressourcen verwenden