Identidad en la Nube

Información general
La identidad es uno de los desafíos centrales que la mayoría de aplicaciones de nube deben enfrentar. Las aplicaciones de nube están distribuidas por diseño, pero todos los nodos deben ser compatibles con el mismo reconocimiento de identidad. Quién es el usuario? Qué permisos se deben otorgar?
Las preocupaciones de clientes sobre seguridad, privacidad y control operacional encabezan la lista de los límites potenciales al uso de soluciones de nube. Clientes que estén considerando cargar sus aplicaciones a la nube deben tener garantías de que el modelo de identidad que se implementa en la nube es coherente con sus requisitos y necesidades.
Hay distintas maneras de construir compatibilidad con identidad in una aplicación. El entorno de nube permite el uso de escenarios sofisticados tales como la colaboración, la mediación y el inicio de sesión único o “single sign-on” (SSO). En tales escenarios, la compatibilidad con identidad tradicional puede ser difícil de implementar.Este artículo describe la infraestructura que la plataforma de Windows Azure proporciona y que ofrece Windows Azure Appfabric para permitir implementación de seguridad sencilla pero segura en estos escenarios.

Qué es identidad?
Antes de describer las tecnologías y la arquitectura de identidad es importante definer la identidad.

La definición de “identidad” del diccionario es:

Todo aquello que hace que una entidad sea definible y reconocible, en términos de posesión una serie de cualidades o características que la distingan de otras entidades.

Para los propósitos de aplicaciones software, esta definición se traduce en “la colección de información que describe una entidad para distinguirla de otras”.

La identidad es, entonces, una colección de información. Esa información puede tener un nombre, una fecha de nacimiento, una dirección, una identificación de empleo, un número de seguridad social (Social Security Number), etc. Es importante notar que las entidades (es decir, las personas), pueden usar información de identidad distinta en contextos distintos. Por ejemplo, la información de identidad personal de una persona (como se escribiría en Facebook), puede ser muy diferente de la información de identidad profesional (como se escribiría en Active Directory en la oficina).

Existen tres escenarios de uso principales que tienen que ver con la identidad:
Autenticación: El proceso de probar una identidad. Una entidad (usuario) usa credenciales (piezas relevantes de información) para comprobar su identidad ante la aplicación.
Autorización: El proceso de conceder permisos a una identidad y de implementar políticas que permitan a las entidades ejecutar tareas únicamente si han obtenido los permisos relevantes.
Consulta de identidad: El proceso de consultar o buscar información de identidad para el uso general de la aplicación.

Tecnologías de identidad
Existen muchas tecnologías diferentes para construir compatibilidad con identidad en las aplicaciones. Como se describirá a continuación, algunas tecnologías utilizan administración basada en roles, mientras que otras se basan en un enfoque basado en notificaciones.

Las tecnologías de identidad se pueden dividir en tres categorías principales:

Almacenes de identidad (Proveedores):
Estas tecnologías son responsables de almacenar un diccionario de información de identidades. Los almacenes de identidad manejan toda la información que describe a las entidades y sus relaciones con otras entidades en el dominio. El resultado es una serie complicada de información que debería en todo caso ser fácil de consultar con el uso de los interfaces del almacén de identidad. Ejemplos: Active Directory, ADFS, SQL.

Selectores de identidad:
Estas tecnologías son las responsables de seleccionar un almacén de identidad y un método de autenticación. Los usuarios se pueden registrar en uno o varios almacenes de identidad (ej., Windows Live ID, Facebook, etc.) Los protocolos de autenticación utilizan selectores de identidad para permitirles a los usuarios escoger el almacén de identidad ante el cual quieren recibir autenticación. Ejemplo: Cardspace 2.0

Marcos de autenticación y de autorización:
Estas tecnologías son las responsables de autenticar las solicitudes y de hacer respetar (enforce) las políticas de acceso. Esto incluye el proceso de comprobar credenciales cotejando la información de los almacenes de identidad, creando tokens de seguridad válidos que contengan la información requerida por la aplicación para identificar a la identidad y sus permisos , y de establecer “porteros” (gatekeepers) que otorguen permisos a solicitudes válidas y nieguen el acceso a solicitudes no autorizadas
Ejemplos: ASP.NET Forms authentication, Kerberos, WIF, OpenID
Windows Azure es compatible con estos tres tipos de tecnologías de identidad, lo que le permite a los clientes fácilmente migrar aplicaciones a la nube. Por ejemplo, es posible unirse al dominio de aplicaciones de la nube y usar Windows Identity basado en roles, o bien, también es posible usar ADFS 2.0 con ACS y autenticar con el uso de identidad basada en notificaciones.

