Hola, hoy vamos a seguir hablando sobre Azure Active Directory, principalmente vamos a hablar de tu anatomia, sus componentes core, sus token de seguridad y algunas caracteristicas extras.

En el nivel más simple, Azure AD es una infraestructura de directorio escalable que proporciona almacenamiento, acceso a datos, replicación y sincronización, registro de dispositivos y servicios de testigos de seguridad (STS). A continuación se muestra un diagrama conceptual que muestra las interfaces públicas y la superficie de gestión:

Core Directory Service

El servicio de directorio básico representa el corazón de Azure AD. Como servicio de directorio en la nube y con el objetivo de eliminar la necesidad de un almacén específico de aplicaciones para información de identidad, Azure AD tiene como objetivo apoyar – dentro de los inquilinos propiedad de la organización – datos de interés común en las aplicaciones de gran mayoría, Son aplicaciones de nube, SaaS, móviles, etc., así como las posibles relaciones entre esos datos.

Modelo y esquema de datos

Los usuarios y los grupos suelen ser buenos ejemplos en los que las organizaciones desean crearlos una sola vez y reutilizarlos en sus aplicaciones o en aquellos para los que compran una suscripción. La información del servicio de directorio principal debe tener generalmente las siguientes características:

• Público en el sentido de algo que es útil compartir en toda la organización, y no algo privado como el atributo de salario de un objeto de usuario,

• Sobre todo estática durante el tiempo, y no cambiada a menudo,

• Pequeño, generalmente punteros a la información contra la información sí mismo.

No es sorprendente que Azure AD siga el modelo de datos de WSAD con los cambios adecuados para el uso de la nube. El modelo de datos es el siguiente:

• El servicio de directorio principal se divide en contextos de directorio, uno o varios por inquilino más un contexto del sistema. Cada contexto de directorio tiene un identificador de valor GUID no modificable, único, no reutilizable, un identificador de contexto, y contiene un conjunto de entidades (o objetos) y asociaciones (o enlaces) entre las entidades. Cada objeto o enlace pertenece exactamente a un contexto.

• Cada objeto tiene una clase o tipo de objeto (ObjectType): TenantDetail, Usuario, Contacto, Grupo, Dispositivo, Application, ServicePrincipal, etc. y un identificador de valor GUID no reemplazable, globalmente único y no exclusivo, es decir, un ID de objeto (ObjectId ).

• Un objeto contiene un conjunto de propiedades: DisplayName, UserPrincipalName, JobTitle, Department, TelephoneNumber, etc. Cada propiedad tiene un nombre y, si se establece, contiene un valor o un conjunto de valores. La clase de objeto determina qué propiedades pueden aparecer en el objeto y la propiedad determina el tipo (cadena, binario, entero, estructura, etc.) y la multiplicidad de los valores.

• Un objeto puede contener un conjunto de propiedades de navegación que cada una corresponde a un enlace (o asociación). Un enlace es una relación direccional, mecanografiada de un objeto a otro objeto, todo en el mismo contexto. El tipo de enlace es su clase de enlace: Manager, DirectReports, MemberOf, Members, etc. Los enlaces contribuyen significativamente a establecer un gráfico social de empresa tal como se discute en el blog de John Shewchuk. Los vínculos mantienen la integridad referencial: al eliminar el objeto de origen o de destino de la relación se suprime implícitamente el vínculo.

• Las instancias de objeto (respectivamente enlace) pueden ser grupo en conjunto de

Nota Para obtener información adicional, consulte el artículo de Microsoft MSDN ENTITY REFERENCE.
El esquema de directorio de Azure AD define las propiedades, las clases de objeto y las clases de enlace; Gran parte de ella es un subconjunto de los esquemas estándar LDAP v3 (y WSAD).

Sin embargo, difiere de los directorios LDAP de las siguientes maneras:

• A diferencia de las entradas de un directorio LDAP, los objetos no tienen nombres distinguidos y no están dispuestos en una jerarquía multinivel distinguida. Los objetos pueden ser interpretados como teniendo varias relaciones jerárquicas basadas en enlaces y valores de propiedad.

