Nuestros clientes evolucionan sus SSO’s integrando nuevos SP’s, estas son las últimas aplicaciones que se suman a nuestro single sign-on:

• Unidisc de UNIFICAT, producto ownCloud
• Kaltura
• Tangram
• Mathworks
• Office365
• appCrue

Infórmate sobre como adAS SSO facilita la integración y adaptación de  SP’s, contacta con nosotros!

Y recuerda que tenemos disponible LonginUp, nuestro SSO en la nube.

Tras un año de duro trabajo por parte de nuestro equipo técnico, nos complace anunciar la publicación de adAS 1.6.0, una nueva versión que trae grandes novedades entre las que destacamos las siguientes:

Arquitectura y código

Se ha realizado una evolución de la arquitectura y del código, de manera que estén asentadas las bases a las características más avanzadas de PHP. Para ello, se ha trabajado en los siguientes aspectos:

• Directorios: se ha separado tanto el código de la herramienta de administración del código de adAS, donde cada uno de ellos tiene una estructura diferenciada de las configuraciones con respecto al código
• Punto de entrada: se ha unificado en un solo archivo .php la entrada de los mensajes que recibe adAS, siendo así más fácil gestionar el despliegue en los servidores web
• Espacio de nombres en las clases: una evolución del código que permite ser compatible con la especificación PSR-4 de PHP

Fuentes de datos

Se ha incluido Sympa como fuente de datos disponible en adAS. Esto permite que puedan ser obtenidas las listas de correo a las que está suscrito un usuario y utilizar esta información tanto en una política de emisión de atributos como en una política de autorización.

Autenticación

Disponible ahora la autenticación delegada mediante Twitter, de manera que un usuario pueda autenticarse en adAS gracias a que ha realizado su autenticación en Twitter.

Además, se ha realizado una nueva implementación de la autenticación mediante certificado digital X.509, donde es más fácil gestionar la autenticación para certificados digitales de diferentes entidades certificadoras.

API Rest

adAS incorpora una API REST a través del cual aplicaciones externas podrán enviar operaciones y consultar información en adAS con respecto a configuraciones, atributos, eventos o información en las fuentes de datos, entre otros. Esta API está protegida mediante OAuth2 por lo que solo estará disponible para aquellas aplicaciones en las que sea necesario.

OAuth 2

Dentro de esta nueva versión de adAS, se ha implementado el perfil o grant «client credentials» del protocolo OAuth 2, siendo de interés para aquellos servicios que necesitan proteger un recurso y la autorización es en base a qué aplicación desea obtener dicho recurso protegido en vez de los datos del usuario que está interactuando con la aplicación. Nosotros lo utilizamos para proteger la API REST de adAS.

Nuestro objetivo es que en futuras versiones estén disponibles el resto de perfiles de OAuth 2, cubriendo así todos los posibles casos de uso que este protocolo define.

Logs

Se ha realizado una nueva implementación del sistema de logs tanto en adAS como en la herramienta de administración, donde ahora se podrán visualizar de manera más ágil y sencillo los mensajes que adAS ha generado en el sistema.

Eventos

La clasificación y visualización de eventos ha experimentado una evolución para facilitar la integración de eventos de cualquier procedencia.

Base de datos auxiliar

Hemos trabajado en evolucionar la actual base de datos auxiliar que utiliza adAS para utilizar servicios de cache como Redis o Memcache con el objetivo de obtener un mayor rendimiento. Es posible seguir utilizando una base de datos pero teniendo en cuenta que es posible que se obtenga un menor rendimiento que con dichos servicios de cache.

Herramienta de administración

La herramienta de administración de adAS también ha experimientado mejoras en sus características principales, como por ejemplo disponer de una cookie de sesión independiente de la obtenida en adAS o la posiblidad de incluir extensiones.

Para más información acerca de estas mejoras y de los bugs que corrije esta versión, consultar el archivo Release-Notes.txt

Hay un par iniciativas en el IETF que van tomando forma y cuya filosofía está muy cerca de lo que PAPI proponía y propone. Si alguien tiene curiosidad, una vuelta a las especificaciones de JOSE y HOBA. Incluso OAuth, un mecanismo de acceso más que consolidado, tiene mucho en común con el intercambio de tokens en PAPI.