Identidad basada en roles
La identidad basada en roles es el enfoque tradicional que usan las aplicaciones para la administración de identidad. Las entidades se dividen en grupos (roles) y los permisos se conceden de acuerdo a pertenencia en los grupos.

La identidad basada en roles es apropiada para escenarios sencillos: el usuario suministra sus credenciales (ej. un nombre de usuario y una contraseña); el marco de autenticación comprueba las credenciales en un almacén de identidades (ej. Base de datos SQL) y asigna el usuario a un grupo de roles y establece un contexto de seguridad en el que se ejecutará la aplicación (ej., Principal). La aplicación luego puede revisar de manera activa si el usuario en ejecución “IsInRole” antes de ejecutar operaciones sensibles permitidas únicamente a un grupo específico de miembros).

Los marcos de autenticación basada en roles generalmente proporcionan la infraestructura con la cual asignar grupos a permisos, y hacen cumplir y respetar la política de seguridad al permitir únicamente a aquellos usuarios a quienes se les concedieron los permisos requeridos, acceso a recursos confidenciales. Esto libera a la aplicación de tener que revisar activamente los permisos del usuario antes de cada acción.

La sencillez es una ventaja principal de la seguridad basada en roles. En algunos casos, sin embargo, estos escenarios sencillos simplemente fallan. Qué pasa si una aplicación necesita más información sobre el usuario que la que provee en un marco de autenticación? Qué pasa si los usuarios que maneja un socio necesitan acceso a la aplicación? Los marcos basados en roles no se diseñaron para la federación de identidades entre distintos proveedores de identidad.

– Implementación de identidad basada en roles en Azure
La mayoría de aplicaciones web hoy en día utilizan identidad basada en roles. La mayoría de usuarios, al considerar hospedar sus aplicaciones existentes en la nube, no aceptarían tener que cambiar su enfoque y tecnología de identidad. Por eso Windows Azure permite a los usuarios continuar el uso de su marco existente de identidad en la nube.
Cuando Kerberos (Windows Identity) se utiliza como el marco de autenticación, los roles en funcionamiento en la nube deben conectarse al Centro de distribución de Kerberos, o Kerberos Distribution Center (KDC). Sin embargo, el KDC y el controlador de dominio o domain controller (DC) nunca están expuestos a la web. Afortunadamente, Azure Connect permite establecer un VLN entre roles en ejecución en la nube y aquellos que están en los servidores locales. De esta manera, es posible establecer conexión entre Azure Roles y el controlador de dominio. Tales roles automáticamente se suscribirán al dominio y podrán usar sus identidades.
La aplicación ASP.NET introdujo proveedores de pertenencia, rol y perfil en el año 2005. Desde entonces, muchas aplicaciones web han usado su infraestructura sencilla pero ponderosa para administrar sus identidades. Las pertenencias definen a los usuarios, los roles asignan usuarios a grupos, y los perfiles guardan información arbitraria que pertenece a los usuarios.
ASP.NET define esquemas de bases de datos requeridos por los proveedores predeterminados. Este esquema se puede implementar como una base de datos separado o se puede combinar con la existente. En la configuración de la aplicación (ej. web.config), los proveedores se definen y se adjuntan a la base de datos mediante el uso de una cadena de conexión. Los proveedores usan ADO.NET para acceder los datos (TDS sobre puerto 1433). La conexión a SQL Azure es compatible con TDS, y así proporcionar una cadena de conexión a SQL Azure es completamente transparente para los proveedores. Una aplicación ASP.NET puede funcionar como un web rol y usar una base de datos implementada en SQL Azure para almacenar los datos del proveedor. Durante la migración de una aplicación a la nube, por lo tanto, todo lo que usted tiene que hacer es cargar la base de datos existente a SQL Azure y actualizar las cadenas de conexión. Si la información de identidad debe permanecer en las instalaciones locales (on-premises) es posible usar Azure Connect y apuntar cadenas de conexión al servidor que esté hospedando la base de datos.
El hecho de que todos los métodos de autenticación que son compatibles con ASP.NET (tales como autenticación Windows y autenticación de formas) aún son compatibles con Windows Azure remueve uno de los obstáculos más serios a la migración de aplicaciones.