• El directorio no admite la herencia de clase de objeto. En WSAD, esta capacidad se utilizó de manera muy limitada, pero añadió una complejidad significativa al sistema.

El esquema de directorio de Azure AD se define por versión específica. Puede evolucionar como fue el caso para el esquema del directorio de WSAD sobre el tiempo desde su primera introducción a principios de 2000. En general, las aplicaciones que consumen información de directorio -y que, por lo tanto, se instancian como un objeto Application en el directorio- tienden a caer en las tres clases siguientes con respecto a los requisitos de extensibilidad de directorio:

1. Una primera clase de aplicación que corresponde a la gran mayoría no necesita extender el directorio y no tiene requisitos de extensibilidad a la dirección.

2. Una segunda clase de aplicaciones tiene necesidades de extensibilidad muy simples donde necesitan publicar alguna información sobre una entidad de directorio, como un usuario, a otras aplicaciones. Hasta la fecha, un mecanismo de extensibilidad integrado aborda este tipo de requisitos de extensibilidad en el contexto específico e histórico de los servicios de Microsoft, como Office 365.

3. La clase final de aplicaciones es la que sin ninguna sorpresa que tiene necesidades de extensibilidad adicionales o extensas. Pueden mantener información importante sobre usuarios y otros objetos, y también pueden tener necesidades complejas de consulta basadas en propiedades y enlaces. Estas consultas pueden estar en la ruta principal de alto volumen de la aplicación.

El uso de un almacén local específico de la aplicación para la extensibilidad podría ser una opción en este caso. Con la llegada de la nube, las capacidades de almacenamiento están ampliamente disponibles a través de servicios como el almacenamiento Azure y la base de datos Azure SQL. Una aplicación que cae en este modelo puede mantener sus propias tablas en un servicio de almacenamiento. Un modelo típico podría ser que las filas de la tabla representen entidades de directorio Azure AD sobre las que la aplicación mantiene su información. Una de las columnas de la tabla sería una clave que identifica la entidad en el directorio (es decir, la clave de combinación). Las otras columnas representan información específica de la aplicación. La aplicación puede utilizar la capacidad de consulta diferencial soportada por el directorio para gestionar el ciclo de vida de las filas en sus tablas utilizando la clave de combinación.

Dicho esto, Azure AD proporciona capacidad de extensibilidad de esquema personalizado (actualmente en vista previa pública) en Azure AD Graph API que permite aumentar la entidad existente con atributos personalizados adicionales sin necesidad de un almacén de datos externo. Un ejemplo común puede consistir en almacenar un número de nómina para el usuario.

A partir de esta escritura, las entidades mencionadas de Usuario, Grupo, TenantDetail, Dispositivo, Aplicación y ServicePrincipal pueden ampliarse con atributos de un solo valor de tipo "String" o "Binario". Azure AD Graph API proporciona para ello fines interfaces REST para una aplicación para registrar, anular el registro, enumerar, leer, escribir y filtrar por propiedades de extensión. Las propiedades de extensión se registran en el objeto Aplicación que corresponde a la aplicación dentro del directorio. La aplicación debe tener acceso de escritura para registrar una propiedad de extensión. 100 propiedades de extensión (a través de TODOS los tipos y TODAS las aplicaciones) se pueden escribir en cualquier objeto individual.

Las aplicaciones multi-tenant que registran propiedades de extensión en el directorio son referenciadas de todos los inquilinos que consienten a esa aplicación. Una vez que un inquilino del cliente ha consentido a una aplicación (incluso para leer) las propiedades de la extensión registradas en esa aplicación están disponibles en el inquilino que consiente para leer / escribir por cualquier aplicación que tenga el acceso apropiado.

Para mas informacion pueden ver los siguientes documentos en el sitio de Microsoft: Extend Azure Active Directory Schema using Graph API (http://blogs.msdn.com/b/aadgraphteam/archive/2014/03/06/extend-azure-active-directory-schema-using-graph-api-preview.aspx) y tambien Extending the Azure Graph Using the Azure Graph Store (http://msdn.microsoft.com/en-us/library/azure/dn720459.aspx).

Espero que les sea de interes y utilidad. Saludos. Roberto Di Lello