Archivado en la categoría (adAS, OAuth, PRiSE) por candido.rodriguez
Publicado el 16-02-2015

Logo de adAS

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

(0) Comments    Read More   
Archivado en la categoría (I+D+i, OAuth, PAPI) por diego.r.lopez
Publicado el 03-10-2014

Después de algunos años en los que ha venido demostrando su capacidad para desplegar infraestructuras de identidad digital a la vez flexibles, ligeras y seguras, al protocolo PAPI le han salido un par de primos de Zumosol que demuestran que las ideas que unos cuantos desarrollamos hace algún tiempo no eran tan malas, y que simplemente nacieron en un tiempo en el que XML y los esquemas complicados de Web Services era el credo dominante y cualquiera que fuera en contra de ellos era un hereje imperdonable.

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…

(0) Comments    Read More   
Archivado en la categoría (OAuth) por elena.lozano
Publicado el 28-10-2013

Como ya comentamos en anteriores entradas, OAuth es un protocolo que permite que una aplicación externa pueda obtener acceso de forma limitada a un servicio web que puede ser de su misma propiedad o de un usuario externo.

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.
(0) Comments    Read More   
Archivado en la categoría (OAuth) por elena.lozano
Publicado el 30-04-2010

Ya se ha publicado un borrador con la nueva versión del protocolo OAuth: OAuth 2.0.

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.
(0) Comments    Read More