Identidad basada en notificaciones
La administración de identidades es un nuevo enfoque del manejo de identidades. Fue diseñada para resolver algunos problemas y preocupaciones que despertó el enfoque de identidad basada en roles descritos anteriormente.
En el enfoque basado en notificaciones, un usuario presenta su identidad a la aplicación mediante el uso de un token que contiene una serie de claims o notificaciones. Una notificación podría ser el nombre del usuario; otra notificación podría ser una dirección de correo electrónico. La autenticación no la implementa la aplicación. Los usuarios autentican comprobando con un sistema externo de identidad conocido como un security token device (STS), que les proporciona tokens a los usuarios para que le entreguen a la aplicación. La aplicación puede después, de manera segura, usar la información que se encuentra en el token debido a la relación de confianza que se ha establecido entre el STS y la aplicación. Para cada solicitud que hace el usuario, el STS está configurado para darle a la aplicación todo lo que necesita saber acerca del usuario, además de la garantía criptográfica de que los datos de identidad recibidos en realidad proviene de una fuente de confianza.
Sacar la autenticación de las aplicaciones lleva a muchos beneficios para desarrolladores, profesionales de IT, y usuarios. Dicho de manera simple, hay menos cuentas de usuarios para que todas las personas manejen, y la centralización de autenticación que resulta hace que sea más fácil hacer un upgrade a métodos más fuertes de autenticación a medida que evolucionan, e incluso la identidad federada con otras plataformas y organizaciones.
En una solución basada en notificaciones, por lo tanto, la aplicación no necesita conectarse a ningún directorio de empresa en particular para buscar los detalles de la identidad de los usuarios. En cambio, la solicitud de los usuarios llega con todos los detalles de identificación que necesita la aplicación para hacer su trabajo. Para el momento en que llega el usuario con todas estas notificaciones, ya ha sido autenticado, y la aplicación puede seguir con sus asuntos sin preocuparse por administrar o buscar cuentas de usuario. El resultado es una aplicación más sencilla con menos código de infraestructura.
La unión con un nuevo asociado es sencilla en un escenario basado en notificaciones. La autenticación a través de un STS puede ser transitiva; si un socio tiene un STS que no es de confianza de la aplicación, pero se puede establecer la confianza entre este STS y otro STS que es de confianza de la aplicación, entonces los usuarios del asociado pueden proporcionar el STS de la aplicación con un token que han recibido de su propio proceso de autenticación, usando el token para adquirir otro token que después se puede utilizar para llamar a la aplicación.

– Escenario básico
El escenario básico identidad basada en notificaciones es relativamente sencillo.

Figura 1

La aplicación y el STS establecen una relación de confianza con el intercambio de claves criptográficas. (1).
La aplicación expone una política que define una lista de notificaciones que necesita y los STS de confianza que pueden producir dichas notificaciones.
Luego de recuperar esta política (2), el cliente contacta el STS (3), solicita las notificaciones requeridas por la aplicación. El STS autentica al usuario y le devuelve un token de seguridad que contiene todas las notificaciones.
El cliente luego hace la solicitud a la aplicación (4), enviando el token de seguridad con la solicitud del servicio. La aplicación valida el token y usa las notificaciones para hacerle una revisión al cliente y formular la respuesta.

– La Federación
Con el enfoque basado en notificaciones, la federación es sencilla de implementar porque la aplicación se desacopla de la administración de identidad y de los almacenes de identidad. Lo único que la aplicación necesita es un token de un STS de confianza; no necesita saber de qué manera el cliente suministró su identidad al STS y recibió el token. La federación es útil, por consiguiente, cuando una aplicación necesita proporcionar servicio a clientes que estén por fuera de su dominio natural. Esto podría surgir, por ejemplo, cuando un servicio interno disponible a los empleados de una compañía se extiende y debe servir a los empleados de un asociado también, cuyas identidades se administran por fuera de la compañía. Esta situación está ilustrada en la Figura 2.

Figura 2

En este ejemplo, la Administración de Contoso ha emitido órdenes administrativas al departamento de IT para permitir a los empleados de su asociado, Fabrikam, el uso de una aplicación que hasta el momento sólo ha estado disponible para empleados de Contoso. La política de servicio es muy sencilla: se presenta el token creada por el STS de Contoso, y se proveerá el servicio. Los empleados de Contoso pueden con facilidad recibir el token y usar el servicio, pero los empleados de Fabrikam no tienen la habilidad de usar el STS de Contoso. Por lo tanto, en lugar de incorporar una relación directa con el STS de Fabrikam a la aplicación, los empleados de Fabrikam pueden usar los tokens que han recibido del STS de Fabrikam para que el STS de Contoso les de un token basado en el hecho de que confía en el STS de Fabrikam.
Los empleados seran autenticados en el STS local de la organización (1), recibirán un token (2), y lo presentarán ante el STS de Contoso (3).
Cuando se ha establecido la confianza entre dos STS, las reglas de asignación de notificaciones se definieron. Usando estas reglas, el STS de Contoso asigna las notificaciones suministradas por el STS de Fabrikam y las utiliza para crear un token válido para la aplicación (4).
Luego de recibir el token producido por el STS de Contoso, los empleados de Fabrikam pueden enviarlo a al aplicación para recibir el servicio (5).

