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

Azure AD como servidor de identidad

(Ver parte 1)

Como seguro que ya has deducido, AAD juega el papel de Authorization Server o Identity Provider (IDP). Esto es sólo una de las funcionalidades que ofrece AAD como servicio de identidad, ofreciendo otras muchas características que quedan fuera del alcance de esta serie de artículos. Simplemente comentar que como IDP, AAD implementa todos los flujos de autenticación de OAuth2.0, por lo que podemos seleccionar AAD como nuestro IDP para cubrir todos los flujos de autenticación.

Application Registration

Tal y como vimos en la primera parte, “el primer paso es incluir 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”. Si estás familiarizado con AAD te habrás dado cuenta que estas propiedades son propias de un Registro de Aplicación, Application Registration en terminología Azure.

Un App Registration pertenece a un único Tenant, independientemente de si sólo se va a acceder a la aplicación desde el propio tenant (single tenant) o desde cualquier directorio (multitenant), siendo el Client ID asociado único a nivel global (globally unique ID). Si bien el Client ID se asigna en el momento de crear el registro, tanto los secretos como los certificados pueden gestionarse en cualquier momento.

 

En resumen, al igual que un usuario real tiene su representación en AAD, un Application Registration es la representación de una aplicación, servicio, etc en el tenant donde reside.

Para habilitar el acceso a un determinado recurso, es necesario configurar los permisos de la aplicación, o dicho de otro modo, indicar el scope a nivel de registro de aplicación, de modo que el cliente pueda solicitar acceso a dicho scope, esto es que pueda solicitar acceso a realizar una operación determinada en un recurso determinado. Este paso simplemente indica a qué recursos podremos acceder y en qué forma, pero será necesario el consentimiento del Resource Owner antes de que el cliente pueda obtener el Access Token que le permita acceder a dicho recurso.

Digital Lover

A modo de ejemplo imaginemos que nuestro cliente final quiere acceder a la información de los usuarios por medio de Graph API (elegimos Graph porque está disponible en AAD de forma predeterminada, pero podría ser una aplicación ad-hoc con sus scopes previamente definidos a su vez en su registro de aplicación asociado).

Una vez configurado el Resource Owner podrá dar su consentimiento. Recordemos que consent hace referencia al proceso por el cual un usuario concede autorización para que una aplicación acceda a recursos protegidos en su nombre. Si bien existen distintos flujos y experiencias de consentimiento, lo fundamental es que en algún punto el Resource Owner deberá dar su consentimiento para permitir el acceso al recurso.

Service Principal

Cuando registramos una nueva aplicación desde el portal, Azure crea automáticamente una identidad asociada a dicha aplicación, un Service Principal o SP en terminología Azure. Ambas entidades están asociadas desde su creación hasta el momento que eliminemos el registro de aplicación.

Este Service Principal representa la identidad de la aplicación en el mismo tenant de Azure AD en el que se hizo el registro.

Esto permite tener diferentes SP en diferentes tenants asociados a un único registro de aplicación (recordemos que el registro de aplicación ocurre únicamente en el tenant asociado a la aplicación). Si un cliente hospedado en un AAD diferente quiere hacer uso de la aplicación, deberá crear un SP en su propio tenant que estará asociado al registro de aplicación único en el tenant original.

Esta separación entre Application Registration y Service Principal permite tener diferentes niveles de consentimiento para diferentes tenants.

Siguiendo con nuestro ejemplo, recordemos que en el registro de aplicación hemos definido el scope Graph - User.Read.All. Mediante el SP podremos visualizar y gestionar el estado del consentimiento sobre cada uno de los scopes definidos en el registro de aplicación.

Enterprise Apps

No es más que un listado de Service Principal. Es el sitio donde puedo gestionar todo lo relativo a permisos y consentimientos asociados a cada uno de los Service Principals.

Es interesante entender la clasificación que hace el propio portal en la pestaña de Enterprise Apps:

  • Enterprise Applications: son los SPs asociados a un registro de aplicación.
  • Managed Identities: SPs asociados a un recurso en Azure.
  • Microsoft Applications: SPs asociadas a aplicaciones de Microsoft.

Por tanto, la forma de gestionar permisos y consentimientos se realiza de la misma manera independientemente de si se trata de una aplicación custom que hayamos registrado, de un recurso de Azure o de una aplicación de Microsoft.

En la última entrega del post, pondremos en práctica todos los conceptos comentados creando una aplicación y realizando todos los pasos necesarios para invocar al recurso final.

 

 

Guía de posibilidades profesionales sobre Azure
He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA