As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Exemplo 3: Controle de acesso multilocatário com RBAC
Para detalhar o exemplo anterior do RBAC, você pode expandir seus requisitos para incluir a multilocação de SaaS, que é um requisito comum para provedores de SaaS. Em soluções multilocatárias, o acesso aos recursos é sempre fornecido em nome de um determinado inquilino. Ou seja, os usuários do Locatário A não podem visualizar os dados do Locatário B, mesmo que esses dados estejam logicamente ou fisicamente colocados em um sistema. O exemplo a seguir ilustra como você pode implementar o isolamento de inquilinos usando vários repositórios de políticas de permissões verificadas e como você pode empregar funções de usuário para definir permissões dentro do inquilino.
Usar o padrão de design do Per Tenant Policy Store é uma prática recomendada para manter o isolamento do inquilino e, ao mesmo tempo, implementar o controle de acesso com permissões verificadas. Nesse cenário, as solicitações do usuário do Locatário A e do Locatário B são verificadas em relação a repositórios de políticas separados DATAMICROSERVICE_POLICYSTORE_A
eDATAMICROSERVICE_POLICYSTORE_B
, respectivamente. Para obter mais informações sobre as considerações de design de permissões verificadas para aplicativos SaaS multilocatários, consulte a seção Considerações sobre design de permissões verificadas para vários locatários.

A política a seguir reside no repositório de DATAMICROSERVICE_POLICYSTORE_A
políticas. Ele verifica se o diretor fará parte do grupo allAccessRole
do tipoRole
. Nesse caso, o diretor poderá realizar as updateData
ações viewData
e em todos os recursos associados ao Locatário A.
permit ( principal in MultitenantApp::Role::"allAccessRole", action in [ MultitenantApp::Action::"viewData", MultitenantApp::Action::"updateData" ], resource );
As políticas a seguir residem no repositório DATAMICROSERVICE_POLICYSTORE_B
de políticas. A primeira política verifica se o principal faz parte do updateDataRole
grupo do tipoRole
. Supondo que seja esse o caso, ele dá permissão aos diretores para realizar a updateData
ação nos recursos associados ao Locatário B.
permit ( principal in MultitenantApp::Role::"updateDataRole", action == MultitenantApp::Action::"updateData", resource );
Essa segunda política determina que os diretores que fazem parte do viewDataRole
grupo do tipo Role
devem ter permissão para realizar a viewData
ação em recursos associados ao Locatário B.
permit ( principal in MultitenantApp::Role::"viewDataRole", action == MultitenantApp::Action::"viewData", resource );
A solicitação de autorização feita pelo Locatário A precisa ser enviada ao repositório DATAMICROSERVICE_POLICYSTORE_A
de políticas e verificada pelas políticas que pertencem a essa loja. Nesse caso, isso é verificado pela primeira política discutida anteriormente como parte deste exemplo. Nessa solicitação de autorização, o principal do tipo User
com um valor de Alice
está solicitando a execução da viewData
ação. O principal pertence ao grupo allAccessRole
do tipoRole
. Alice está tentando realizar a viewData
ação no SampleData
recurso. Como Alice tem o allAccessRole
papel, essa avaliação resulta em uma ALLOW
decisão.
{ "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, em vez disso, você visualizar uma solicitação feita pelo Locatário B porUser Bob
, verá algo parecido com a seguinte solicitação de autorização. A solicitação é enviada para o repositório de DATAMICROSERVICE_POLICYSTORE_B
políticas porque é originária do Locatário B. Nessa solicitação, o principal Bob
deseja realizar a ação updateData
no recurso. SampleData
No entanto, não Bob
faz parte de um grupo que tenha acesso à ação updateData
nesse recurso. Portanto, a solicitação resulta em uma DENY
decisão.
{ "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": [] } ] } }
Neste terceiro exemplo, User Alice
tenta realizar a viewData
ação no recursoSampleData
. Essa solicitação é direcionada ao repositório de DATAMICROSERVICE_POLICYSTORE_A
políticas porque a diretora Alice
pertence ao Locatário A. Alice
faz parte do grupo allAccessRole
do tipoRole
, o que permite que ela execute a viewData
ação nos recursos. Dessa forma, a solicitação resulta em uma ALLOW
decisão.
{ "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": [] } ] } }