Ser pionero e ir (un poco) contracorriente tiene sus problemas, pero a la larga da cierto placer sentirse reivindicado…

En general, el acceso a los recursos se realiza mediante la presentación de un token de acceso, el cual ha sido obtenido por el cliente (la aplicación que realiza las peticiones a los recursos) presentando unas credenciales que representan la autorización del dueño del recurso (otro usuario o la misma aplicación).

En el RFC donde se define la nueva versión del protocolo, OAuth 2.0 (RFC 6749), podemos encontrar diferentes casos de uso, los cuales se denominan Grants.

Existen cuatro tipos predefinidos, aunque es posible implementar extensiones según unas directivas generales definidas en el estándar.

En esta entrada comentaremos los usos de cada uno de estos grants predefinidos, así como algunas de sus características principales.

• Authorization Code Grant: Este Grant define cómo el cliente redirecciona al dueño del recurso a un servidor de autorización que ofrecerá un código de autorización al cliente. Ese código de autorización será la credencial presentada por el cliente para obtener el token de acceso.
• Implicit Grant: El cliente obtiene un token de acceso directamente, sin existir un código de autorización. Suele utilizarse para librerías javascript. Uno de sus inconvenientes es que la validación del cliente se realiza mediante la URI a la que se enviará el token, por lo que al no incluir autenticación del cliente, la seguridad puede verse comprometida.
• Resource Owner password credentials: Las credenciales que se utilizan son el usuario y la contraseña del usuario. Este perfil está recomendado sólo para casos en los que existe un grado elevado de confianza entre el dueño del recurso y el cliente y cuando el cliente es capaz de obtener las credenciales del propietario del recurso.
• Client Credentials Grant: Este grant es utilizado en casos donde el objeto de la autorización se limita a los recursos protegidos bajo el control del cliente, es decir; cuando el cliente es el propietario del recurso (actuando en su nombre) o el cliente realiza una petición de acceso a recursos protegidos basados en una autorización previa establecida con el servidor de autorización.

Esta nueva versión se basa en lo que ya se definía en el protocolo, pero añadiendo nuevos perfiles y flujos de autorización, basados en OAuth WRAP, específicos para aplicaciones web, de escritorio, teléfonos móviles e incluso aplicables a dispositivos como los sistemas multimedia para el salón.

Los nuevos flujos y perfiles desarrollados se dividen en tres tipos:

• Flujos de Delegación de Usuario (User Delegation Flows):
  Definen el protocolo de autorización para clientes que actúan en nombre de un usuario final. Hay distintos perfiles, dependiendo de la plataforma en la que se desarrollen: dispositivos externos, servidores web o programas de usuarios (navegadores web, etc.).
• Flujos de Usuarios Finales (End-User Credentials Flows):
  Se utiliza para clientes que actúan en nombre de los usuarios, pero permiten a la aplicación cliente tener acceso directo a las credenciales del usuario final, evitando el paso intermedio de pedir autorización al usuario directamente.
  Estos tipos de flujos requieren una relación de confianza mayor entre el cliente y los usuarios.
• Flujos autónomos (Autonomous Flows):
  Flujos que permiten al cliente actuar en su propio nombre mediante sus propias credenciales o una aserción que será capaz de leer el servidor de autorización y comprobar si es válida o no.

Dentro de los perfiles ya establecidos existen dos tipos: Perfiles de Clientes Autónomos (Autonomous Client Profiles), donde el Cliente actúa en su nombre y Perfiles de Delegación del Usuario (User Delegation Profiles), donde el Cliente actúa en nombre de un usuario determinado.

Los perfiles de Clientes Autónomos son dos:

Perfil de cuenta de Cliente con contraseña (Client Account and Password Profile):

Este perfil se utiliza cuando el Cliente es una aplicación que necesita un Recurso Protegido en nombre de una organización y el Servidor de Autorización acepta cuentas y contraseñas como método de autenticación.

Perfil de Aserción: (Assertion Profile)

Este perfil autoriza al cliente con una aserción, ya sea SAML u otro tipo que reconozca el Servidor de Autorización. El cliente presenta esta aserción al Servidor de Autorización y se intercambiarán por el Token de Acceso que permitirá acceder al recurso protegido.

Existen tres tipos de perfiles de Delegación del Usuario:

