MOTOR DE TRANSFORMACIÓN DE ATRIBUTOS PARA UN PROVEEDOR DE IDENTIDAD

Transcripción

1 MOTOR DE TRANSFORMACIÓN DE ATRIBUTOS PARA UN PROVEEDOR DE IDENTIDAD Los autores fueron excluidos del documento por reglas del comité organizador PALABRAS CLAVES Motor de transformación de atributos, proveedor de identidad, claims, seguridad, autorización RESUMEN La autenticación basada en claims [1] permite entre otros beneficios desacoplar la lógica de autenticación de la aplicación en cuestión. Esta lógica reside en lo que se conoce como proveedor de identidad. El usuario se autentica en el proveedor de identidad donde le son generados claims 1 que lo describen. A partir de ese momento todos los pedidos realizados a una aplicación web que confié en el proveedor de identidad viajaran con los claims que le fueron emitidos, permitiendo a la aplicación autenticar al usuario. En ocasiones los claims generados son el resultado de extraer información de distintos proveedores de datos. En otras, la aplicación cliente requiere de cierto claims que no son emitidos directamente pero pueden ser inferidos a partir de los claims existentes, como es el caso de un rol. Para resolver estos problemas se usa un motor de transformación de claims, el cual dado un conjunto de claims de entrada y un conjunto de reglas que serán aplicadas al conjunto de entrada, produce un conjunto de claims de salida. Este trabajo aborda la creación de un motor de reglas transformación de claims. Este será usado dentro de WebooLive Identity Server [2], el cual es un proveedor de identidad implementado para la Facultad de Matemática y Computación de la Universidad de La Habana. 1 Se prefiere usar el término claims porque es el más conocido en la bibliografía en este contexto. Cualquier traducción al español perdería semántica

2 INTRODUCCIÓN Una de las cuestiones más importantes en las aplicaciones web es la autenticación y la autorización de usuarios. La autenticación del usuario es lo referente a conocer la identidad de este y mediante la autorización se define el acceso a distintas partes de una aplicación. La mayoría de las aplicaciones incluyen su propia lógica para soportar estos procesos. Este método resulta difícil de manejar cuando las aplicaciones comparten información entre ellas relativa a los usuarios, lo cual sucede con frecuencia en una empresa o universidad. Muchas grandes aplicaciones están compuestas por aplicaciones individuales las cuales interactúan entre ellas dando una experiencia centralizada para el usuario. Estas aplicaciones delegan la autenticación de los usuarios en un proveedor de identidad (IdP) 2. Algunos ejemplos de proveedores de identidad son Windows Live ID, Facebook y Google. El usuario se autentica en el proveedor de identidad donde le son generados claims 3 que lo describen. A partir de ese momento todos los pedidos realizados a una aplicación web que confié en el proveedor de identidad no requieren las credenciales del usuario, pues leen los claims asociados al usuario, permitiéndole acceder a distintas aplicaciones con solo validarse una vez. Se dice entonces que una aplicación es basada en claims si el acceso a sus recursos se basa en claims que son emitidos por una contraparte, en este caso un proveedor de identidad. El conjunto de claims generados se le denomina token de seguridad. Cada token de seguridad es creado y firmado por el servidor de identidad. Una aplicación basada en claims considera al usuario autenticado si presenta un token de seguridad válido de un una servidor de identidad de su confianza. La Figura 1 muestra el patrón básico para usar claims. Figura 1. Servidor de Identidad, token de seguridad y aplicaciones 2 El término viene del inglés, Identity Provider de ahí las siglas empleadas (IdP) 3 Aunque se usa el término atributos, en ingles se maneja como claims

3 Los claims desacoplan la autenticación de la autorización, por lo que la aplicación no necesita incluir lógica para un modo especifico de autenticación. La lógica de autorización queda delegado a la aplicación, la cual regula los niveles de acceso basado en roles y claims que le son emitidos al usuario por el proveedor de identidad. En ocasiones los claims emitidos por el servidor de identidad no brindan información directa para realizar la autorización en la aplicación. Estos deben ser convertidos a claims que sean entendidos por la lógica de autorización de la aplicación en cuestión. Surge entonces la necesidad de tener un mecanismo que transforme los claims originales en claims útiles a la aplicación. WEBOOLIVE IDENTITY SERVER En el Grupo de Investigación Weboo de la Facultad de Matemática y Computación de la Universidad de La Habana se ha implementado un proveedor de identidad propio conocido como WebooLive Identity Server (WLIS) [2], para unificar la autenticación de los usuarios en las aplicaciones web de esa facultad. WLIS integra identidades de distintos fuentes de datos (Figura 2) de usuarios tales como el Directorio Activo de la Facultad, el Directorio Activo del Grupo Weboo 4, el Sistema de Estudiantes de la Universidad (SISGENUS), así como de bases de datos SQL Server. Figura 2. Proceso de integración de atributos en WLIS En ese proceso de integración de atributos puede usarse también un motor de transformación para modificar y seleccionar los atributos provenientes de los proveedores de datos subyacentes. Se propone entonces definir las funcionalidades que se requieren de un motor de transformación para resolver el problema de integración de atributos, así como transformar los claims emitidos por el IdP en claims útiles a las aplicaciones para poder realizar acciones como la autorización. En lo sucesivo el trabajo se concentrará en resolver el problema de integración de atributos. 4 Web Object Oriented Group es un grupo de investigación de la Facultad de Matemática

