La seguridad en Symfony2

Symfony2 ya es un framework con trayectoria para los usuarios que acostumbran a desarrollar en PHP5, pero desde sus inicio a implementado un modelo de seguridad para la autenticación y autorización de los usuarios dentro de sus proyectos.

Realmente me pareció muy interesante, ya que aplicando esta técnica evitamos que un usuario acceda a un recurso al cuál no debería tenes acceso. Por eso los invito a compartir como es la seguridad de usuarios dentro de Symfony2

En el primer paso del proceso, el sistema de seguridad identifica quién es el usuario obligándolo a presentar algún tipo de identificación. Esto se llama autenticación, y significa que el sistema está tratando de determinar quién eres.

Una vez que el sistema sabe quien eres, el siguiente paso es determinar si deberías tener acceso a un determinado recurso. Esta parte del proceso se llama autorización, y significa que el sistema está comprobando si tienes suficientes privilegios para realizar una determinada acción.

Otro componente indispensable para la seguridad en Symfony2 es el uso de firewall, que se utilizan cuando un usuario hace una petición a una URL, es allí cuando se activa el sistema de seguridad. El trabajo del firewall es determinar si el usuario necesita estar autenticado, y si lo hace, enviar una respuesta al usuario para iniciar el proceso de autenticación.

Un cortafuegos se activa cuando la URL de una petición entrante concuerda con el patrón de la expresión regular configurada en el valor config del cortafuegos. En este ejemplo el patrón (^/) concordará con cada petición entrante. El hecho de que el firewall esté activado no significa, sin embargo, que el nombre de usuario de autenticación HTTP y el cuadro de diálogo de la contraseña se muestre en cada URL. Por ejemplo, cualquier usuario puede acceder a /foo sin que se le pida se autentique.

Esto funciona en primer lugar porque el cortafuegos permite usuarios anónimos a través del parámetro de configuración anonymous. En otras palabras, el cortafuegos no requiere que el usuario se autentique plenamente de inmediato. Y puesto que no hay rol especial necesario para acceder a /foo (bajo la sección access_control), la petición se puede llevar a cabo sin solicitar al usuario se autentique.

Finalmente encontramos el Control de Acceso, Si un usuario solicita /admin/foo, sin embargo, el proceso se comporta de manera diferente. Esto se debe a la sección de configuración access_control la cual dice que cualquier URL coincidente con el patrón de la expresión regular ^/admin (es decir, /admin o cualquier cosa coincidente con /admin/*) requiere el rol ROLE_ADMIN. Los roles son la base para la mayor parte de la autorización: el usuario puede acceder a /admin/foo sólo si cuenta con el rol ROLE_ADMIN.

Como antes, cuando el usuario hace la petición originalmente, el cortafuegos no solicita ningún tipo de identificación. Sin embargo, tan pronto como la capa de control de acceso niega el acceso a los usuarios (ya que el usuario anónimo no tiene el rol ROLE_ADMIN), el servidor de seguridad entra en acción e inicia el proceso de autenticación). El proceso de autenticación depende del mecanismo de autenticación que utilices. Por ejemplo, si estás utilizando el método de autenticación con formulario de acceso, el usuario será redirigido a la página de inicio de sesión. Si estás utilizando autenticación HTTP, se enviará al usuario una respuesta HTTP 401 para que el usuario vea el cuadro de diálogo de nombre de usuario y contraseña.

Ahora el usuario de nuevo tiene la posibilidad de presentar sus credenciales a la aplicación. Si las credenciales son válidas, se puede intentar de nuevo la petición original.

Realmente interesante el proceso de autenticación y autorización con firewalls y ACLs verdad, pero lo mejor es que es posible realizar estas configuración en un solo archivo de tipo YAML donde podremos especificar muchos de los parámetros vistos, crear cuanto firewall creamos necesarios y todas las ACLs.

Por otro lado es bueno saber que cada petición que reciba nuestro Controlador Frontal va a estar activando el proceso de seguridad para chequear y dar acceso a los recursos que realmente debe dependiendo no solo de las credenciales del usuario sino también de sus provilegios o ROLES.

Saludos!

Enlace | Seguridad en Symfony2