Scopes

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

Geltungsbereiche bieten eine Möglichkeit, eine Gruppe von Ressourcen und Vorgängen genauer zu definieren, die ein Zugriffstoken zulässt. Geltungsbereiche stellen ein Intent dar. Wenn ein Client ein Zugriffstoken anfordert, geben die angeforderten Geltungsbereiche die Art der Funktion an, die ein Client bei der Darstellung des Zugriffstokens verwenden 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 zulässigen Identitätsdomaingeltungsbereiche enthält. Es werden Zugriffstoken zurückgegeben, die alle anwendbaren Identitätsdomaingeltungsbereiche enthalten, die auf den Berechtigungen basieren, die durch die Anwendungsrollen der Identitätsdomain dargestellt werden, die dem anfordernden Client und dem durch die Anforderung des Clients angegebenen Benutzer (sofern vorhanden) erteilt werden. 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 Bereiche einer bestimmten Rolle enthält, vorausgesetzt, sowohl dem Client als auch 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 enthält die anwendbaren Geltungsbereiche für den Benutzeradministrator und den Anwendungsadministrator, solange sowohl dem Client als auch dem Benutzer diese Rollen erteilt werden. Beispiel: Ein Client hat die Werte 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 korrekte 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:

Java-Beispielcode

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");

Für eine App sind keine Geltungsbereiche definiert

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

scope=openid: Das resultierende Zugriffstoken kann mit /oauth2/c1/userinfo verwendet werden, das die minimalen Benutzerinformationen 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. Trust-Geltungsbereiche ermöglichen es einer vertrauenswürdigen oder vertraulichen Clientanwendung, ein Zugriffstoken anzufordern, das Zugriff auf eine der Ressourcen innerhalb einer Identitätsdomain (Account), auf andere Ressourcen basierend auf definierten Tags (Tags) oder nur auf die Services gewährt, bei denen eine explizite Verknüpfung zwischen dem Client und dem Service (Explicit) vorhanden ist.

Hinweis

Die Option zum Definieren des Parameters trustScope steht nur vertrauenswürdigen und vertraulichen Clientanwendungen zur Verfügung. Die Option ist für öffentliche Clientanwendungen nicht verfügbar.

Beachten Sie die folgenden Richtlinien bei der Verwendung eines Vertrauensbereichs:

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 Geltungsbereiche.
Der von der Client-App angeforderte Bereich muss immer vorhanden sein und entweder direkt oder hierarchisch mit den definierten zulässigen Bereichen des Clients übereinstimmen, um dem Client den Zugriff auf die Ressource zu ermöglichen.
Der trustScope-Wert von Explicit wird vertrauenswürdigen und vertraulichen Clientanwendungen standardmäßig 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 mit dem trustScope-Wert All oder Tags. aktualisieren.
Bei Identitätspropagierungstokenanforderungen, die den Geltungsbereich urn:opc:resource:consumer::all verwenden, enthält das resultierende Zugriffstoken nicht den Geltungsbereich urn:opc:resource:consumer::all.

Die folgenden Links enthalten weitere Informationen zu jeder verfügbaren trustScope:

Treuhandbereich für Accounts verwenden

Der Vertrauensbereich Account ermöglicht es einer vertrauenswürdigen oder vertraulichen Clientanwendung, ein Zugriffstoken abzurufen, das Zugriff auf alle Services in derselben Identitätsdomain gewährt, ohne dass eine explizite Verknüpfung mit den Zielservices erforderlich ist.

So verwenden Sie den Vertrauensbereich Account:

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

Hinweis

