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

Best practice per la multi-tenancy con attributi personalizzati

Amazon Cognito supporta attributi personalizzati con nomi a tua scelta. Uno scenario in cui gli attributi personalizzati sono utili è quando distinguono la locazione degli utenti in un pool di utenti condiviso. Quando assegni agli utenti un valore per un attributo comecustom:tenantID, ad esempio, la tua app può assegnare di conseguenza l'accesso alle risorse specifiche del tenant. Un attributo personalizzato che definisce un ID tenant deve essere immutabile o di sola lettura per il client dell'app.

Il diagramma seguente mostra i tenant che condividono un client di app e un pool di utenti, con attributi personalizzati nel pool di utenti che indica il tenant a cui appartengono.

Quando gli attributi personalizzati determinano la locazione, è possibile distribuire una singola applicazione o accedere. URL Dopo che l'utente ha effettuato l'accesso, l'app può elaborare il custom:tenantID reclamo, determinare quali risorse caricare, il marchio da applicare e le funzionalità da visualizzare. Per decisioni avanzate sul controllo degli accessi in base agli attributi degli utenti, configura il tuo pool di utenti come provider di identità in Amazon Verified Permissions e genera decisioni di accesso dal contenuto di ID o token di accesso.

Quando implementare la multi-tenancy con attributi personalizzati

Quando la locazione è a livello di superficie. Un attributo tenant può contribuire ai risultati di branding e layout. Quando si desidera ottenere un isolamento significativo tra i tenant, gli attributi personalizzati non sono la scelta migliore. Qualsiasi differenza tra i tenant che devono essere configurati a livello di pool di utenti o di app e client, ad esempio MFA il marchio dell'interfaccia utente ospitata, richiede che si creino distinzioni tra i tenant in un modo che gli attributi personalizzati non offrono. Con i pool di identità, puoi persino scegliere il IAM ruolo degli utenti dall'attestazione degli attributi personalizzati contenuta nel loro token ID.

Livello di impegno

Poiché la multi-tenancy con attributi personalizzati trasferisce l'obbligo di prendere decisioni di autorizzazione basate sugli inquilini sulla vostra app, il livello di impegno tende ad essere elevato. Se sei già esperto in una configurazione client che analizza i OIDC reclami o in Amazon Verified Permissions, questo approccio potrebbe richiedere il minimo sforzo.