4 DESARROLLO MOTOR DE TRANSFORMACIÓN Con el objetivo de expresar la funcionalidad requerida para el motor de transformación se definen formalmente los siguientes conceptos: Se define Atributo (claim) como una terna {llave:valor:tipo}, (tres cadenas de caracteres). El valor valor se presenta como string, pero en el momento de su uso se interpretará como el tipo especificado en tipo. Se llamará Perfil a un conjunto de atributos que pueden o no tener repetición. Ejemplo: {Llave= Nombre ; Valor= Jose Antonio ; Tipo= string }, {Llave= Correo ; Valor= jose@matcom.uh.cu ; Tipo= string }, {Llave= Correo ; Valor= jose.antonion@lab.matcom.uh.cu ; Tipo= string } {Llave= Edad ; Valor= 22 ; Tipo= integer } Se define Motor de transformación a la componente capaz de recibir un conjunto de perfiles y un conjunto de reglas de transformación y producir un único perfil, en donde los atributos resultantes serán aquellos producidos por dichas reglas. Cada perfil tendrá un identificador que permitirá reconocerlo, entonces, un atributo puede redefinirse como {perfil:llave:valor:tipo} El perfil de destino (inicialmente vacío) se le denominará con una etiqueta especial para poder re-procesar los atributos que se vayan emitiendo [Un atributo emitido por una regla puede ser reutilizado por otra regla que se ejecute posteriormente en el flujo de ejecución]. Se llamará conjunto de entrada al conjunto de tuplas {perfil:llave:valor:tipo} que se facilita para ser transformado. El conjunto de reglas de transformación estará compuesto por reglas de transformación ordenadas que se aplicarán secuencialmente según su prioridad (las reglas de menor valor numérico se aplicarán primero). Solo se ejecutará una regla a la vez para un mismo procesamiento. Cada regla de transformación estará compuesta por una precondición y una o varias acciones. La precondición define si la regla se ejecuta o no. De manera predeterminada siempre es verdadero. La precondición se aplica sobre los elementos del conjunto de entrada. Ésta estará compuesta por operadores lógicos AND y OR y/o por expresiones booleanas. Cada expresión booleana estará compuesta por: o Un cuantificador: Existe, ParaTodo [tomando como fuente al conjunto de entrada] o Una llave: cadena que representa una llave de un atributo

5 o Operador: Mayor, MayorIgual, Menor, MenorIgual, Igual, EmpiezaCon, TerminaCon, Contiene, Verifica ( una expresión regular) o Valor Ejemplos de Condiciones: Existe Llave Correo ParaTodo Llave Correo TerminaCon.cu La acción define el o los atributos que se generarán. La acción puede ser: o Adición explícita: Se define explícitamente la terna {llave:valor:tipo}. Ésta se adiciona si se cumple la precondición. o Copia directa: Se copian tal cual aquellos atributos que fueron verificados por la precondición, teniendo en cuenta los cuantificadores. o Copia filtrada: Se especifica un filtro que determina los atributos a copiar. o Copia filtrada transformada: Se especifica un filtro que determina los atributos a copiar pero cada atributo se pasa por una transformación literal. El filtro (en el caso de la copia filtrada para la acción) es muy similar a la precondición y su objetivo es seleccionar atributos específicos dentro del conjunto de entrada. El filtro está compuesto por: o Un cuantificador: Todos, Uno. o Una llave: cadena o (*) para definir cualquier llave o Operador: los mismos que para la precondición o Valor Ejemplos de filtros: Todos Llave Correo Todos Llave Correo TerminaCon matcom.uh.cu Uno Llave Correo En el caso de la copia filtrada transformada, el operador del filtro estará limitado a una expresión regular y la transformación literal se hará utilizando expresiones regulares de reemplazo..la Figura 3 muestra la función del motor de transformación de atributos

6 Figura 3.Motor de reglas de transformación de atributos en el servidor de identidad TRABAJOS RELACIONADOS En Windows Azure Active Directory [3] existe una componente llamada Access Control Service [4] la cual contiene un motor de reglas para transformar claims que resuelve un problema similar. En este caso la lógica para transformar de claims está completamente fuera del proveedor de identidad como un servicio independiente que puede ser usado contra cualquier IdP. Este servicio es brindado para aplicaciones que se hospedan en Windows Azure y no es posible reusarlo en otras aplicaciones. Active Directory Federation Service (ADFS) [5] es el proveedor de identidad federada que está presente en las versiones de Windows Server el cual permite autenticación unificada. Este brinda la posibilidad de definir reglas para realizar la transformación de claims en el caso de que se esté usando autenticación federada [1]. Este motor de reglas de transformación no es brindado de manera independiente por lo que no es posible su uso dentro de WLIS. De manera general estas dos soluciones se encuentran en arquitecturas que no permite su uso dentro de WLIS. Aunque las implementaciones concretas de estos motores no son reusables, muchas ideas presentes en ellos sí lo son, las cuales será de utilidad para crear un motor de transformación para WLIS. Además se analizó la herramienta AuthBridge [6] la cual tiene entre sus características un pequeño motor de transformación para normalizar los atributos provenientes de diferentes proveedores de identidad. Esta implementación fue estudiada detalladamente y fue descartada por dos razones fundamentales: el motor de transformación no está diseñado para soportar todas las acciones definidas en el epígrafe Motor de Transformación y la herramienta no está lo suficientemente depurada y robusta como para ser usada en un escenario productivo.