– Interoperabilidad
Los protocolos que ejecutan aplicaciones distribuidas deben estar estandarizadas para permitir la colaboración entre distintas tecnologías y plataformas. El grupo más popular de estándares relativas a servicios web se llama WS-*, y contiene estándares tales como WS- Security, WS-Federation y WS-Trust.
Es vital que el STS sea interoperable con todos los diferentes tipos de usuarios y usuarios de confianza que usarán sus servicios. Varios estándares de WS-* se usan en el escenario descrito anteriormente. La política se recupera usando http GET y la política en sí misma se estructura de acuerdo a las especificaciones de WS-Security, WS-Federation y WS-Trust. El STS expone los extremos que implementan la especificación de WS-Trust, que describe como hacer la solicitud y la recepción de tokens de seguridad. La mayoría de STS emiten tokens de SAML (Security Assertion Markup Language). SAML es un vocabulario XML reconocido por la industria que se puede usar para representar notificaciones de una manera interoperable.

SAML, con WS-Federation y WS-Trust standards, define todos los detalles alrededor de la autorización basada en notificaciones:
• Los escenarios de casos de autorización basada en notificaciones
• Los protocolos de comunicación
• Los jugadores y sus tareas en los protocolos
• La estructura de los metadatos expuestos por cada uno de los usuarios.

La adherencia a los estándares permite la comunicación con otros STS que estén en plataformas completamente distintas y permite inicio de sesión único en muchas aplicaciones, sin importar el tipo de plataforma.
El desarrollador se libra de tener que manejar todos los detalles de estándares de SAML y WS-*, porque WIF y ACS (descrito más adelante), hacen todo el trabajo pesado y proporcionan interfaces sencillas y modelos de objetos a ser usadas por el desarrollador.

– Escalabilidad y disponibilidad
El STS es un elemento principal en soluciones basadas en notificaciones. Si el STS está abajo (down) o no está disponible, los usuarios no podrán recibir tokens y por lo tanto no se les permitirá el uso de la aplicación. Adicionalmente, un STS individual probablemente se utilizará para servir a múltiples aplicaciones con distintas cargas de trabajo al mismo tiempo. Por esto, el STS debe estar diseñado para ser escalable y disponible en todo momento, y debería poder manejar picos impredecibles en la demanda. La nube es un entorno natural para hospedar este tipo de aplicación.
No es por lo tanto sorprendente que uno de los servicios proporcionado por la plataforma de Windows Azure es un STS. Este STS se llama Access Control Service (Servicio de Control de Acceso)

Access Control Service (ACS)
Windows Azure AppFabric Access Control Service (ACS) 2.0 es un servicio hospedado que proporciona autenticación federada y de autorización manejada por reglas basada en notificaciones para aplicaciones de Winddows Azure. Al desempeñar el rol de un recurso de STS que puede recibir notificaciones de usuarios externos y las transforma en notificaciones que la aplicación puede utilizar, ACS 2.0 les permite a los usuarios lograr una externalización real de las políticas de autorización, y de esta manera ofrece la oportunidad de desacoplar las aplicaciones para la mayoría de la lógica de autorización, al hospedar esa lógica (en la forma de reglas de transformación de notificaciones) en el ACS en sí.

ACS 2.0 les permite a los desarrolladores construir aplicaciones y servicios que acepten tanto identidades empresariales (a través de la integración con Active Directory Federation Services 2.0), y una amplia gama de identidades web (a través de la compatibilidad con identidades de Windows Live ID, OpenID, Google, Yahoo y Facebook) con el uso de un único código de base. ACS 2.0. proporciona compatibilidad con los formatos de token de SAML 1.1, SAML 2.) y Simple Web Token (SWT), y está plenamente integrado con el marco de Windows Identity Foundation (WIF).