Das Attribut trustScope von Account heißt in der Identitätsdomainkonsole Alle.
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, der Zugriff auf alle Services in derselben Domain gewährt, 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 Geltungsbereiche 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 von der Clientanwendung angeforderte Geltungsbereich muss entweder direkt oder hierarchisch mit mindestens einem der zulässigen Geltungsbereiche des Clients übereinstimmen, um dem Client den Zugriff auf die Ressource zu ermöglichen. Beispiel: Eine Clientanwendung verwendet den Bereich urn:opc:resource:consumer:paas:analytics::read in ihrer Anforderung für den Zugriff auf eine Ressource. Wenn der Bereich direkt mit einem definierten zulässigen Bereich übereinstimmt, lautet die Zielgruppe im zurückgegebenen Zugriffstoken urn:opc:resource:scope:account und der Bereich urn:opc:resource:consumer:paas:analytics::read.

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

Beispiele für Anforderungen und Antworten

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele für die Clientzugangsdaten und die Erteilungsflüsse des Ressourceneigentümers.

Ablaufanforderung für Clientzugangsdaten - Beispiel

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.

Ablaufanforderung für Ressourceneigentümer - Beispiel

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 Ressourceneigentümers 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=" 
}

Verwenden des Tags Trust Scope

Der Vertrauensbereich Tags ermöglicht es einer vertrauenswürdigen oder vertraulichen Clientanwendung, ein Zugriffstoken abzurufen, das basierend auf den definierten Tags Zugriff auf andere Ressourcen gewährt.

So verwenden Sie den Vertrauensbereich Tags:

Weisen Sie dem Parameter trustScope den Wert Tags zu, damit die Clientanwendung auf Tags von 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 Ressourcenanwendung key:value-Paare für das Attribut Tags definiert hat und dass mindestens ein key:value-Paar aus der Liste des Attributs allowedTags der Clientanwendung mit einem key:value-Paar des Attributs Tags der Ressourcenanwendung ü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 Geltungsbereiche 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 von der Clientanwendung angeforderte Geltungsbereich muss entweder direkt oder hierarchisch mit mindestens einem der zulässigen Geltungsbereiche des Clients übereinstimmen, um dem Client den Zugriff auf die Ressource zu ermöglichen. Beispiel: Eine Clientanwendung verwendet den Bereich urn:opc:resource:consumer:paas:analytics::read in ihrer Anforderung für den Zugriff auf eine Ressource. Wenn der Bereich direkt mit einem definierten zulässigen Bereich ü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.

Beispiele für Anforderungen und Antworten

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele für den Ablauf der Clientzugangsdaten 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 dekodierte Zielgruppe:

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

Die folgenden Beispiele zeigen Anforderungs- und Antwortbeispiele für 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 
}

Explizites Vertrauen verwenden

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

Sie müssen nichts unternehmen, um den Vertrauensbereich Explicit zu verwenden, weil 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 Account-Trust-Geltungsbereich verwenden und Tags-Trust-Geltungsbereich verwenden.

Beispiele für Anforderungen und Antworten

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 Vertrauensbereich Explicit definiert den Vertrauensbereich nur für die Services, bei denen eine explizite Verknüpfung zwischen dem Client und dem Zielservice vorhanden ist. Sie können in einer einzelnen Autorisierungsanforderung oder Tokenanforderung mehrere Geltungsbereiche angeben, die zu verschiedenen Ressourcen gehören, und im Gegenzug mehrere Zugriffstoken abrufen, die jeweils die Geltungsbereiche für jede Ressource enthalten.

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 die Tokenantwort, die mehrere Zugriffstoken enthält, parsen und jedes Token für den Zugriff auf jeden Ressourcenservice verwenden können.

Hinweis

Sie können dieses Feature mit allen Berechtigungstypen mit Ausnahme des Ablaufs "Implizit" verwenden. Siehe Zugriffsberechtigungstyp "Implizit".

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

Beispiele für Anforderungen und Antworten

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

Scopes

Vertrauensbereiche verwenden

Treuhandbereich für Accounts verwenden

Verwenden des Tags Trust Scope

Explizites Vertrauen verwenden

Explizite Vertrauensbereiche aus mehreren Ressourcen verwenden