En aplicaciones, normalmente la autenticación y autorización de usuarios se realiza a través del uso de bases de datos específicas de la aplicación o servicios de directorio activo como Microsoft Active Directory.
Sin embargo, todos estos mecanismos requieren el mantenimiento de un directorio de usuarios en el cual tengan definidos qué usuarios tienen acceso a la aplicación y a qué recursos pueden acceder una vez autenticados.
¿El problema? Cómo unificar y proteger toda la información de usuarios de las diferentes plataformas y aplicaciones de una organización o empresa para simplificar tanto el proceso de mantenimiento como el acceso a estas. La respuesta es usando Autenticación Federada.
Autenticación Federada
La autenticación federada consiste en delegar a una entidad de confianza las tareas de obtener y guardar información de usuarios para su autenticación. La aplicación sigue manteniendo el control de autorizar qué recursos puede ver el usuario, pero se libera de la necesidad de autenticar cada usuario y asignarle los correspondientes roles o grupos convirtiéndose en un sistema de autenticación pasiva. Esto permite desacoplar la autenticación de la autorización y evitar que cada aplicación tenga que gestionar las credenciales de sus usuarios.
Identidad Federada entre Realms
Esta entidad, a su vez, puede tener otras entidades de confianza, las cuales no necesariamente tienen que estar en el mismo dominio. Una entidad puede aceptar tokens de seguridad de otras entidades que confíe. Esto permite federar la identidad con otros dominios de seguridad diferentes, Realms[9].
En el caso de que por ejemplo un usuario externo de otro Realm, un partner company, quiera acceder a una aplicación de tu dominio, éste deberá primero autenticarse en su propio dominio a través de su entidad emisora. Posteriormente el usuario se autentica en tu dominio con el token obtenido previamente de su entidad de autenticación. Una vez autenticado, tu emisor, que puede estar en otro dominio, le devuelve otro token el cual le permite validarse a tu aplicación.
Security Token Services
Para poder delegar el proceso de autenticación es necesario definir un modo estándar para que la aplicación pueda validar los usuarios y obtener su información. Security Token Service STSs[2] es la entidad de autenticación con la que se comunica la aplicación y la que le devuelve un token de autenticación con todos los claims[3] definidos para cada usuario. Estas entidades STS están enfocadas a sistemas de autenticación basados en claims. Esto hace que cualquier aplicación que use un sistema de autenticación por claims pueda consumir estos servicios de forma transparente.
Cada STS usa Identity Providers[2] IdPs que son los responsables de la validación de los usuarios. Cuando un identity provider autentica el usuario, el STS crea un token incluyendo los claims de éste. Cuando la autenticación es a través del navegador web, el token es entregado en una cookie. Esto indica a la aplicación que el usuario se ha autenticado y permite el acceso a otras aplicaciones sin la necesidad de volver a pedir las credenciales del usuario ofreciendo un servicio de Single Sign-On (SSO)[8].
Actualmente existen diferentes soluciones STSs. Active Directory Federation Service[6] ADFS o Azure Access Control Service[7] ACS son las soluciones de Microsoft.
ADFS es una entidad de autenticación local cuya finalidad es la de hacer la función de STS y también la de IdP ya que usa el Directorio Activo para la validación de usuarios.
ACS es el servicio azure el cual también hace la función de entidad de autenticación. Pero a diferencia del ADFS, éste soporta IdP externos como Windows Live ID, Google, Facebook o Yahoo. Hace uso de estos IdPs externos para redirigir el usuario a su proveedor de identidad correspondiente para la autenticación.
También existen soluciones open source (Identity Server, OpenSSO,…) con las que puedes implementar tu propio sistema STS.
Proceso de Autenticación
El usuario intenta acceder a la aplicación y esta redirige el usuario al ACS (STS).
El STS a su vez, selecciona un IdP para autenticar el usuario en función de su Realm o dominio.
El STS redirige el usuario al IdP y se autentica.
El IdP devuelve al ACS un token con claims del usuario.
El STS genera un token y una versión extendida de los claims específicos de la aplicación y redirige el usuario a la aplicación.
La aplicación valida el usuario con el token y usa los claims para autorizar que acciones y recursos tiene el usuario sobre la aplicación.
Configurar aplicación con autenticación federada
Para poder configurar autenticación federada, la aplicación primero debe establecer una relación de confianza con el emisor STS que será la entidad la cual te autenticará los usuarios y te devolverá la validación usando un token junto con los permisos del usuario a través de los claims.
La aplicación debe pedir al emisor el fichero de configuración Federation Metadata[5]. En este fichero se sigue el estándar WS-Federation y en él está definido el certificado del emisor junto a la llave pública con la que la aplicación puede verificar los token recibidos. También incluye la lista de claims que el emisor puede proveer, la url a la cual los usuarios pueden pedir el token o en que formato vendrá el token (e.j protocolo comunicación SAML).
Windows proporciona un framework llamado Windows Identity Foundation WIF[2] el cual proporciona las herramientas para construir aplicaciones basadas en claims y incorpora protocolos para autenticación federada. Además, permite automatizar todo el proceso de configuración de la aplicación a partir del fichero Federation Metadata. Simplemente hay que indicarle la dirección del STS emisor y automáticamente se baja el fichero metadata configurando de este modo la aplicación automáticamente.
Ejemplo fichero Federation Metadata
<EntityDescriptor xmlns=»urn:oasis:names:tc:SAML:2.0:metadata» ID=»_5f3badf8-ef9f-4649-9050-0ba081c04b1a» entityID=»https://sts.windows.net/{tenantid}/»>
<X509Data>
<X509Certificate>MIIC4jCCAcqgAwIBAgIQQNXrmzhLN4VGlUXDYCRT3zANBgkqhkiG9w0BAQsFADAtMSswKQ</X509Certificate>
</X509Data>
<fed:ClaimTypesOffered>
<auth:ClaimType xmlns:auth=»http://docs.oasis-open.org/wsfed/authorization/200706″Uri=»http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name» Optional=»true»>
<auth:DisplayName>Name</auth:DisplayName>
<auth:Description>The mutable display name of the user.</auth:Description></auth:ClaimType>
<fed:ApplicationServiceEndpoint>
<EndpointReference xmlns=»http://www.w3.org/2005/08/addressing»>
<Address>https://login.microsoftonline.com/common/wsfed</Address>
</EndpointReference>
</fed:ApplicationServiceEndpoint>
<IDPSSODescriptor protocolSupportEnumeration=»urn:oasis:names:tc:SAML:2.0:protocol»>
Con la ayuda del framework WIF podemos configurar automáticamente la aplicación para usar autenticación federada. Sólo es necesario indicarle la dirección de la entidad STS y el Realm de nuestra aplicación.
Validación del Relying Party
En la parte del emisor STS, hay que registrar la aplicación o servicio el cual va a consumir los servicios de autenticación para que pueda validarlos posteriormente el STS cuando reciba solicitudes de autenticación de usuarios por parte de la aplicación. A las aplicaciones o servicios que consumen los STS se definen como Relying Parties.
En la configuración de la entidad STS hay que definir el nombre del Relying Party, el Realm donde se introduce el ID de la aplicación, y finalmente el Return Url en el cual se define la dirección donde el STS tiene que redirigir el usuario una vez autenticado.
Referencias
[1]. How to Authenticate Web Users with Azure Active Directory Access Control
[2]. Authenticating Users and Authorizing Requests
https://msdn.microsoft.com/en-us/library/hh868049.aspx
[3]. An Introduction to Claims
https://msdn.microsoft.com/en-us/library/ff359101.aspx
[4]. Federated Identities: OpenID vs SAML vs OAuth
http://www.softwaresecured.com/2013/07/16/federated-identities-openid-vs-saml-vs-oauth/
[5]. Federation Metadata
https://msdn.microsoft.com/en-us/library/azure/dn195592.aspx
[6]. Active Directory Federation Services
https://msdn.microsoft.com/en-us/library/bb897402.aspx
[7]. Federated Identity with Microsoft Azure Access Control Service
https://msdn.microsoft.com/en-us/library/hh446535.aspx
[8]. Understanding Enterprise Single Sign-On
https://msdn.microsoft.com/en-us/library/aa745042(v=bts.10).aspx
[9]. Claims-Based Architectures
https://msdn.microsoft.com/en-us/library/ff359108.aspx
Ramón Tomás es Ingeniero superior en Telecomunicaciones por la universidad politécnica de Catalunya. Se ha unido a Sogeti recientemente, en la unidad de soluciones Microsoft en Barcelona como desarrollador analista. Anteriormente ha trabajado como desarrollador especializado en tecnología Microsoft para clientes del sector bancario.
Para saber más sobre cómo Sogeti puede ayudarte en el desarrollo de soluciones tecnológicas para tu negocio, visita nuestra web.
Artículos y tendencias sobre soluciones tecnológicas 
0 comments on “Autenticación Federada”