Utilizzo di Amazon Verified Permissions con provider di identità - Autorizzazioni verificate da Amazon

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 di Amazon Verified Permissions con provider di identità

Una fonte di identità è una rappresentazione di un provider di identità esterno (IdP) in Amazon Verified Permissions. Le fonti di identità forniscono informazioni su un utente che si è autenticato con un IdP che ha una relazione di fiducia con il tuo policy store. Quando l'applicazione effettua una richiesta di autorizzazione con un token proveniente da una fonte di identità, il policy store può prendere decisioni di autorizzazione sulla base delle proprietà dell'utente e delle autorizzazioni di accesso. Le fonti di identità Verified Permissions migliorano l'autorizzazione grazie a una connessione diretta all'archivio centrale delle identità e al servizio di autenticazione.

Puoi utilizzare i provider di identità OpenID Connect (OIDCIdPs) con autorizzazioni verificate. L'applicazione può generare richieste di autorizzazione con OIDC identità (ID) o token JSON web di accesso (). JWTs Con i token ID, Verified Permissions legge le dichiarazioni degli utenti IDs e degli attributi come principi per il controllo degli accessi basato sugli attributi (). ABAC Con i token di accesso, Verified Permissions legge l'utente come mandante e le altre attestazioni come contesto. IDs Con entrambi i tipi di token, puoi mappare un claim come se fosse groups un gruppo principale e creare policy che valutino il controllo degli accessi basato sui ruoli (). RBAC

Puoi aggiungere un pool di utenti Amazon Cognito o un OIDC IdP OpenID Connect () personalizzato come fonte di identità.

Utilizzo delle fonti di identità di Amazon Cognito

Verified Permissions lavora a stretto contatto con i pool di utenti di Amazon Cognito. Amazon Cognito JWTs ha una struttura prevedibile. Verified Permissions riconosce questa struttura e trae il massimo vantaggio dalle informazioni in essa contenute. Ad esempio, è possibile implementare un modello di autorizzazione access control (RBAC) basato sui ruoli con token ID o token di accesso.

Una nuova fonte di identità per i pool di utenti di Amazon Cognito richiede le seguenti informazioni:

  • Il Regione AWS.

  • L'ID pool di utenti.

  • Il tipo di entità utente che desideri associare alla fonte della tua identità, ad esempioMyCorp::User.

  • Il tipo di entità di gruppo che desideri associare alla tua fonte di identità, ad esempioMyCorp::UserGroup.

  • (Facoltativo) Il client IDs del tuo pool di utenti che desideri autorizzare a effettuare richieste al tuo policy store.

Poiché Verified Permissions funziona solo con i pool di utenti di Amazon Cognito nello Account AWS stesso account, non puoi specificare una fonte di identità in un altro account. Verified Permissions imposta il prefisso dell'entità, l'identificatore dell'identità e della fonte a cui devi fare riferimento nelle politiche che agiscono sui principali del pool di utenti, all'ID del tuo pool di utenti, ad esempio. us-west-2_EXAMPLE

Le dichiarazioni relative ai token del pool di utenti possono contenere attributi, ambiti, gruppi, client e dati personalizzati. IDs Amazon Cognito JWTs ha la capacità di includere una varietà di informazioni che possono contribuire alle decisioni di autorizzazione nelle autorizzazioni verificate. Ciò include:

  1. Dichiarazioni relative al nome utente e al gruppo con prefisso cognito:

  2. Attributi utente personalizzati con un custom: prefix

  3. Affermazioni personalizzate aggiunte in fase di esecuzione

  4. OIDCaffermazioni standard come sub e email

Tratteremo queste affermazioni in dettaglio e spieghiamo come gestirle nelle politiche sulle autorizzazioni verificate, inMappatura dei token del provider di identità allo schema.

Importante

Sebbene sia possibile revocare i token Amazon Cognito prima della scadenzaJWTs, sono considerati risorse stateless autonome con firma e validità. I servizi conformi al JSON Web Token RFC 7519 dovrebbero convalidare i token da remoto e non sono tenuti a convalidarli con l'emittente. Ciò significa che è possibile che Verified Autorizzations conceda l'accesso in base a un token che è stato revocato o rilasciato a un utente che è stato successivamente eliminato. Per mitigare questo rischio, ti consigliamo di creare i token con la durata di validità più breve possibile e di revocare i token di aggiornamento quando desideri rimuovere l'autorizzazione a continuare la sessione di un utente.

