Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo delle fonti di identità negli schemi e nelle politiche
Potresti scoprire di voler aggiungere una fonte di identità a un Policy Store e le dichiarazioni di un provider di mappe allo schema del tuo Policy Store. Puoi automatizzare questo processo o aggiornare lo schema manualmente. Questa sezione della guida per l'utente contiene le seguenti informazioni:
-
Quando è possibile compilare automaticamente gli attributi in uno schema di policy store
-
Come utilizzare le attestazioni relative ai token Amazon Cognito e OIDC nelle politiche relative alle autorizzazioni verificate
-
Come creare manualmente uno schema per una fonte di identità
Gli archivi di policy collegati alle API e gli archivi di policy con una fonte di identità tramite la configurazione guidata non richiedono la mappatura manuale degli attributi del token di identità (ID) allo schema. Puoi fornire autorizzazioni verificate con gli attributi del tuo pool di utenti o con i token OIDC e creare uno schema popolato con attributi utente. Nell'autorizzazione con token ID, Verified Permissions associa le rivendicazioni agli attributi di un'entità principale. Potrebbe essere necessario mappare manualmente i token Amazon Cognito al tuo schema nelle seguenti condizioni:
-
Hai creato un policy store o un policy store vuoto a partire da un esempio.
-
Desiderate estendere l'uso dei token di accesso oltre il controllo degli accessi basato sui ruoli (RBAC).
-
Puoi creare archivi di policy con l'API REST di Verified Permissions, un SDK o il. AWS AWS CDK
Per utilizzare Amazon Cognito o un provider di identità OIDC (IdP) come fonte di identità nel tuo archivio di policy per le autorizzazioni verificate, devi avere gli attributi del provider nello schema. Se hai creato il tuo archivio di politiche in modo da compilare automaticamente lo schema a partire dalle informazioni del fornitore in un token ID, sei pronto per scrivere le policy. Se crei un policy store senza uno schema per la tua origine di identità, devi aggiungere gli attributi del provider allo schema. Lo schema deve corrispondere alle entità create dai token del provider IsAuthorizedWithTokeno alle richieste BatchIsAuthorizedWithToken API. Quindi puoi scrivere politiche utilizzando gli attributi del token del provider.
Per ulteriori informazioni sull'utilizzo dell'ID Amazon Cognito e dei token di accesso per gli utenti autenticati in Autorizzazioni verificate, consulta Authorization with Amazon Verified Permissions nella Amazon Cognito Developer Guide.
Argomenti
Cose da sapere sulla mappatura degli schemi
La mappatura degli attributi differisce tra i tipi di token
Nell'autorizzazione del token di accesso, Verified Permissions mappa le rivendicazioni in base al contesto. Nell'autorizzazione tramite token ID, Verified Permissions associa le rivendicazioni agli attributi principali. Per gli archivi di policy creati nella console Verified Permissions, solo gli archivi di policy vuoti e di esempio non lasciano alcuna fonte di identità e richiedono di compilare lo schema con gli attributi del pool di utenti per l'autorizzazione del token ID. L'autorizzazione dei token di accesso si basa sul controllo degli accessi basato sui ruoli (RBAC) con attestazioni di appartenenza al gruppo e non associa automaticamente altre attestazioni allo schema del policy store.
Gli attributi di origine dell'identità non sono obbligatori
Quando crei una fonte di identità nella console Autorizzazioni verificate, nessun attributo viene contrassegnato come obbligatorio. In questo modo si evita che le attestazioni mancanti causino errori di convalida nelle richieste di autorizzazione. È possibile impostare gli attributi come obbligatori in base alle esigenze, ma devono essere presenti in tutte le richieste di autorizzazione.
RBAC non richiede attributi nello schema
Gli schemi per le fonti di identità dipendono dalle associazioni di entità che si creano quando si aggiunge la fonte di identità. Un'origine di identità associa un'attestazione a un tipo di entità utente e un'affermazione a un tipo di entità di gruppo. Queste mappature di entità sono il fulcro di una configurazione di origine dell'identità. Con queste informazioni minime, è possibile scrivere politiche che eseguano azioni di autorizzazione per utenti specifici e gruppi specifici di cui gli utenti potrebbero essere membri, in un modello di controllo degli accessi basato sul ruolo (RBAC). L'aggiunta di attestazioni di token allo schema estende l'ambito di autorizzazione del policy store. Gli attributi utente dei token ID contengono informazioni sugli utenti che possono contribuire all'autorizzazione del controllo degli accessi basato sugli attributi (ABAC). Gli attributi di contesto dei token di accesso contengono informazioni come gli ambiti OAuth 2.0 che possono fornire ulteriori informazioni sul controllo degli accessi fornite dal provider, ma richiedono ulteriori modifiche allo schema.
Le opzioni Configura con API Gateway e un'origine di identità e Configurazione guidata nella console Autorizzazioni verificate assegnano le attestazioni del token ID allo schema. Questo non è il caso delle rivendicazioni relative ai token di accesso. Per aggiungere attestazioni di token di accesso non di gruppo allo schema, è necessario modificare lo schema in modalità JSON e aggiungere gli attributi CommonTypes.
L'affermazione dei gruppi OIDC supporta più formati
Quando aggiungi un provider OIDC, puoi scegliere il nome della dichiarazione di gruppo in ID o i token di accesso che desideri associare all'appartenenza al gruppo di un utente nel tuo archivio delle politiche. Le autorizzazioni verificate riconoscono le dichiarazioni dei gruppi nei seguenti formati:
-
Stringa senza spazi:
"groups": "MyGroup" -
Elenco delimitato da spazi:.
"groups": "MyGroup1 MyGroup2 MyGroup3"Ogni stringa è un gruppo. -
Elenco JSON (delimitato da virgole):
"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]
Nota
Verified Permissions interpreta ogni stringa contenuta in una dichiarazione di gruppi separati da spazi come un gruppo separato. Per interpretare il nome di un gruppo con un carattere di spazio come un singolo gruppo, sostituisci o rimuovi lo spazio nell'attestazione. Ad esempio, formatta un gruppo denominato My
Group comeMyGroup.
Scegli un tipo di token
Il modo in cui il policy store funziona con la fonte di identità dipende da una decisione chiave nella configurazione dell'origine dell'identità: se elaborare gli ID o i token di accesso. Con un provider di identità Amazon Cognito, puoi scegliere il tipo di token quando crei un archivio di policy collegato ad API. Quando crei un archivio di policy collegato ad API, devi scegliere se configurare l'autorizzazione per l'ID o i token di accesso. Queste informazioni influiscono sugli attributi dello schema che Verified Permissions applica al tuo policy store e sulla sintassi dell'autorizzatore Lambda per l'API API Gateway. Con un provider OIDC, devi scegliere un tipo di token quando aggiungi la fonte dell'identità. Puoi scegliere ID o token di accesso e la tua scelta esclude che il tipo di token non scelto venga elaborato nel tuo archivio delle polizze. Soprattutto se desideri trarre vantaggio dalla mappatura automatica delle rivendicazioni dei token ID agli attributi nella console Verified Permissions, decidi in anticipo il tipo di token che desideri elaborare prima di creare la tua fonte di identità. La modifica del tipo di token richiede uno sforzo significativo per rifattorizzare le politiche e lo schema. I seguenti argomenti descrivono l'uso degli ID e dei token di accesso con gli archivi delle politiche.
Cedar parser richiede parentesi per alcuni caratteri
Le politiche in genere fanno riferimento agli attributi dello schema in un formato simile. principal.username Nel caso della maggior parte dei caratteri non alfanumerici come :., o / che potrebbero apparire nei nomi delle rivendicazioni dei token, Verified Permissions non è in grado di analizzare un valore di condizione come o. principal.cognito:groups context.ip-address È invece necessario formattare queste condizioni con la notazione tra parentesi nel formato o, rispettivamente. principal["cognito:username"] context["ip-address"] Il carattere di sottolineatura _ è un carattere valido nei nomi delle rivendicazioni e rappresenta l'unica eccezione non alfanumerica a questo requisito.
Uno schema di esempio parziale per un attributo principale di questo tipo è simile al seguente:
"User": { "shape": { "type": "Record", "attributes": { "cognito:username": { "type": "String", "required": true }, "custom:employmentStoreCode": { "type": "String", "required": true, }, "email": { "type": "String", "required": false } } } }
Uno schema di esempio parziale per un attributo di contesto di questo tipo è simile al seguente:
"GetOrder": { "memberOf": [], "appliesTo": { "resourceTypes": [ "Order" ], "context": { "type": "Record", "attributes": { "ip-address": { "required": false, "type": "String" } } }, "principalTypes": [ "User" ] } }
Un esempio di politica per gli attributi che verranno convalidati rispetto a questo schema è simile alla seguente:
permit ( principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup", action, resource ) when { principal["cognito:username"] == "alice" && principal["custom:employmentStoreCode"] == "petstore-dallas" && principal has email && principal.email == "alice@example.com" && context["ip-address"] like "192.0.2.*" };
Mappatura dei token ID sullo schema
Verified Permissions elabora le dichiarazioni relative ai token ID come attributi dell'utente: nomi e titoli, appartenenza al gruppo, informazioni di contatto. I token ID sono molto utili in un modello di autorizzazione ABAC (Attribute-Based Access Control). Se desideri che le autorizzazioni verificate analizzino l'accesso alle risorse in base a chi effettua la richiesta, scegli i token ID come fonte della tua identità.
Token ID Amazon Cognito
I token ID Amazon Cognito funzionano con la maggior parte delle librerie relying-party OIDC. Estendono le funzionalità di OIDC con ulteriori attestazioni. L'applicazione può autenticare l'utente con le operazioni API di autenticazione dei pool di utenti di Amazon Cognito o con l'interfaccia utente ospitata dal pool di utenti. Per ulteriori informazioni, consulta Usare l'API e gli endpoint nella Amazon Cognito Developer Guide.
Affermazioni utili nei token ID di Amazon Cognito
cognito:usernameepreferred_username-
Varianti del nome utente.
sub-
L'identificatore utente univoco (UUID) dell'utente
- Affermazioni con un prefisso
custom: -
Un prefisso per attributi personalizzati del pool di utenti come.
custom:employmentStoreCode - Affermazioni standard
-
Dichiarazioni OIDC standard come
emaile.phone_numberPer ulteriori informazioni, consulta Dichiarazioni standardin OpenID Connect Core 1.0 che incorporano il set di errata 2. cognito:groups-
Appartenenze ai gruppi di un utente. In un modello di autorizzazione basato sul controllo degli accessi basato sui ruoli (RBAC), questa dichiarazione presenta i ruoli che è possibile valutare nelle politiche.
- Reclami transitori
-
Affermazioni che non sono di proprietà dell'utente, ma vengono aggiunte in fase di esecuzione da un trigger Lambda prima della generazione di token del pool di utenti. Le affermazioni transitorie assomigliano alle affermazioni standard ma non rientrano nello standard, ad esempio o.
tenantdepartment
Nelle politiche che fanno riferimento agli attributi di Amazon Cognito con un : separatore, fai riferimento agli attributi nel formato. principal[" L'affermazione dei ruoli cognito:username"]cognito:groups è un'eccezione a questa regola. Verified Permissions associa il contenuto di questa dichiarazione alle entità principali dell'entità utente.
Per ulteriori informazioni sulla struttura dei token ID dei pool di utenti di Amazon Cognito, consulta Using the ID token nella Amazon Cognito Developer Guide.
Il seguente esempio di token ID ha ciascuno dei quattro tipi di attributi. Include l'attestazione specifica di Amazon Cognitocognito:username, l'attestazione personalizzatacustom:employmentStoreCode, l'attestazione standard e l'attestazione email transitoria. tenant
{ "sub": "91eb4550-XXX", "cognito:groups": [ "Store-Owner-Role", "Customer" ], "email_verified": true, "clearance": "confidential", "iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE", "cognito:username": "alice", "custom:employmentStoreCode": "petstore-dallas", "origin_jti": "5b9f50a3-05da-454a-8b99-b79c2349de77", "aud": "1example23456789", "event_id": "0ed5ad5c-7182-4ecf-XXX", "token_use": "id", "auth_time": 1687885407, "department": "engineering", "exp": 1687889006, "iat": 1687885407, "tenant": "x11app-tenant-1", "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111", "email": "alice@example.com" }
Quando crei una fonte di identità con il tuo pool di utenti Amazon Cognito, specifichi il tipo di entità principale con cui Verified Permissions genera nelle richieste di autorizzazione. IsAuthorizedWithToken Le tue politiche possono quindi testare gli attributi di tale principale come parte della valutazione della richiesta. Lo schema definisce il tipo e gli attributi principali per una fonte di identità, quindi è possibile farvi riferimento nelle politiche Cedar.
Specificate anche il tipo di entità di gruppo che desiderate derivare dal claim ID Token Groups. Nelle richieste di autorizzazione, Verified Permissions associa ogni membro della dichiarazione di gruppo a quel tipo di entità di gruppo. Nelle politiche, puoi fare riferimento a quell'entità di gruppo come principale.
L'esempio seguente mostra come riflettere gli attributi del token di identità di esempio nello schema di autorizzazioni verificate. Per ulteriori informazioni sulla modifica dello schema, consultaModifica degli schemi in modalità JSON. Se la configurazione dell'origine dell'identità specifica il tipo principaleUser, puoi includere qualcosa di simile al seguente esempio per rendere tali attributi disponibili a Cedar.
"User": { "shape": { "type": "Record", "attributes": { "cognito:username": { "type": "String", "required": false }, "custom:employmentStoreCode": { "type": "String", "required": false }, "email": { "type": "String" }, "tenant": { "type": "String", "required": true } } } }
Dopo aver aggiornato lo schema in modo che rifletta gli attributi di Amazon Cognito, puoi creare policy che fanno riferimento agli attributi.
permit ( principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup", action, resource ) when { principal["cognito:username"] == "alice" && principal["custom:employmentStoreCode"] == "petstore-dallas" && principal.tenant == "x11app-tenant-1" && principal has email && principal.email == "alice@example.com" };
Token ID OIDC
Lavorare con i token ID di un provider OIDC è molto simile a lavorare con i token ID di Amazon Cognito. La differenza sta nelle affermazioni. Il tuo IdP potrebbe presentare attributi OIDC standard
Per ulteriori informazioni, consulta Creazione di archivi di policy per le autorizzazioni verificate.
Di seguito è riportato uno schema di esempio per un policy store con una fonte di identità OIDC.
"User": { "shape": { "type": "Record", "attributes": { "email": { "type": "String" }, "email_verified": { "type": "Boolean" }, "name": { "type": "String", "required": true }, "phone_number": { "type": "String" }, "phone_number_verified": { "type": "Boolean" } } } }
La seguente politica si applica ai membri di un gruppo del provider OIDC.
permit ( principal in MyCorp::UserGroup::"MyOIDCProvider|MyUserGroup", action, resource ) when { principal.email_verified == true && principal.email == "alice@example.com" && principal.phone_number_verified == true && principal.phone_number like "+1206*" };
Mappatura dei token di accesso
Verified Permissions elabora le dichiarazioni dei token di accesso diverse da quelle dichiarate dai gruppi come attributi dell'azione o attributi di contesto. Oltre all'appartenenza al gruppo, i token di accesso del tuo IdP potrebbero contenere informazioni sull'accesso alle API. I token di accesso sono utili nei modelli di autorizzazione che utilizzano il controllo degli accessi basato sui ruoli (RBAC). I modelli di autorizzazione che si basano su richieste di token di accesso diverse dall'appartenenza al gruppo richiedono uno sforzo aggiuntivo nella configurazione dello schema.
Mappatura dei token di accesso di Amazon Cognito
I token di accesso di Amazon Cognito hanno affermazioni che possono essere utilizzate per l'autorizzazione:
Affermazioni utili nei token di accesso di Amazon Cognito
client_id-
L'ID dell'applicazione client di un relying party dell'OIDC. Con l'ID client, Verified Permissions può verificare che la richiesta di autorizzazione provenga da un client autorizzato per il policy store. Nell'autorizzazione machine-to-machine (M2M), il sistema richiedente autorizza una richiesta con un segreto del cliente e fornisce l'ID e gli ambiti del client come prova dell'autorizzazione.
scope-
Gli ambiti OAuth 2.0
che rappresentano i permessi di accesso del portatore del token. cognito:groups-
Appartenenze ai gruppi di un utente. In un modello di autorizzazione basato sul controllo degli accessi basato sui ruoli (RBAC), questa dichiarazione presenta i ruoli che è possibile valutare nelle politiche.
- Reclami transitori
-
Affermazioni che non sono un'autorizzazione di accesso, ma vengono aggiunte in fase di esecuzione da un trigger Lambda di generazione precedente al token di un pool di utenti. Le affermazioni transitorie assomigliano alle affermazioni standard ma non rientrano nello standard, ad esempio o.
tenantdepartmentLa personalizzazione dei token di accesso aggiunge costi alla bolletta. AWS
Per ulteriori informazioni sulla struttura dei token di accesso dei pool di utenti di Amazon Cognito, consulta Using the access token nella Amazon Cognito Developer Guide.
Un token di accesso Amazon Cognito viene mappato su un oggetto di contesto quando viene passato a Autorizzazioni verificate. È possibile fare riferimento agli attributi del token di accesso utilizzando. context.token. Il token di accesso di esempio seguente include sia le attribute_nameclient_id scope attestazioni che.
{ "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e", "cognito:groups": [ "Store-Owner-Role", "Customer" ], "iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE", "client_id": "1example23456789", "origin_jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111", "event_id": "bda909cb-3e29-4bb8-83e3-ce6808f49011", "token_use": "access", "scope": "MyAPI/mydata.write", "auth_time": 1688092966, "exp": 1688096566, "iat": 1688092966, "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222", "username": "alice" }
L'esempio seguente mostra come riflettere gli attributi del token di accesso di esempio nello schema di autorizzazioni verificate. Per ulteriori informazioni sulla modifica dello schema, consultaModifica degli schemi in modalità JSON.
{ "MyApplication": { "actions": { "Read": { "appliesTo": { "context": { "type": "ReusedContext" }, "resourceTypes": [ "Application" ], "principalTypes": [ "User" ] } } }, ... ... "commonTypes": { "ReusedContext": { "attributes": { "token": { "type": "Record", "attributes": { "scope": { "type": "Set", "element": { "type": "String" } }, "client_id": { "type": "String" } } } }, "type": "Record" } } } }
Dopo aver aggiornato lo schema in modo che rifletta gli attributi di Amazon Cognito, puoi creare policy che fanno riferimento agli attributi.
permit(principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource) when { context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" && context.token.scope.contains("MyAPI/mydata.write") };
Mappatura dei token di accesso OIDC
La maggior parte dei token di accesso di provider OIDC esterni si allinea strettamente ai token di accesso di Amazon Cognito. Un token di accesso OIDC viene mappato su un oggetto di contesto quando viene passato a Verified Permissions. È possibile fare riferimento agli attributi del token di accesso utilizzando. context.token. Il seguente token di accesso OIDC include esempi di attestazioni di base.attribute_name
{ "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e", "groups": [ "Store-Owner-Role", "Customer" ], "iss": "https://auth.example.com", "client_id": "1example23456789", "aud": "https://myapplication.example.com" "scope": "MyAPI-Read", "exp": 1688096566, "iat": 1688092966, "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222", "username": "alice" }
L'esempio seguente mostra come riflettere gli attributi del token di accesso di esempio nello schema Verified Permissions. Per ulteriori informazioni sulla modifica dello schema, consultaModifica degli schemi in modalità JSON.
{ "MyApplication": { "actions": { "Read": { "appliesTo": { "context": { "type": "ReusedContext" }, "resourceTypes": [ "Application" ], "principalTypes": [ "User" ] } } }, ... ... "commonTypes": { "ReusedContext": { "attributes": { "token": { "type": "Record", "attributes": { "scope": { "type": "Set", "element": { "type": "String" } }, "client_id": { "type": "String" } } } }, "type": "Record" } } } }
Dopo aver aggiornato lo schema in modo che rifletta gli attributi IdP, puoi creare politiche che fanno riferimento agli attributi.
permit( principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource ) when { context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" && context.token.scope.contains("MyAPI-read") };
Notazione alternativa per le dichiarazioni delimitate da due punti di Amazon Cognito
Al momento del lancio di Verified Permissions, lo schema consigliato per il token Amazon Cognito dichiarava «cognito:groupsmi piace» custom:store e convertiva queste stringhe delimitate da due punti per utilizzare . il carattere come delimitatore gerarchico. Questo formato è chiamato notazione a punti. Ad esempio, un riferimento a cognito:groups became principal.cognito.groups nelle tue politiche. Sebbene sia possibile continuare a utilizzare questo formato, si consiglia di creare lo schema e le politiche utilizzando la notazione tra parentesi. In questo formato, un riferimento a cognito:groups diventa principal["cognito:groups"] nelle tue politiche. Gli schemi generati automaticamente per i token ID del pool di utenti dalla console Verified Permissions utilizzano la notazione tra parentesi.
Puoi continuare a utilizzare la notazione a punti in schemi e policy creati manualmente per le fonti di identità Amazon Cognito. Non puoi utilizzare la notazione a punti con : o qualsiasi altro carattere non alfanumerico nello schema o nelle politiche per nessun altro tipo di IdP OIDC.
Uno schema per la notazione a punti annida ogni istanza di un : carattere come elemento secondario della frase cognito o custom iniziale, come illustrato nell'esempio seguente:
"CognitoUser": { "shape": { "type": "Record", "attributes": { "cognito": { "type": "Record", "required": true, "attributes": { "username": { "type": "String", "required": true } } }, "custom": { "type": "Record", "required": true, "attributes": { "employmentStoreCode": { "type": "String", "required": true } } }, "email": { "type": "String" }, "tenant": { "type": "String", "required": true } } } }
Con uno schema in questo formato, è possibile creare una politica con notazione a punti come nell'esempio seguente:
permit(principal, action, resource) when { principal.cognito.username == "alice" && principal.custom.employmentStoreCode == "petstore-dallas" && principal.tenant == "x11app-tenant-1" && principal has email && principal.email == "alice@example.com" };
