Documentação do Symfony2
Renderizada do repositório symfony-docs-pt-BR no Github
O objetivo deste capítulo é fornecer uma visão mais aprofundada do sistema de ACL, e também explicar algumas das decisões de projeto por trás dele.
Os recursos de uma instância do objeto de segurança do Symfony2 tem base no conceito de uma Lista de Controle de Acesso (ACL). Cada instância do objeto de domínio tem a sua própria ACL. A instância ACL contém uma lista detalhada de Entradas de Controle de Acesso (ACEs), que são usadas para tomar decisões de acesso. O sistema ACL do Symfony2 concentra-se em dois objetivos principais:
Conforme indicado no primeiro ponto, uma das principais capacidades do sistema ACL do Symfony2 é uma forma de recuperar ACLs/ACEs com alto desempenho. Isto é extremamente importante, pois cada ACL pode ter várias ACEs, e herdam de outra ACL em forma de árvore. Portanto, nenhum ORM é utilizado, em vez disso, a implementação padrão interage com a sua conexão diretamente usando o DBAL do Doctrine.
O sistema de ACL é completamente desacoplado de seus objetos de domínio. Eles não tem que ser armazenados na mesma base de dados, ou no mesmo servidor. De forma a atingir esse desacoplamento, os seus objetos, no sistema ACL, são representados através de objetos de identidade de objeto. Toda vez que você deseja recuperar a ACL para um objeto de domínio, o sistema de ACL vai primeiro criar uma identidade de objeto do seu objeto de domínio e, em seguida, passar essa identidade de objeto ao provedor ACL para processamento adicional.
Isto é análogo à identidade de objeto, mas representa um usuário ou um papel em sua aplicação. Cada papel ou usuário tem a sua própria identidade de segurança.
A implementação padrão usa cinco tabelas de banco de dados, conforme listado abaixo. Em uma aplicação típica, as tabelas são ordenadas da com menos linhas para a com mais linhas:
Entradas de controle de acesso podem ter escopos diferentes nos quais se aplicam. No Symfony2, existem basicamente dois escopos diferentes:
Às vezes, você vai encontrar a necessidade de aplicar uma ACE apenas a um campo específico do objeto. Vamos dizer que você quer que o ID somente seja visualizado por um administrador, mas não por seu serviço do cliente. Para resolver este problema comum, mais dois sub-escopos foram adicionados:
Para as decisões de pré-autorização, que são as decisões tomadas antes de qualquer método seguro (ou ação segura) ser invocado, o serviço AccessDecisionManager é usado. O AccessDecisionManager também é usado para tomar decisões de autorização com base em papéis. Assim como os papéis, o sistema de ACL adiciona vários atributos novos que podem ser utilizados para verificar se há permissões diferentes.
| Atributo | Significado Pretendido | Bitmasks Inteiras |
|---|---|---|
| VIEW | Se alguém tem permissão para ver o objeto de domínio. | VIEW, EDIT, OPERATOR, MASTER ou OWNER |
| EDIT | Se alguém tem permissão para fazer alterações no objeto de domínio. | EDIT, OPERATOR, MASTER ou OWNER |
| CREATE | Se alguém tem permissão para criar o objeto de domínio. | CREATE, OPERATOR, MASTER ou OWNER |
| DELETE | Se alguém tem permissão excluir o objeto de domínio. | DELETE, OPERATOR, MASTER ou OWNER |
| UNDELETE | Se alguém tem permissão para restaurar o objeto de domínio anteriormente excluído. | UNDELETE, OPERATOR, MASTER ou OWNER |
| OPERATOR | Se alguém tem permissão para executar todas as ações acima. | OPERATOR, MASTER ou OWNER |
| MASTER | Se alguém tem permissão para executar todas as ações acima, e além disso é autorizada a conceder qualuqer uma das permissões acima para outros. | MASTER ou OWNER |
| OWNER | Se alguém é dono do objeto de domínio. Um dono pode executar qualquer uma das ações acima e conceder permissões master e owner | OWNER |
Os atributos são usados pelo AccessDecisionManager, assim como papéis. Muitas vezes, estes atributos representam, de fato, um agregado de bitmasks inteiros. Bitmasks inteiros por outro lado, são utilizados internamente pelo sistema de ACL para armazenar de forma eficiente suas permissões de usuário no banco de dados e executar verificações de acesso usando operações bitmask extremamente rápidas.
O mapa de permissão acima não é de forma alguma estático, e teoricamente poderia ser completamente substituído. No entanto, ele deve cobrir a maioria dos problemas que você encontra e para a interoperabilidade com outros bundles, você é incentivado a manter o significado previsto por eles.
Decisões pós-autorização são feitas depois de um método seguro ter sido invocado, e normalmente envolvem o objeto de domínio que é retornado por esse método. Após a invocação de providers, também é permitido modificar ou filtrar o objeto de domínio antes de ser devolvido.
Devido às limitações atuais da linguagem PHP, não existem recursos de pós-autorização integrados no componente de segurança. No entanto, existe um JMSSecurityExtraBundle experimental que adiciona esses recursos. Consulte a documentação para obter mais informações sobre a forma como isso é feito.
A classe ACL fornece dois métodos para determinar se uma identidade de segurança tem as bitmasks necessárias, isGranted e isFieldGranted. Quando a ACL recebe um pedido de autorização através de um desses métodos, ela delega esse pedido para uma implementação de PermissionGrantingStrategy. Isso permite a substituição da forma como as decisões de acesso são tomadas sem modificar a própria classe ACL.
O PermissionGrantingStrategy primeiro verifica todos os seus ACEs object-scope, se nenhum for aplicável, as ACEs class-scope serão verificadas, se nenhuma for aplicável, em seguida, o processo vai ser repetido com as ACEs da ACL pai. Se não existe nenhuma ACL pai, uma exceção será lançada.