7 Dado que las alternativas existentes a resolver el problema no son aplicables al escenario descrito se decide brindar una implementación para un motor de transformación de atributos. MODELACIÓN DE REGLAS Las reglas de trasformación deberán ser reutilizables, por esto se requiere que sean modeladas de forma que se desacople del funcionamiento del motor de transformación del conjunto de reglas. Como opción para esta representación se usa XML 5, el cual facilita portabilidad de las reglas descritas, así como su fácil lectura por el motor de transformación. El archivo XML definirá un grupo de reglas. En el Listado 1 se muestra como definir una regla. De manera general una regla estará compuesta por una condición y un conjunto de acciones que se ejecutarán en caso de que la precondición sea verdadera para un perfil. En el listado no se muestran definiciones concretas para la precondición y acciones con el objetivo de no desgastar demasiado al lector leyendo el formato del fichero XML. <?xml version="1.0" encoding="utf-8"?> <RulesDefinitions> <Rules> <Rule Name="EmptyRule" Priority="0"> <Condition> { precondición } </Condition> <Actions> { acciones } </Actions> </Rule> <Rule Name="EmptyRule2" Priority="1"> </Rule> </Rules> </RulesDefinitions> Listado 1. Ejemplo de definición de regla XML IMPLEMENTACIÓN Se implementaron dos componentes principales. El motor de transformación y el gestor de reglas. El gestor de reglas permite al administrador del IdP, la edición y comprobación de reglas de transformación, así como de exportar estas al XML abordado en el epígrafe Modelación de reglas. El proceso completo desde la creación de las reglas hasta la ejecución de estas por del motor se describe en la Figura 4. 5 Extensible Markup Language, lenguaje declarativo basado en etiquetas.

8 Figura 4. Componentes del motor de reglas de transformación. En la Figura 4 se muestra además un componente (Analizador Sintáctico de Reglas) encargado de analizar sintácticamente las reglas y de proporcionarlas como entrada al motor de transformación. En el motor de transformación se usaron algunas ideas propuestas en el patrón Intérprete descrito en [7]. De esta manera el Analizador Sintáctico la facilita un conjunto de expresiones que representar la lógica de transformación de cada regla. El Gestor de Reglas es una aplicación web desarrollada en ASP.NET MVC 4 [7], usando JQuery [8] y el Bootstrap de Twitter [9]. Esta aplicación fue diseñada para que la gestión de reglas se hiciese completamente en el lado cliente, lo cual brinda un mayor usabilidad de la interfaz gráfica. CONCLUSIONES En el presente trabajo se abordó un problema existente en el proceso de integración de atributos que tiene lugar en algunas implementaciones de proveedores de identidad. Se identificó que necesitaba un motor de transformación de atributos para resolver dicho problema y de definieron las funcionalidad que debía brindar el motor. Se analizaron las alternativas existentes a resolver el problema y se descartó el uso de todas ellas debido a que no eran reusables para incluirlas como parte de otra sistema o no en otros casos no poseían todas las funcionalidades deseadas. El trabajo concluye con una implementación concreta de dicho motor la cual está siendo usada en WebooLive Identity Server. REFERENCIAS

9 [1] D. Baier, V. Bertocci, K. Brown, E. Pace y M. Woloski, A Guide to Claims-based Identity, Patterns & Practices. [2] A. Tamayo y M. Katrib, «Identity integration in a private cloud,» IADIS (ICWI), [3] Microsoft Corporation, «Windows Azure Active Directory,» [En línea]. Available: [4] Microsoft Corporation, «Access Control Service,» [En línea]. Available: [Último acceso: Febrero 2013]. [5] Microsoft Corporation, «Active Directory Federation Service,» [En línea]. Available: [Último acceso: Febrero 2013]. [6] «AutoBridge,» [En línea]. Available: [Último acceso: Febrero 2013]. [7] E. Gamma, R. Helm, R. Johnson y J. Vlissides, Design Patterns. Elements of Reusable Object-Oriented Software. [8] J. Palermo, J. Bogard, E. Hexter, M. Hinze y J. Skinner, ASP.NET MVC 4 in action, New York: Manning, [9] B. Bibeault y Y. Katz, jquery in Action, Manning, [10] Twitter, [En línea]. Available: [Último acceso: Enero 2013].