Perfil denombre de usuario y contraseña (Username and Password Profile):

El usuario da su nombre de usuario y contraseña a la aplicación Cliente que tiene instalada en su dispositivo. Con estos datos, el Cliente presenta sus credenciales al Servidor de Autorización para así intercambiarlas por un Token de Acceso que le permita acceder al recurso protegido.

Perfil Aplicación Web (Web App Profile)

Consiste en que el usuario se autentique de alguna forma determinada establecida de antemano en la aplicación web Cliente. Este perfil se utiliza cuando el Cliente es una aplicación web que accede al Recurso Protegido en nombre del usuario sin necesidad de adquirir las credenciales de los mismos.

Rich App Profile:

Se utiliza cuando el Cliente es una aplicación que el Usuario ha instalado en un dispositivo y está disponible en él un navegador web, pero el usuario no desea dar su nombre de usuario y contraseña a una aplicación o no necesita estos parámetros para autenticarse en el Servidor de Autorización.

En esta entrada vamos a comentar una extensión que está siendo definida actualmente y que amplía nuestra perspectiva a la hora de utilizar este protocolo.

Hablamos de OAuth WRAP (OAuth Web Resource Authorization Profiles), la cual nació para intentar simplificar a OAuth, eliminando sus procesos de firma y reemplazándolas por tokens de corta duración sobre SSL/TLS.

WRAP no pretende sustituir a OAuth, pero sí añadir nuevas características que completen y desarrollen elementos de los cuales carece el protocolo en su versión original.

Esta extensión permite la delegación de la autorización de recursos protegidos a una o más autoridades de confianza. Los Clientes que desean acceder a un Recurso Protegido primero obtienen autorización de un Servidor de Autorización, enviando para ello unas credenciales y perfiles determinados.

Una vez autorizados, el Cliente obtiene un Token de Acceso (Access Token) firmado digitalmente que podrá ser reemitido en caso de ser necesario y que permitira, como su nombre indica, acceder a los recursos protegidos.

OAuth WRAP define distintos perfiles que especifican las credenciales que deben enviarse al Servidor de Autenticación y cómo las obtendrá el Cliente. Es posible especificar perfiles propios e incluso adoptar los que ya están establecidos. En posteriores posts os comentaremos algunos de ellos.

El escenario en el que nos encontramos es el indicado en la figura, en el cual un cliente realiza conexiones HTTPS contra un IdP (Proveedor de Identidad) para acceder a un sistema SSO y por ende a recursos protegidos. Dónde al logarse el cliente con éxito, el IdP genera una aserción sobre quién es el cliente y qué atributos posee, el IdP firma esta aserción con el mismo certificado que se ha usado para establecer la conexión HTTPS.

Escenario

El problema, o mejor dicho, el origen de las inquietudes reside en el uso del mismo certificado para la conexión HTTPS y para la firma de la aserción o de cualquier otro tipo de metadatos, y en el cual confían los SPs (proveedor de servicio) que han establecido relaciones de confianza con el IdP.

Pues bien, estas inquietudes se basan en la creencia incierta de que un servidor web firmará alegremente cualquier cosa presentada por el cliente en el ‘random binary blob‘ durante el SSL-handshake. Si esto fuese cierto un atacante tendría la capacidad de enviar como ‘random binary blob‘ una aserción falsa, que al ser firmada por el certificado x509 en el que confían los SPs, le diese la capacidad de acceder a recursos a los cuales no tiene acceso.

Esto es totalmente falso, ya que bajo ninguna circunstancia un servidor web firmará datos arbitrarios presentados por un cliente. Para aclarar esto voy a explicar que datos presenta el cliente al servidor y que son susceptibles de ser firmados.

Durante el handshake del  protocolo TLS/SSL se genera el master secret, el cual es un secreto compartido entre el cliente y el servidor, de 48 bytes y que es usado como clave simétrica para proteger la sesión. Este master secret, se genera mediante la siguiente función:

master_secret = PRF(pre_master_secret, "master secret",
                    ClientHello.random + ServerHello.random);

