Exemplo 5: filtragem de interface do usuário com permissões verificadas e Cedar - AWS Orientação prescritiva

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 5: filtragem de interface do usuário com permissões verificadas e Cedar

Você também pode usar as Permissões verificadas para implementar a filtragem RBAC dos elementos da interface do usuário com base em ações autorizadas. Isso é extremamente valioso para aplicativos que têm elementos de interface de usuário sensíveis ao contexto que podem estar associados a usuários ou inquilinos específicos no caso de um aplicativo SaaS multilocatário.

No exemplo a seguir, Users dos não Role viewer estão autorizados a realizar atualizações. Para esses usuários, a interface do usuário não deve renderizar nenhum botão de atualização.

Exemplo de filtragem de interface de usuário com Amazon Verified Permissions e Cedar

Neste exemplo, um aplicativo web de página única tem quatro botões. Os botões visíveis dependem Role do usuário que está atualmente conectado ao aplicativo. À medida que o aplicativo web de página única renderiza a interface do usuário, ele consulta as permissões verificadas para determinar quais ações o usuário está autorizado a realizar e, em seguida, gera os botões com base na decisão de autorização.

A política a seguir especifica que o tipo Role com um valor de viewer pode visualizar usuários e dados. Uma decisão de ALLOW autorização para essa política exige uma viewUsers ação viewData or e também exige que um recurso seja associado ao tipo Data ouUsers. Uma ALLOW decisão permite que a interface do usuário renderize dois botões: viewDataButton e. viewUsersButton

permit ( principal in GuiAPP::Role::"viewer", action in [GuiAPP::Action::"viewData", GuiAPP::Action::"viewUsers"], resource ) when { resource in [GuiAPP::Type::"Data", GuiAPP::Type::"Users"] };

A política a seguir especifica que o tipo Role com um valor de só viewerDataOnly pode visualizar dados. Uma decisão de ALLOW autorização para essa política exige uma viewData ação e também exige que um recurso seja associado ao tipoData. Uma ALLOW decisão permite que a interface do usuário renderize o botãoviewDataButton.

permit ( principal in GuiApp::Role::"viewerDataOnly", action in [GuiApp::Action::"viewData"], resource in [GuiApp::Type::"Data"] );

A política a seguir especifica que o tipo Role com um valor de admin pode editar e visualizar dados e usuários. Uma decisão de ALLOW autorização para essa política exige uma ação de updateDataupdateUsers, viewData, ouviewUsers, e também exige que um recurso seja associado ao tipo Data ouUsers. Uma ALLOW decisão permite que a interface do usuário renderize todos os quatro botões: updateDataButtonupdateUsersButton,viewDataButton, e. viewUsersButton

permit ( principal in GuiApp::Role::"admin", action in [ GuiApp::Action::"updateData", GuiApp::Action::"updateUsers", GuiApp::Action::"viewData", GuiApp::Action::"viewUsers" ], resource ) when { resource in [GuiApp::Type::"Data", GuiApp::Type::"Users"] };