Como se describió anteriormente, un STS es un servicio necesario para todas las aplicaciones basadas en notificaciones. Acces Control Service es un STS confiable, escalable y disponible que ofrece Azure para el uso de todas las aplicaciones basadas en notificaciones ejecutadas por clientes de Azure.
Access Control Service tiene un portal simple que es accesible desde el portal principal de Azure. Para crear un sTS, lo único que usted tiene que hacer es abrir un espacio de nombres en AppFabric y habilitar Access Control La configuración del STS consta de tres pasos principales:

Paso 1: Configurar proveedores de identidad.
Establezca la confianza con proveedores de identidad (STS) que emitirán tokens de entrada. Una vez establecida la confianza, el aCS puede procesar tokens que se originen de estos STS y asignar notificaciones de entrada a notificaciones de salida.
El ACS viene con una lisa de proveedores de identidad que ya son de la confianza de Azure, tales como Google, Yahoo y Windows Live ID. Usted puede seleccionar entre estos o establecer confianza con ACS y su propio ADFS 2.0 u otros STS predeterminados.

Paso 2: Establecer confianza con una aplicación de relying party (RP), o usuario de confianza.
En ACS, una aplicación de usuario de confianza es sólo una proyección de la aplicación al sistema. La RP define los URLs para la aplicación, la preferencia de formato de token, el tiempo de expiración del token, las opciones de firma del token, y las opciones de cifrado del token.

Paso 3: Definir reglas de asignación.
Defina las reglas de asignación que definen cómo ACS emitirá tokens a su aplicación de acuerdo a las notificaciones de entrada proporcionadas por los proveedores de identidad.

Después de la configuración, el portal proporciona una sección de Aplication Integration (Integración de la aplicación), que incluye toda la información necesaria para agregar una referencia STS (usando WIF) al ACS. Generalmente todo lo que usted necesita es el extremo de metadatos expuesto por el ACS.

Windows Identity Foundation
WIF es un marco para la implementación de aplicaciones para notificaciones. Puede ser utilizado en cualquier aplicación web, servicio web, aplicación de nube, o aplicación local.
WIF fue diseñada para facilitar la interacción con notificaciones al proporcionar un API simple y herramientas que unificarán y simplificarán aplicaciones para notificaciones. Está construido sobre el plumbing (la fontanería o las instalaciones sanitarias) de WCF y utiliza a cabalidad su sencillez y extensibilidad. WIF también implementa todos los estándares relacionados de
WS-* y SAML. WIF liberando al desarrollador de tener que manejar sus detalles. ,
WIF ofrece una variedad de otras posibilidades además: un API simple para administración de tokens y de notificaciones, una clase base para la construcción de un STS personalizado, ASP.NET HttpModules para procesamiento de tokens al interior del la canalización http de aplicaciones basadas en la red, y mucho más.
Con WIF, desarrollador está escudado de todo el trabajo pesado criptográfico requerido para implementar protocolos basados en notificaciones. WIF descifra el token de seguridad presentado por el cliente, valida su virma, valida cualquier clave de prueba, destruye el token en una serie de notificaciones, y los presenta al desarrollador a través de un modelo de objetos fácil de consumir.
WIF está plenamente integrado con Visual Studio 2010. Proporciona las herramientas necesarias para integrar compatibilidad con notificaciones en las aplicaciones web existentes a través de tan sólo unos pocos clics del mouse. WIF es la tecnología recomendada para integrar Azure AppFabric ACS en su aplicación.

Conclusión
Casi todas las aplicaciones deben manejar la identidad, que es un pilar principal en la aplicación de la seguridad. Windows Azure es compatible tanto con el enfoque de la identidad basada en notificaciones como con el enfoque la identidad basada en roles. La administración de la identidad no es un tema sencillo. La mayoría de los desarrolladores no son expertos en seguridad, y se sentirán incómodos al ser asignados las tareas de autenticar, autorizar, y personalizar experiencias para los usuarios.

La identidad basada en notificaciones saca la administración de la identidad fuera de los límites de la aplicación, liberando al desarrollador y al profesional IT de esa pesada carga de responsabilidad. Produce tokens que contienen información sobre el usuario en la forma de notificaciones. De estos tokens, la aplicación recibe toda la información que necesita sobre el usuario, y esta información se adjunta a la solicitud de servicio.
Crear un STS no es sencillo. Un STS debe ser escalable, confiable y disponible. Windows Azure APPFabric por eso ofrece una STS tal como un servicio: escalable, confianza y disponible por diseño, porque se ejecuta en una nube de Windows Azure.

Fuente: SeguridadIT

•