Donde PRF es la Pseudoroandom Function elegida de la cipher-suite- especificada en fases previas del handshake, la cual es una función basada en HMAC, que no usa en ningún momento la clave privada del certificado.
El pre_master_secret, es una cadena de 48 bytes enviada por el cliente al servidor y que es lo que nos interesa en este caso, ya que representa los únicos datos que el servidor cifra de forma «alegre».
La cadena «master secret» es una constante con dicho valor.
Y por último las cadenas ClientHello.random y ServerHello.random son dos blob de 28 bytes, el primero enviado por el cliente en la fase ClientHello del handshake y el segundo enviado por el servidor en la fase ServerHello.

Como he dicho anteriormente, nos interesa el pre_master_secret, ya que esta cadena son 48 bytes, de los cuales 46 son generados aleatoriamente por el cliente y 2 indican el protocolo. Estos 48 bytes son cifrados con la clave pública del servidor. Y es este cifrado el punto que ha generado tanta controversia.
Pues bien, al cifrarse estos datos con la clave pública del servidor, es este servidor el único que puede descifrar y por tanto entender estos datos, ya que es el único en posesión de la clave privada correspondiente.
Con esto, si un cliente malintencionado en vez de generar 46 bytes aleatorios, introduce la aserción falsa, lo que obtendría es un mensaje cifrado que sólo puede leer quien posea la clave privada del servidor. La cual no está en posesión de los SPs, ya que estos sólo necesitan la clave pública, para comprobar la firma de las aserciones.

Como conclusión, decir que podemos estar seguros de usar el mismo certificado x509 tanto para asegurar sesiones con TLS/SSL como para firmar aserciones o metadatos ya que según la especificación del protocolo TLS los datos que un servidor cifra «alegremente», sólo los puede descifrar él.

Por último decir que separar por roles el uso de claves privadas de los certificados x509, es decir, usar una para TLS y otra para firmar aserciones y/o metadatos, es una buena práctica de seguridad. Ya que  aunque TLS ha sido diseñado para resistir ataques contra autenticación y firmado, la historia nos ha demostrado muchas veces que confiar en la calidad de un algoritmo o protocolo y en su implementación debería evitarse en la medida de lo posible.

En esta entrada vamos a comentaros los dos escenarios que pueden configurarse con OAuth y que nos hace a los desarrolladores la vida un poco más fácil:

El primer de ellos es el escenario con Acceso Delegado (3-legged scenario), en el cual hay tres actores: Cliente, Propietario del Recurso y Servidor. El Cliente pide acceso a los recursos en nombre de un propietario de un recurso concreto. En este caso las Credenciales que serán necesarias intercambiar para garantizar un mínimo de seguridad son las propietario del recurso y las del cliente. Este escenario es el que ilustrábamos en nuestro anterior post.

El otro escenario que se propone es el que tiene un Acceso Directo ( 2-legged scenario). Los actores en este escenario son sólo dos: Cliente y Servidor. Esta situación se da cuando el Cliente pide acceso a los recursos en su nombre. En este caso el Cliente y el Propietario del Recurso serán la misma entidad y sólo será necesario enviar las Credenciales del Cliente.

Su origen se remonta a la necesidad de querer establecer un protocolo estándar que sacara factor común de las buenas prácticas existentes en los distintos sistemas de autenticación existentes, como por ejemplo Google AuthSub , AOL OpenAuth , Flickr API y Amazon Web Services API entre otras.

Para ilustrar las ventajas de OAuth, veamos el siguiente ejemplo: Una aplicación nueva incluye un servicio de avisos de fechas importantes que deberá importar de otra aplicación, por ejemplo, la agenda del gestor de correo. Para poder activar el servicio es necesario que el sujeto en cuestión le de su nombre de usuario y contraseña para así acceder al gestor de correo. El resultado obtenido es que ambas aplicaciones funcionan correctamente, pero existe un inconveniente primordial: la aplicación que da el servicio de avisos ya tiene su contraseña, lo cual puede llevar a un problema de seguridad grave.

OAuth intenta solucionar esta problemática restringiendo el acceso a los recursos. En el ejemplo anterior, mediante OAuth se habría conseguido que la aplicación servidora sólo pudiera acceder a la información del calendario, evitando así tener que darle el nombre de usuario y contraseña y que hubiera un acceso ilimitado a la información contenida en el gestor de correo.

En vez de utilizar nombre de usuario y contraseña, OAuth utilizará unas credenciales que permitirán el acceso a uno o varios recursos por un periodo de tiempo determinado.