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

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 o nelle richieste. IsAuthorizedWithTokenBatchIsAuthorizedWithTokenAPI Queste API operazioni accettano gli utenti come utenti Principal e prendono decisioni di autorizzazione Action in base ai Resource quali desiderano accedere. Ulteriori personalizzazioni Context possono contribuire a una decisione di accesso dettagliata.

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

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 autorizzazioni verificate è come una IAM politica 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.

APIautorizzazione con autorizzazioni verificate

Il tuo ID o i token di accesso possono autorizzare le richieste al back-end API Amazon REST APIs Gateway con autorizzazioni verificate. Puoi creare un archivio di policy con collegamenti immediati al tuo pool di utenti e. API Con l'opzione di avvio Configura con Cognito e API Gateway, Verified Permissions aggiunge una fonte di identità del pool di utenti al policy store e un autorizzatore Lambda a. API Quando l'applicazione passa un token portatore del pool di utenti aAPI, 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 gateway API con autorizzazioni verificate. Per un'analisi dettagliata, consulta API-linked policy stores nella Amazon Verified Permissions User Guide.

Verified Permissions struttura API l'autorizzazione 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) APIs 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 un archivio di policy di autorizzazioni RBAC 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 API collegato o segui la configurazione guidata nella console Verified Permissions, il tuo policy store ha automaticamente questa relazione genitore-membro.

Il token ID può essere combinato RBAC con il controllo degli accessi basato sugli attributi (). ABAC Dopo aver creato un archivio di policy API collegato, puoi migliorare le tue policy con gli attributi degli utenti 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 basata sui ruoli API

La seguente politica di esempio è stata creata configurando un archivio di criteri di autorizzazione verificata, a titolo di esempio. PetStoreRESTAPI

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:

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 API richieste. 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 GET richiesta a un utente che richiede l'autorizzazione,. URL 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 di principal per un utente in un pool di utenti con ID us-east-1_Example con sub 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 Autorizzazioni verificate e Amazon ABAC Cognito. NelABAC, un sistema esamina gli attributi di un'entità e prende una decisione di autorizzazione in base alle condizioni da te definite.