Le politiche Cedar per le fonti di identità del pool di utenti in Verified Permissions utilizzano una sintassi speciale per i nomi delle rivendicazioni che contengono caratteri diversi da quelli alfanumerici e dal carattere di sottolineatura (). _ Ciò include le dichiarazioni di prefisso del pool di utenti che contengono un carattere, come e. : cognito:username custom:department Per scrivere una condizione politica che faccia riferimento al custom:department claim cognito:username o, scrivila rispettivamente come principal["cognito:username"] eprincipal["custom:department"].

Nota

Se un token contiene un'attestazione con un custom: prefisso cognito: or e un nome di attestazione con valore letterale cognito ocustom, una richiesta di autorizzazione con IsAuthorizedWithTokenun. ValidationException

L'esempio seguente mostra come creare una policy che faccia riferimento ad alcune delle dichiarazioni dei pool di utenti di Amazon Cognito associate a un'entità principale.

permit( principal == ExampleCo::User::"us-east-1_example|4fe90f4a-ref8d9-4033-a750-4c8622d62fb6", action, resource == ExampleCo::Photo::"VacationPhoto94.jpg" ) when { principal["cognito:username"]) == "alice" && principal["custom:department"]) == "Finance" };

Per ulteriori informazioni sulla mappatura delle rivendicazioni, consulta. Mappatura dei token ID allo schema Per ulteriori informazioni sull'autorizzazione per gli utenti di Amazon Cognito, consulta Authorization with Amazon Verified Permissions nella Amazon Cognito Developer Guide.

Lavorare con le fonti di identità OIDC

Puoi anche configurare qualsiasi OIDC IdP OpenID Connect () conforme come fonte di identità di un policy store. OIDCi provider sono simili ai pool di utenti di Amazon Cognito: producono JWTs come prodotto di autenticazione. Per aggiungere un OIDC provider, devi fornire un emittente URL

Una nuova fonte di OIDC identità richiede le seguenti informazioni:

  • L'emittente. URL Verified Permissions deve essere in grado di rilevare un .well-known/openid-configuration endpoint in questo modo. URL

  • Il tipo di token che desideri utilizzare nelle richieste di autorizzazione. In questo caso, hai scelto Identity token.

  • Il tipo di entità utente che desideri associare alla fonte della tua identità, ad esempioMyCorp::User.

  • Il tipo di entità di gruppo che desideri associare alla tua fonte di identità, ad esempioMyCorp::UserGroup.

  • Un esempio di token ID o una definizione delle attestazioni nel token ID.

  • Il prefisso che desideri applicare all'entità IDs utente e di gruppo. Alla fine CLIAPI, puoi scegliere questo prefisso. Negli archivi di policy creati con l'opzione Configura con API Gateway e un'origine di identità o l'opzione di configurazione guidata, Verified Permissions assegna un prefisso al nome dell'emittente meno, ad esempio. https:// MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"

L'autorizzazione con fonti di OIDC identità utilizza le stesse API operazioni delle fonti di identità del pool di utenti: and. IsAuthorizedWithTokenBatchIsAuthorizedWithToken

L'esempio seguente mostra come è possibile creare una politica che consenta l'accesso ai report di fine anno ai dipendenti del reparto contabilità, abbiano una classificazione riservata e non lavorino in un ufficio secondario. Verified Permissions ricava questi attributi dalle attestazioni contenute nel token ID del preside.

