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)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à.
Argomenti
- Utilizzo delle fonti di identità di Amazon Cognito
- Lavorare con le fonti di identità OIDC
- Convalida del cliente e del pubblico
- Autorizzazione lato client per JWTs
- Creazione di fonti di identità Amazon Verified Permissions
- Modifica delle fonti di identità di Amazon Verified Permissions
- Mappatura dei token del provider di identità allo schema
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 esempio
MyCorp::User
. -
Il tipo di entità di gruppo che desideri associare alla tua fonte di identità, ad esempio
MyCorp::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:
-
Dichiarazioni relative al nome utente e al gruppo con prefisso
cognito:
-
Attributi utente personalizzati con un
custom: prefix
-
Affermazioni personalizzate aggiunte in fase di esecuzione
-
OIDCaffermazioni standard come
sub
eemail
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
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 esempio
MyCorp::User
. -
Il tipo di entità di gruppo che desideri associare alla tua fonte di identità, ad esempio
MyCorp::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'aud
affermazione non è sempre associata al pubblico.
Verified Permissions esegue la convalida dell'identità, dell'origine, del pubblico e del client come segue:
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-verify