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à.
Esempio 3: controllo degli accessi multi-tenant con RBAC
Per approfondire il precedente esempio RBAC, è possibile espandere i requisiti per includere la multi-tenancy SaaS, che è un requisito comune per i provider SaaS. Nelle soluzioni multi-tenant, l'accesso alle risorse viene sempre fornito per conto di un determinato tenant. Cioè, gli utenti del Tenant A non possono visualizzare i dati del Tenant B, anche se tali dati sono collocati logicamente o fisicamente in un sistema. L'esempio seguente illustra come implementare l'isolamento dei tenant utilizzando più archivi di policy per le autorizzazioni verificate e come utilizzare i ruoli utente per definire le autorizzazioni all'interno del tenant.
L'utilizzo del modello di progettazione Per Tenant Policy Store è una best practice per mantenere l'isolamento dei tenant durante l'implementazione del controllo degli accessi con autorizzazioni verificate. In questo scenario, le richieste degli utenti Tenant A e Tenant B vengono verificate in archivi di policy separati e, rispettivamente. DATAMICROSERVICE_POLICYSTORE_A
DATAMICROSERVICE_POLICYSTORE_B
Per ulteriori informazioni sulle considerazioni sulla progettazione di autorizzazioni verificate per applicazioni SaaS multi-tenant, consulta la sezione Considerazioni sulla progettazione multi-tenant delle autorizzazioni verificate.

La seguente policy si trova nel Policy Store. DATAMICROSERVICE_POLICYSTORE_A
Verifica che il principale faccia parte del gruppo allAccessRole
di tipi. Role
In questo caso, il committente sarà autorizzato a eseguire le updateData
azioni viewData
e su tutte le risorse associate al Tenant A.
permit ( principal in MultitenantApp::Role::"allAccessRole", action in [ MultitenantApp::Action::"viewData", MultitenantApp::Action::"updateData" ], resource );
Le seguenti politiche si trovano nell'archivio delle DATAMICROSERVICE_POLICYSTORE_B
politiche. La prima policy verifica che il principale faccia parte del updateDataRole
gruppo di tipi. Role
Supponendo che sia così, autorizza i mandanti a eseguire l'updateData
azione sulle risorse associate al Tenant B.
permit ( principal in MultitenantApp::Role::"updateDataRole", action == MultitenantApp::Action::"updateData", resource );
Questa seconda politica impone che i committenti che fanno parte del viewDataRole
gruppo di tipo Role
siano autorizzati a eseguire l'viewData
azione sulle risorse associate al Tenant B.
permit ( principal in MultitenantApp::Role::"viewDataRole", action == MultitenantApp::Action::"viewData", resource );
La richiesta di autorizzazione effettuata dal Tenant A deve essere inviata al DATAMICROSERVICE_POLICYSTORE_A
policy store e verificata in base alle politiche che appartengono a tale archivio. In questo caso, viene verificata in base alla prima politica discussa in precedenza come parte di questo esempio. In questa richiesta di autorizzazione, il principale di tipo User
con valore di Alice
richiede di eseguire l'viewData
azione. Il principale appartiene al gruppo allAccessRole
di tipiRole
. Alice sta cercando di eseguire l'viewData
azione sulla SampleData
risorsa. Poiché Alice ha il allAccessRole
ruolo, questa valutazione porta a una ALLOW
decisione.
{ "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A", "principal": { "entityType": "MultitenantApp::User", "entityId": "Alice" }, "action": { "actionType": "MultitenantApp::Action", "actionId": "viewData" }, "resource": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "entities": { "entityList": [ { "identifier": { "entityType": "MultitenantApp::User", "entityId": "Alice" }, "attributes": {}, "parents": [ { "entityType": "MultitenantApp::Role", "entityId": "allAccessRole" } ] }, { "identifier": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "attributes": {}, "parents": [] } ] } }
Se, invece, visualizzi una richiesta fatta dal Tenant B daUser Bob
, vedrai qualcosa come la seguente richiesta di autorizzazione. La richiesta viene inviata al DATAMICROSERVICE_POLICYSTORE_B
policy store perché proviene dal Tenant B. In questa richiesta, il principale Bob
desidera eseguire l'azione updateData
sulla risorsa. SampleData
Tuttavia, non Bob
fa parte di un gruppo che ha accesso all'azione updateData
su quella risorsa. Pertanto, la richiesta dà luogo a una DENY
decisione.
{ "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B", "principal": { "entityType": "MultitenantApp::User", "entityId": "Bob" }, "action": { "actionType": "MultitenantApp::Action", "actionId": "updateData" }, "resource": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "entities": { "entityList": [ { "identifier": { "entityType": "MultitenantApp::User", "entityId": "Bob" }, "attributes": {}, "parents": [ { "entityType": "MultitenantApp::Role", "entityId": "viewDataRole" } ] }, { "identifier": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "attributes": {}, "parents": [] } ] } }
In questo terzo esempio, User Alice
tenta di eseguire l'viewData
azione sulla risorsaSampleData
. Questa richiesta viene indirizzata al DATAMICROSERVICE_POLICYSTORE_A
policy store perché il responsabile Alice
appartiene al Tenant A. Alice
fa parte del gruppo allAccessRole
del tipoRole
, che le consente di eseguire l'viewData
azione sulle risorse. Pertanto, la richiesta dà luogo a una ALLOW
decisione.
{ "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A", "principal": { "entityType": "MultitenantApp::User", "entityId": "Alice" }, "action": { "actionType": "MultitenantApp::Action", "actionId": "viewData" }, "resource": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "entities": { "entityList": [ { "identifier": { "entityType": "MultitenantApp::User", "entityId": "Alice" }, "attributes": {}, "parents": [ { "entityType": "MultitenantApp::Role", "entityId": "allAccessRole" } ] }, { "identifier": { "entityType": "MultitenantApp::Data", "entityId": "SampleData" }, "attributes": {}, "parents": [] } ] } }