permit( principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting", action, resource in MyCorp::Folder::"YearEnd2024" ) when { principal.jobClassification == "Confidential" && !(principal.location like "SatelliteOffice*") };

Convalida del cliente e del pubblico

Quando si aggiunge una fonte di identità a un policy store, Verified Permissions dispone di opzioni di configurazione che verificano che l'ID e i token di accesso vengano utilizzati come previsto. Questa convalida avviene durante l'elaborazione delle IsAuthorizedWithToken richieste e. BatchIsAuthorizedWithToken API Il comportamento differisce tra ID e token di accesso e tra Amazon Cognito OIDC e le fonti di identità. Con i provider di pool di utenti di Amazon Cognito, Verified Permissions può convalidare l'ID client sia nell'ID che nei token di accesso. Con OIDC i provider, Verified Permissions può convalidare l'ID client nei token ID e il pubblico nei token di accesso.

Un ID client è un identificatore associato a un'OIDCapplicazione OAuth or configurata con il provider, ad esempio. 1example23456789 Un pubblico è un URL percorso associato al relying party, o destinazione, previsto per l'applicazione di destinazione, ad esempio. https://myapplication.example.com L'audaffermazione non è sempre associata al pubblico.

Verified Permissions esegue la convalida dell'identità, dell'origine, del pubblico e del client come segue:

Amazon Cognito

I token ID Amazon Cognito hanno un'audaffermazione che contiene l'ID client dell'app. I token di accesso hanno un client_id claim che contiene anche l'ID client dell'app.

Quando inserisci uno o più valori per la convalida dell'applicazione Client nella fonte della tua identità, Verified Permissions confronta questo elenco di client IDs dell'app con l'attestazione del token ID o l'audattestazione del token di accesso. client_id Le autorizzazioni verificate non convalidano un pubblico affidabile per le fonti di identità di Amazon URL Cognito.

OIDC

OIDCI token ID hanno un'audattestazione che contiene un elenco di clienti. IDs I token di accesso hanno un aud claim che contiene il pubblico URL del token. I token di accesso hanno anche un'client_idattestazione che contiene l'ID client desiderato.

Puoi inserire uno o più valori per la convalida dell'Audience con un OIDC provider. Quando scegli un tipo di token o token ID, Verified Permissions convalida l'ID cliente, verificando che almeno un membro del cliente indicato IDs nel aud claim corrisponda a un valore di convalida del pubblico.

Verified Permissions convalida il pubblico per i token di accesso, verificando che l'audattestazione corrisponda a un valore di convalida del pubblico. Questo valore del token di accesso deriva principalmente dal claim, ma può provenire dal aud claim cid or client_id se non esiste alcun claim. aud Rivolgiti al tuo IdP per conoscere la dichiarazione e il formato del pubblico corretti.

Un esempio di valore di convalida del pubblico del token ID è. 1example23456789

Un esempio di valore di convalida del pubblico del token di accesso è. https://myapplication.example.com

Autorizzazione lato client per JWTs

Potresti voler elaborare i token JSON web nella tua applicazione e passare le relative dichiarazioni a Verified Permissions senza utilizzare una fonte di identità del Policy Store. Puoi estrarre gli attributi della tua entità da un JSON Web Token (JWT) e analizzarli in Autorizzazioni verificate.

Questo esempio mostra come è possibile chiamare le autorizzazioni verificate da un OIDC IdP.¹

async function authorizeUsingJwtToken(jwtToken) { const payload = await verifier.verify(jwtToken); var principalEntity = { entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type entityId: payload["sub"], // the application need to use the claim that represents the user-id }; var resourceEntity = { entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id }; var action = { actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id actionId: "GetPhoto", //the application needs to fill in the relevant action type }; var entities = { entityList: [], }; entities.entityList.push(...getUserEntitiesFromToken(payload)); var policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id const authResult = await client .isAuthorized({ policyStoreId: policyStoreId, principal: principalEntity, resource: resourceEntity, action: action, entities, }) .promise(); return authResult; } function getUserEntitiesFromToken(payload) { let attributes = {}; let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss']; Object.entries(payload).forEach(([key, value]) => { if (claimsNotPassedInEntities.includes(key)) { return; } if (Array.isArray(value)) { var attibuteItem = []; value.forEach((item) => { attibuteItem.push({ string: item, }); }); attributes[key] = { set: attibuteItem, }; } else if (typeof value === 'string') { attributes[key] = { string: value, } } else if (typeof value === 'bigint' || typeof value ==='number') { attributes[key] = { long: value, } } else if (typeof value === 'boolean') { attributes[key] = { boolean: value, } } }); let entityItem = { attributes: attributes, identifier: { entityType: "PhotoFlash::User", entityId: payload["sub"], // the application needs to use the claim that represents the user-id } }; return [entityItem]; }

¹ Questo esempio di codice utilizza la aws-jwt-verifylibreria per la verifica JWTs firmata da -compatible. OIDC IdPs