AAD. App Registration, Enterprise Application y Service Principals (Parte1)

Elementos involucrados en el proceso de Autenticación y Autorización

La gestión de identidad es siempre un tema complejo y que genera dudas en múltiples proyectos a la hora de implementar escenarios de autenticación / autorización (Authz / Authn) en el que distintos actores deben ser considerados en las políticas de acceso a nuestros recursos. La cosa se complica si los actores ya no son solo usuarios sino además aplicaciones, servicios, daemons, etc…

App Registration, Enterprise Applications, Service Principals, Managed Identities.. son todos elementos de Azure AD que aparecen habitualmente en discusiones de gestión de identidad.

A lo largo de una serie de entradas en este blog vamos a descifrar que representa cada una de ellas, cómo están relacionadas y cómo utilizarlas en los distintos escenarios de autenticación.

Antes de introducirse en la terminología propia de Azure, es fundamental entender ciertos elementos involucrados en los flujos de AUTHZ / AUTHN y este será el objetivo de esta primera entrada. Recomiendo en este punto una revisión de las distintas piezas que forman parte de OAuth 2.0, el protocolo de autorización que se ha convertido en un standard de facto en la industria, ya que los elementos involucrados son similares.

De acuerdo a la documentación de Microsoft…

“OAuth 2.0 es el protocolo de autorización del sector. Permite que un usuario conceda acceso limitado a sus recursos protegidos. Diseñado para trabajar específicamente con el Protocolo de transferencia de hipertexto (HTTP), OAuth separa el rol del cliente del propietario del recurso. El cliente solicita acceso a los recursos que controla el propietario del recurso y que hospeda el servidor de recursos. El servidor de recursos emite tokens de acceso con la aprobación del propietario del recurso. El cliente usa los tokens de acceso para acceder a los recursos protegidos que hospeda el servidor de recursos.”

Un buen resumen, pero algo engorroso y difícil de seguir si no se está familiarizado en la materia. Vamos a intentar explicarlo más detenidamente, ya que sienta las bases para entender las distintas entidades y recursos asociados en AAD.

El escenario de partida es un usuario que es el propietario de ciertos recursos. Este usuario sería el Resource Owner y los recursos estarían hospedados en un Resource Server. Estamos en un nivel de abstracción alto, pudiendo ser los recursos cualquier activo digital, tanto datos (ficheros, bases de datos…) como recursos de proceso (máquinas, contenedores…).

Los recursos tienen asociado un Scope que define qué acciones pueden realizarse sobre el recurso. Dependiendo del recurso las acciones pueden ser muy diferentes, por ejemplo podremos tener un scope con las acciones típicas Read y Write asociado a un recurso de tipo fichero, pero un scope diferente con otras acciones como por ejemplo ReadMail y SendMail asociadas a un recurso del tipo servidor de correo.

Para proteger los recursos en base al scope asociado a cada uno de ellos entra en juego una pieza nueva, denominada Authorization Server, que gestiona las distintas identidades, Security Principals, que representan a los diferentes actores. Siguiendo con nuestro ejemplo, nuestro Authorization Server contendría un Security Principal que representa al Resource Owner.

El protocolo se basa en la relación de confianza que se establece entre el Authorization Server y el Resource Server. Este último delega las tareas de autenticación en el primero, siendo este el proveedor de identidades del segundo, lo que se conoce como IDP o Identity Provider.

Introducimos en el escenario representado en el diagrama anterior un cliente que quiere acceder a alguno de nuestros recursos. Este cliente puede ser una aplicación pesada, una aplicación web, una aplicación móvil, una SPA, un servicio, lo que queramos. La solución rápida y totalmente desaconsejable es compartir con la aplicación cliente los usuarios y/o secretos necesarios para establecer la conexión con el recurso. Queremos evitar compartir estos secretos con cada uno de los clientes que accedan a nuestros recursos, pero sobre todo establecer unos mecanismos de authz / authn que garanticen que sólo se permiten accesos a ciertos clientes y que cada uno de los clientes sólo realiza las acciones a las que ha sido previamente autorizado. Para ello en primer lugar el Authz Server debe ser consciente de la existencia del cliente, por lo que el primer paso es dar de alta en el proveedor de identidad un Security Principal que represente al cliente y que tendrá un identificador único y opcionalmente un secreto o certificado exclusivo para este cliente. Una vez que el cliente está registrado, este podrá autenticarse contra el AUTH Server y solicitar acceso a los recursos con los permisos que necesite (scope). En este punto es importante destacar que las identidades del servidor de autenticación (principals) pueden ser personas, pero también servicios, procesos, etc.

En este punto entra en juego el consentimiento. Antes de permitir que el cliente acceda a los recursos solicitados, el Resource Owner deberá aprobar ese tipo de acceso previamente. No es necesaria una aprobación explícita por cada solicitud de acceso, ya que el consentimiento puede “recordarse”, esto es, mantenerse en el Security Principal asociado al cliente. Cómo se realiza este proceso depende del flujo de autenticación utilizado.

OAuth 2.0 ofrece varios flujos para distintos escenarios, pero en esencia no hay grandes diferencias entre unos y otros. Siguiendo con nuestro ejemplo, el flujo sería el siguiente.

El cliente realiza una petición solicitando acceso al recurso indicado en el scope.
Si el Resource Owner ha dado su consentimiento previamente, se devuelve el código de autorización, Auth Code, que permite al cliente solicitar tokens de acceso para llamar directamente al recurso (paso 5). Si no hay consentimiento, será necesaria la intervención del Resource Owner (paso 2, 3 y 4) antes de devolver el código de acceso.
Llegados a este punto el cliente tiene un Authz Code que por sí sólo no puede utilizar para acceder al recurso que necesita. El siguiente paso es obtener un Access Token que le permita acceso al recurso. En este punto el cliente utilizará su secreto o certificado en caso de que se haya configurado esta opción o PKCE (Proof Key for Code Exchange) para determinados flujos, que no es más que un secreto generado por el cliente en la primera llamada que puede ser verificado por el Authorization Server en llamadas sucesivas.
El servidor de autenticación devolverá el Access Token y el Refresh Token para renovar el primero. Adicionalmente puede solicitarse en el scope un Identity Token que contendrá información asociada a la identidad del cliente, el cual puede compartirse son el recurso final.

Hasta ahora no hemos hablado de recursos propios de Azure AD, simplemente comentar que todos los elementos que aparecen en los flujos explicados hasta este punto tendrán su representación de una u otra forma en Azure AD. En la siguiente entrada del blog haremos un mapeo de los elementos aquí mencionados con los recursos de Azure AD y entraremos en más detalle sobre los mismos.