El objetivo de este capítulo es darte una descripción más detallada del sistema ACL, y también explicar algunas de las decisiones de diseño detrás de él.
La capacidad de la instancia del objeto seguridad de Symfony2 está basada en el concepto de una Lista de Control de Acceso. Cada instancia del objeto dominio tiene su propia ACL. La instancia de ACL contiene una detallada lista de las entradas de control de acceso (ACE) utilizada para tomar decisiones de acceso. El sistema ACL de Symfony2 se enfoca en dos objetivos principales:
Según lo indicado por el primer punto, una de las principales capacidades del sistema ACL de Symfony2 es una forma de alto rendimiento de recuperar las ACL/ACE. Esto es muy importante ya que cada ACL puede tener varias ACE, y heredar de otra ACL anterior en una forma de árbol. Por tanto, ningún ORM es forzoso, en su lugar la implementación predeterminada interacciona con tu conexión directamente usando el DBAL de Doctrine.
El sistema ACL está disociado completamente de los objetos de tu dominio. Ni siquiera se tienen que almacenar en la misma base de datos, o en el mismo servidor. Para lograr esta disociación, en el sistema ACL los objetos son representados a través de objeto identidad objetos. Cada vez, que desees recuperar la ACL para un objeto dominio, el sistema ACL en primer lugar crea un objeto identidad de tu objeto dominio y, a continuación pasa esa identidad de objeto al proveedor de ACL para su posterior procesamiento.
Esto es análogo a la identidad de objeto, pero representa a un usuario o un rol en tu aplicación. Cada rol, o usuario tiene una identidad de seguridad propia.
La implementación predeterminada usa cinco tablas de bases de datos enumeradas a continuación. Las tablas están ordenadas de menos filas a más filas en una aplicación típica:
Las entradas del control de acceso pueden tener diferente ámbito en el cual se aplican. En Symfony2, básicamente hay dos diferentes ámbitos:
A veces, encontraras la necesidad de aplicar una ACE sólo a un campo específico del objeto. Digamos que deseas que el ID sólo sea visto por un gestor, pero no por tu servicio al cliente. Para resolver este problema común, se añadieron dos subámbitos:
Para las decisiones de preautorización, es decir, las decisiones antes de que se invoque al método o acción de seguridad, se usa el servicio AccessDecisionManager provisto. El AccessDecisionManager también se utiliza para tomar decisiones de autorización basadas en roles. Al igual que los roles, el sistema ACL añade varios nuevos atributos que se pueden utilizar para comprobar diferentes permisos.
| Atributo | Significado previsto | Máscara de Bits |
|---|---|---|
| VIEW | Cuando le es permitido a alguien ver el objeto dominio. | VIEW, EDIT, OPERATOR, MASTER u OWNER |
| EDIT | Cuando le es permitido a alguien hacer cambios al objeto dominio. | EDIT, OPERATOR, MASTER, u OWNER |
| CREATE | Cuando a alguien se le permite crear el objeto dominio. | CREATE, OPERATOR, MASTER, u OWNER |
| DELETE | Cuando a alguien se le permite eliminar el objeto dominio. | DELETE, OPERATOR, MASTER u OWNER |
| UNDELETE | Cuando le es permitido a alguien restaurar un objeto dominio previamente eliminado. | UNDELETE, OPERATOR, MASTER u OWNER |
| OPERATOR | Cuando le es permitido a alguien realizar todas las acciones anteriores. | OPERATOR, MASTER u OWNER |
| MASTER | Cuando le es permitido a alguien realizar todas las acciones anteriores, y además tiene permitido conceder cualquiera de los permisos anteriores a otros. | MASTER u OWNER |
| OWNER | Cuando alguien es dueño del objeto dominio. Un propietario puede realizar cualquiera de las acciones anteriores y otorgar privilegios y permisos de propietario. | OWNER |
Los atributos los utiliza el AccessDecisionManager, justo como los roles. A menudo, estos atributos en realidad representan un conjunto de enteros como máscaras de bits. Las máscaras de bits de enteros en cambio, las utiliza internamente el sistema ACL para almacenar de manera eficiente los permisos de los usuarios en la base de datos, y realizar comprobaciones de acceso usando las extremadamente rápidas operaciones de las máscaras de bits.
El mapa de permisos citado más arriba no es estático, y, teóricamente, lo podrías reemplazar a voluntad por completo. Sin embargo, debería abarcar la mayoría de los problemas que encuentres, y para interoperabilidad con otros paquetes, te animamos a que le adhieras el significado que tienes previsto para ellos.
Las decisiones de postautorización se realizan después de haber invocado a un método seguro, y por lo general implican que el objeto dominio es devuelto por este método. Después de invocar a los proveedores también te permite modificar o filtrar el objeto dominio antes de devolverlo.
Debido a las limitaciones actuales del lenguaje PHP, no hay capacidad de postautorización integrada en el núcleo del componente seguridad. Sin embargo, hay un JMSSecurityExtraBundle experimental que añade estas capacidades. Consulta su documentación para más información sobre cómo se logra esto.
La clase ACL proporciona dos métodos para determinar si una identidad de seguridad tiene la máscara de bits necesaria, isGranted y isFieldGranted. Cuando la ACL recibe una petición de autorización a través de uno de estos métodos, delega esta petición a una implementación de PermissionGrantingStrategy. Esto te permite reemplazar la forma en que se tomen decisiones de acceso sin tener que modificar la clase ACL misma.
PermissionGrantingStrategy primero verifica todo su ámbito de aplicación ACE a objetos si no es aplicable, comprobará el ámbito de la clase ACL, si no es aplicable, entonces el proceso se repetirá con las ACE de la ACL padre. Si no existe la ACL padre, será lanzada una excepción.
