Autorizzazione con Amazon Verified Permissions

Amazon Verified Permissions è un servizio di autorizzazione per le applicazioni che crei. Quando aggiungi un pool di utenti Amazon Cognito come fonte di identità, la tua app può passare i token di accesso o di identità (ID) al pool di utenti alle Autorizzazioni verificate per consentire o negare una decisione. Verified Permissions considera le proprietà dell'utente e il contesto della richiesta in base alle politiche redatte in Cedar Policy Language. Il contesto della richiesta può includere un identificatore per il documento, l'immagine o l'altra risorsa richiesta e l'azione che l'utente desidera intraprendere sulla risorsa.

L'app può fornire l'identità dell'utente o i token di accesso alle autorizzazioni verificate nelle richieste API. IsAuthorizedWithTokenBatchIsAuthorizedWithToken Queste operazioni API accettano gli utenti come utenti Principal e prendono decisioni di Action autorizzazione per Resource chi desidera accedere. Ulteriori personalizzazioni Context possono contribuire a una decisione di accesso dettagliata.

Quando la tua app presenta un token in una richiesta IsAuthorizedWithToken API, Verified Permissions esegue le seguenti convalide.

1. Il tuo pool di utenti è un'origine di identità di Verified Permissions configurata per il policy store richiesto.

2. La richiesta client_id o aud, rispettivamente, nel tuo token di accesso o di identità, corrisponde all'ID client dell'app pool di utenti che hai fornito a Verified Permissions. Per verificare questa richiesta, devi configurare la convalida dell'ID cliente nella tua fonte di identità Autorizzazioni verificate.

3. Il tuo token non è scaduto.

4. Il valore dell'token_useattestazione nel tuo token corrisponde ai parametri a cui lo hai passatoIsAuthorizedWithToken. L'token_useattestazione deve essere access se l'hai passata al accessToken parametro e id se l'hai passata al identityToken parametro.

5. La firma nel tuo token proviene dalle chiavi web JSON pubblicate (JWK) del tuo pool di utenti. Puoi visualizzare i tuoi JWK su https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json.

Token revocati e utenti eliminati

Verified Permissions convalida solo le informazioni che conosce dalla fonte della tua identità e dalla data di scadenza del token dell'utente. Verified Permissions non verifica la revoca del token o l'esistenza dell'utente. Se hai revocato il token dell'utente o hai eliminato il profilo utente dal tuo pool di utenti, Verified Permissions considera comunque il token valido fino alla scadenza.

Valutazione delle politiche

Configura il tuo pool di utenti come fonte di identità per il tuo policy store. Configura la tua app per inviare i token degli utenti nelle richieste a Verified Permissions. Per ogni richiesta, Verified Permissions confronta le affermazioni contenute nel token con una politica. Una politica di Verified Permissions è come una politica IAM in  AWS. Dichiara un principio, una risorsa e un’azione. Verified Permissions risponde alla tua richiesta indicando Allow se corrisponde a un'azione consentita e non corrisponde a un'Denyazione esplicita; in caso contrario, risponde con. Deny Per ulteriori informazioni, consulta le politiche relative a Amazon Verified Permissions nella Guida per l'utente di Amazon Verified Permissions.

Personalizzazione dei token

Per modificare, aggiungere e rimuovere le affermazioni degli utenti che desideri presentare a Verified Permissions, personalizza il contenuto dei tuoi token di accesso e di identità con un. Trigger Lambda di pre-generazione del token Con un trigger prima della generazione di token, puoi aggiungere e modificare le richieste nei tuoi token. Ad esempio, puoi interrogare un database per gli attributi utente aggiuntivi e codificarli nel tuo token ID.

Nota

A causa del modo in cui Verified Permissions elabora le richieste, non aggiungerle con nome cognito , dev o custom nella funzione di pre-generazione del token. Quando presenti questi prefissi riservati per  richieste non in un formato delimitato da due punti, ad esempio come cognito:username, ma come nomi completi delle richieste, le tue richieste di autorizzazione hanno esito negativo.

Risorse aggiuntive

• Mappatura dei token Amazon Cognito allo schema di autorizzazioni verificate

• Autorizza le API API Gateway utilizzando Amazon Verified Permissions e Amazon Cognito

Autorizzazione API con autorizzazioni verificate

Il tuo ID o i token di accesso possono autorizzare le richieste alle API REST di Amazon API Gateway di back-end con autorizzazioni verificate. Puoi creare un archivio di policy con collegamenti immediati al tuo pool di utenti e alla tua API. Con l'opzione di avvio Configurazione con Cognito e API Gateway, Verified Permissions aggiunge una fonte di identità del pool di utenti al policy store e un autorizzatore Lambda all'API. Quando l'applicazione passa un token portatore del pool di utenti all'API, l'autorizzatore Lambda richiama le autorizzazioni verificate. L'autorizzatore passa il token come principale e il percorso e il metodo della richiesta come azione.

Il diagramma seguente illustra il flusso di autorizzazione per un'API API Gateway con autorizzazioni verificate. Per un'analisi dettagliata, consulta gli archivi di policy collegati alle API nella Amazon Verified Permissions User Guide.

Verified Permissions struttura l'autorizzazione delle API in base ai gruppi di pool di utenti. Poiché sia l'ID che i token di accesso includono un cognito:groups claim, il policy store può gestire il controllo degli accessi basato sui ruoli (RBAC) per le API in una varietà di contesti applicativi.

Scelta delle impostazioni del policy store

