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à.

Mappatura dei token del provider di identità allo schema

Potresti scoprire di voler aggiungere una fonte di identità a un archivio di politiche e le dichiarazioni del provider di mappe allo schema del tuo archivio di politiche. Puoi automatizzare questo processo o aggiornare lo schema manualmente. Dopo aver mappato i token allo schema, è possibile creare politiche che vi fanno riferimento.

Questa sezione della guida per l'utente contiene le seguenti informazioni:

API-gli archivi di policy collegati e gli archivi di policy con una fonte di identità creati 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 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:

Per utilizzare Amazon Cognito o un provider di OIDC identità (IdP) come fonte di identità nel tuo archivio di policy di Autorizzazioni verificate, devi avere gli attributi del provider nello schema. Lo schema è fisso e deve corrispondere alle entità che i token del provider creano o richiedono. IsAuthorizedWithTokenBatchIsAuthorizedWithTokenAPI Se hai creato il tuo archivio delle politiche in modo da compilare automaticamente lo schema a partire dalle informazioni del provider 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 che corrispondono alle entità create utilizzando API le richieste. È quindi possibile 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.

Mappatura dei token ID allo 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 access control () basato sugli attributi. ABAC Se desideri che Verified Permissions analizzi l'accesso alle risorse in base a chi effettua la richiesta, scegli i token ID come fonte di identità.

Token ID Amazon Cognito

I token ID Amazon Cognito funzionano con la maggior parte delle OIDC librerie relying-party. Estendono le funzionalità di con reclami aggiuntivi. OIDC L'applicazione può autenticare l'utente con le operazioni di API autenticazione dei pool di utenti di Amazon Cognito o con l'interfaccia utente ospitata dal pool di utenti. Per ulteriori informazioni, consulta Using the API and endpoints nella Amazon Cognito Developer Guide.

Nelle politiche che fanno riferimento agli attributi di Amazon Cognito con un : separatore, fai riferimento agli attributi nel formato. principal["cognito:username"] L'affermazione dei ruoli 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 dell'archivio delle politiche 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
         }
      }
   }
}

Per un esempio di politica che verrà convalidata rispetto a questo schema, vedi. Riflette gli attributi del token Amazon Cognito ID

OIDCToken ID

Lavorare con i token ID di un OIDC provider è molto simile a lavorare con i token ID di Amazon Cognito. La differenza sta nelle affermazioni. Il tuo IdP potrebbe presentare OIDCattributi standard o avere uno schema personalizzato. Quando crei un nuovo archivio di politiche nella console Verified Permissions, puoi aggiungere una fonte di OIDC identità con un token ID di esempio oppure puoi mappare manualmente le attestazioni dei token agli attributi utente. Poiché Verified Permissions non conosce lo schema degli attributi del tuo IdP, devi fornire queste informazioni.

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 un'origine di OIDC identità.

"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"
         }
      }
   }
}

Per un esempio di politica che verrà convalidata in base a questo schema, vedereRiflette gli OIDC attributi del token ID.

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'APIaccesso. 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:

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.attribute_name Il token di accesso di esempio seguente include sia le client_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 dell'archivio delle politiche 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"
         }
      }
   }
}

Per un esempio di politica che verrà convalidata in base a questo schema, vediRiflette gli attributi del token di accesso di Amazon Cognito.

Mappatura OIDC dei token di accesso

La maggior parte dei token di accesso di OIDC provider esterni si allinea strettamente ai token di accesso di Amazon Cognito. Un token di OIDC accesso 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.attribute_name Il seguente token di OIDC accesso di esempio include affermazioni di base di esempio.

{
    "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 di autorizzazioni verificate. Per ulteriori informazioni sulla modifica dello schema, consultaModifica degli schemi dell'archivio delle politiche 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"
         }
      }
   }
}

Per un esempio di politica che verrà convalidata in base a questo schema, vediRiflette gli attributi del token di OIDC accesso.

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
         }
      }
   }
}

Per un esempio di politica che verrà convalidata in base a questo schema e utilizzerà la notazione a punti, vedere. Utilizza la notazione a punti per fare riferimento agli attributi

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 ai gruppi 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.

RBACnon richiede attributi nello schema

Gli schemi per le fonti di identità dipendono dalle associazioni di entità che crei quando aggiungi 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 sui ruoli. 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 () basata 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 provider di identità e Configurazione guidata nella console Autorizzazioni verificate assegnano le attestazioni dei token ID allo schema. Questo non è il caso delle rivendicazioni relative ai token di accesso. Per aggiungere rivendicazioni di token di accesso non di gruppo allo schema, è necessario modificare lo schema in JSON modalità e aggiungere attributi. commonTypes Per ulteriori informazioni, consulta Mappatura dei token di accesso.

OIDCgroups claim supporta più formati

Quando aggiungi un OIDC provider, 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 policy store. Le autorizzazioni verificate riconoscono le rivendicazioni dei gruppi nei seguenti formati:

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 API di policy collegato. Quando crei un archivio API di policy collegato, devi scegliere se configurare l'autorizzazione per ID o 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 il tuo Gateway. API API Con un OIDC provider, è necessario scegliere un tipo di token quando si aggiunge la fonte dell'identità. Puoi scegliere ID o token di accesso e la tua scelta esclude il tipo di token non scelto dall'elaborazione nel tuo policy store. 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:username 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"
      ]
   }
}

Per un esempio di politica che verrà convalidata rispetto a questo schema, vediUtilizza la notazione tra parentesi per fare riferimento agli attributi del token.