Entre los servicios más conocidos de la seguridad como servicio podemos citar a la autenticación y la autorización.
Cuando comenzamos a desarrollar aplicaciones nos preocupábamos de que solo las personas autenticadas pudieran acceder a nuestra aplicación y sus recursos. Pero más adelante nos comenzamos a preocupar de que aun cuando la persona estuviera autenticada, no tuviera acceso a toda la aplicación o a todos los recursos, si no solo a aquellos a los que tuviera permiso. A esto le llamamos autorización. Y para lograr esto nos auxiliamos de los roles.
A manera de ejemplo: Solo los administradores pueden definir los salarios de los trabajadores.
Esto funciona y funciona bien. Pero dentro de una empresa que empieza a tener aplicaciones y más aplicaciones llega un momento en que la duplicación del código para mantener los servicios de autenticación y autorización en cada aplicación e implementado de formas diferentes es incontrolable haciéndose bastante complejo este problema. Las soluciones han sido:
- Para la autenticación, el uso de SSO (Single Sign On) una forma de autenticarse fuera de las aplicaciones, solo una vez, y tener acceso a todas las aplicaciones que se encuentren dentro de este esquema de autenticación.
- Para la autorización, la externalización de este servicio fuera de las aplicaciones usando para ello sistemas que almacenan políticas de control de acceso para todas las aplicaciones y servicios, siendo capaces de recibir de las aplicaciones las solicitudes de acceso de los usuarios y responderles SI o NO, en dependencia de si se cumple con las políticas de seguridad establecidas.
En el caso de los sistemas de autorización, todos deben cumplir con estos requerimientos básicos:
- Ser externo e independiente del resto de las aplicaciones.
- Estar basado en políticas.
- Usar estándares abiertos y probados.
- Estar Basado en atributos.
- Ser de grano fino.
- Ser dinámico.
La solución que se propone hasta el momento es:
XACML es un estándar, pero también incluye una propuesta de arquitectura para sus componentes:
En las aplicaciones y servicios que usan XACML, cuando un usuario les pide acceso a un recurso, generan una petición con esta información de la solicitud hecha por el usuario y la mandan a lo que se conoce como un PEP, a su vez el PEP crea un mensaje SAML que es enviado a un PDP donde residen todas las políticas de control de acceso de las aplicaciones. Con la información contenida en el mensaje SAML se busca la política que determinará si el usuario tiene los privilegios o no para acceder al recurso solicitado. A veces la información del usuario viene incompleta y es necesario consultar a los PIP y AS para extraer más información. Al final se devuelve un Permit o Deny o en algunos casos cuando no se encuentra ninguna política a aplicar un no procede que es lo mismo que Deny. Con esta información el PEP le dice a la aplicación si le da el acceso o no al recurso solicitado.
Como ven en la imagen de arriba, una aplicación tiene embebido un PEP que le solicita al PDP si el usuario Bob tiene permiso de ordenar una etiqueta roja, el PDP sabe que si la edad de bod es menor de 21 deberá denegar esta solicitud pero no conoce su edad, así que debe solicitarla a un PIP.
Se ha desarrollado un componente que actúa como un PEP y que puede ser embebido dentro de aplicaciones JAVA, pudiendo estas interactuar con el IS de WSO2. Esto permitire que las aplicaciones puedan externalizar el servicio de autorización, interactuando solamente con un PEP.
Con este enfoque hay sus problemas y desventajas.
El problema más concreto a mi entender es que no todo el mundo entiende a XACMl y SAML, y si los entienden quieren implementar todo esto desde 0. También que hay gente "centrados en aplicaciones" que prefieren seguir codificando sus reglas de negocio, políticas y todo lo que quieran dentro de las aplicaciones, desconociendo que los negocios cambian y con ellos las reglas y las políticas.
Entre las desventajas tenemos:
- El rendimiento, tiempo de respuesta, de un sistema de este tipo será menor que el del enfoque tradicional que reside completamente dentro de 1 aplicación.
- La complejidad de definir y administrar políticas XACML.
- El proceso de integrar los mecanismos de autorización de los sistemas legados a este nuevo enfoque.
- El cómo proveer una interfaz estándar para comunicarse con los PEP y los PDP.
- El hecho de que los PDP deben ser capaces de manejar grandes volúmenes de políticas. Entre 10 000 y 100 000 o más.
- El cómo lograr alta disponibilidad y confianza. Porque si este sistema se cae o se corrompe, todos los demás sistemas serán inoperables.
A estas desventajas se une una pregunta que no siempre es de fácil respuesta: ¿Cuáles son los recursos a los que un usuario tiene acceso? Esta no es una pregunta para un usuario de una aplicación nada más, si no para un usuario con permisos de acceso a diferentes aplicaciones.
Implementaciones para dar solución a este tema hay varias. Vean algunos ejemplos.
He podido ver algunas, aunque no probarlas completamente por falta de tiempo, pero entre ellas y las que no están listadas ahí mi preferida por la cantidad de funcionalidades que brinda y las muchas más que se le van incorporando y que sea libre y de código abierto, es el Identity Server(IS) de WSO2. Vamos a ver por qué.
El tema del rendimiento es una preocupación real, y lo era para mí hasta hace poco.
En la nueva versión del IS se incluirá un mecanismo de cacheo de las decisiones, lo que reducirá notablemente los tiempos de respuesta y las transacciones por segundo. Vean cómo.
Todo podrá ser cacheado de manera tal que se evitarán bastantes consultas cuando se pida lo mismo. Las pruebas de carga dan fe de esto:
Ambiente de las pruebas:
- Intel(R) Xeon(R) CPU X3440 @ 2.53GHz processor, 4 GB RAM, OS - Debian 6.0 (64bit) - with a single instance of Identity Server
- [-Xms1024m -Xmx2024m -XX:MaxPermSize=1024m]
- Policy Complexity
- L1: 10 rules per policy while one rule dealing with 1 attribute
- L2: 100 rules per policy while one rule dealing with more than 10 attributes
- Requests
- one million XACML requests.
- XACML requests are randomly retrieved from a pool where 10 000 different requests are available
- Resourceshttp://people.wso2.com/~asela/xacml_load_test/
En la siguiente imagen veremos los resultados de una prueba de carga, con una concurrencia de 100 0 200 usuarios haciendo peticiones al IS con diferentes niveles de complejidad de las políticas a evaluar. El IS procesa 1 millón de peticiones y pueden ver los resultados, en la penúltima columna sin usar el mecanismo de cacheo y en la última columna usando el mecanismo de cacheo. La mejora en el rendimiento es notable.
En esta segunda imagen se hizo la misma prueba pero usando otro mecanismo para mejorar el rendimiento. Vean como los resultados se mantienen.
Así que de momento el problema del rendimiento está solucionado. En nuestro escenario de la universidad o en cualquier empresa es difícil llegar a estos niveles de solicitudes.
Sobre la complejidad del diseño de las políticas XACML: ya en otra entrada hemos abordado como el IS tiene una UI sumamente mejorada y bastante fácil de manejar
Sobre cómo mover el mecanismo de autorización de los sistemas legados: hay que buscar las variantes, pero cada solución puede ser específica para cada sistema, y todo dependerá de que tan bien diseñado haya sido el mismo. De manera general la solución pasa por la extracción de las políticas ya sea a partir del código o de su almacenamiento en los SGBD y su transformación, automatizada o no, al formato XACML.
Para la preocupación de las interfaces estandarizadas: todas las funcionalidades del IS están expuestas como servicios web, y en algunos casos hasta usando un API en REST.
Para el manejo de grandes volúmenes de políticas: la solución pasa por distribuirlas, y cargarlas bajo demanda.
Y para las preocupaciones de la alta disponibilidad y confianza: se puede usar la siempre viable solución de clusterización, que viene por defecto en todas las soluciones de WSO2.
Como ven el IS de WSO2, como todas las herramientas de esta suite, se perfila como una solución viable y muy útil para resolver nuestros problemas de seguridad. Si a esto le sumamos que incorpora funcionalidades para:
- Emitir token usando un servicio STS.
- Facilidades de SSO.
- Uso de OpenID y Oauth.
Entonces queda claro que no se le puede dar de lado cuando se implemente una solución de seguridad usando herramientas libres y de código abierto.
Entradas
El Identity Server de WSO2 como proveedor de autorización de grano fino.