Quando si configura un'origine di identità in un policy store, è necessario scegliere se elaborare i token di accesso o ID. Questa decisione è importante per il modo in cui funziona il motore delle policy. I token ID contengono attributi utente. I token di accesso contengono informazioni sul controllo degli accessi degli utenti: ambiti OAuth. Sebbene entrambi i tipi di token contengano informazioni sull'appartenenza al gruppo, in genere consigliamo il token di accesso per RBAC con un archivio di policy di autorizzazioni verificate. Il token di accesso si aggiunge all'appartenenza al gruppo con ambiti che possono contribuire alla decisione di autorizzazione. Le affermazioni in un token di accesso diventano contesto nella richiesta di autorizzazione.

È inoltre necessario configurare i tipi di entità utente e di gruppo quando si configura un pool di utenti come fonte di identità. I tipi di entità sono identificatori principali, di azioni e di risorse a cui puoi fare riferimento nelle politiche di autorizzazione verificate. Le entità negli archivi delle politiche possono avere una relazione di appartenenza, in cui un'entità può essere membro di un'entità principale. Con l'appartenenza, puoi fare riferimento a gruppi principali, gruppi di azione e gruppi di risorse. Nel caso di gruppi di pool di utenti, il tipo di entità utente specificato deve essere un membro del tipo di entità di gruppo. Quando configuri un policy store collegato all'API o segui la configurazione guidata nella console Verified Permissions, il policy store ha automaticamente questa relazione genitore-membro.

Il token ID può combinare RBAC con il controllo degli accessi basato sugli attributi (ABAC). Dopo aver creato un policy store collegato all'API, puoi migliorare le tue policy con gli attributi utente e l'appartenenza ai gruppi. Le dichiarazioni di attributo in un token ID diventano gli attributi principali nella richiesta di autorizzazione. Le tue politiche possono prendere decisioni di autorizzazione in base agli attributi principali.

Puoi anche configurare un policy store per accettare token con un'client_idaffermazione aud or che corrisponda a un elenco di app client accettabili da te fornito.

Esempio di politica per l'autorizzazione delle API basata sui ruoli

La seguente politica di esempio è stata creata configurando un archivio di criteri di autorizzazione verificata per un'API REST di PetStoreesempio.

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

Verified Permissions restituisce una Allow decisione sulla richiesta di autorizzazione dell'applicazione quando:

1. L'applicazione ha passato un ID o un token di accesso in un'Authorizationintestazione come token portatore.

2. L'applicazione ha passato un token con un'cognito:groupsaffermazione che contiene la stringa. MyGroup

3. L'applicazione ha inviato una HTTP GET richiesta, ad esempio, a https://myapi.example.com/pets ohttps://myapi.example.com/pets/scrappy.

Esempio di policy per un utente Amazon Cognito.

Il tuo pool di utenti può anche generare richieste di autorizzazione a Verified Permissions in condizioni diverse dalle richieste API. Puoi inviare qualsiasi decisione di controllo degli accessi contenuta nella tua applicazione al tuo policy store. Ad esempio, puoi integrare la sicurezza di Amazon DynamoDB o Amazon S3 con il controllo degli accessi basato sugli attributi prima che le richieste transitino sulla rete, riducendo l'utilizzo delle quote.

L'esempio seguente utilizza il Cedar Policy Language per consentire agli utenti Finance che si autenticano con un client dell'app pool di utenti di leggere e scrivere example_image.png. John, un utente della tua app, riceve un token ID dal client dell'app e lo trasmette in una richiesta GET a un URL che richiede l'autorizzazione, https://example.com/images/example_image.png. Il token ID di John ha una richiesta aud dell'ID client dell'app del pool di utenti 1234567890example. La tua funzione Lambda di prima generazione del token ha anche inserito una nuova affermazione costCenter con un valore, per John, di Finance1234.

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

Il seguente corpo di richiesta restituisce una risposta Allow.

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

Quando desideri specificare un principale in una politica di autorizzazioni verificate, utilizza il seguente formato:

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

Di seguito è riportato un esempio principale per un utente in un pool di utenti con ID us-east-1_Example con ID secondario o ID utente. 973db890-092c-49e4-a9d0-912a4c0a20c7

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

Quando desideri specificare un gruppo di utenti in una politica di autorizzazioni verificate, utilizza il seguente formato:

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

Di seguito è riportato un esempio

Controllo dell'accesso basato sugli attributi

L'autorizzazione con autorizzazioni verificate per le tue app e gli attributi per la funzionalità di controllo degli accessi dei pool di identità di Amazon Cognito AWS per le credenziali sono entrambe forme di controllo degli accessi basato sugli attributi (ABAC). Di seguito è riportato un confronto tra le funzionalità di Verified Permissions e Amazon Cognito ABAC. In ABAC, un sistema esamina gli attributi di un'entità e prende una decisione di autorizzazione in base a condizioni definite dall'utente.

Servizio	Processo	Risultato
Autorizzazioni verificate da Amazon	Restituisce una Deny decisione Allow or dall'analisi di un pool di utenti JWT.	L'accesso alle risorse dell'applicazione riesce o fallisce in base alla valutazione delle politiche Cedar.
Pool di identità di Amazon Cognito (attributi per il controllo degli accessi)	Assegna i tag di sessione all'utente in base ai suoi attributi. Le condizioni delle policy IAM possono controllare i tag Allow o Deny l'accesso degli utenti a Servizi AWS.	Una sessione con tag con AWS credenziali temporanee per un ruolo IAM.