{"id":3331,"date":"2017-02-10T07:42:00","date_gmt":"2017-02-10T10:42:00","guid":{"rendered":"http:\/\/www.radians.com.ar\/blog\/?p=3331"},"modified":"2020-06-29T18:18:43","modified_gmt":"2020-06-29T21:18:43","slug":"azure-active-directory-teoria","status":"publish","type":"post","link":"https:\/\/www.radians.com.ar\/blog\/?p=3331","title":{"rendered":"Azure Active Directory [Teoria]"},"content":{"rendered":"

\"z33\"<\/a>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. <\/p>\n

En el nivel m\u00e1s simple, Azure AD es una infraestructura de directorio escalable que proporciona almacenamiento, acceso a datos, replicaci\u00f3n y sincronizaci\u00f3n, registro de dispositivos y servicios de testigos de seguridad (STS). A continuaci\u00f3n se muestra un diagrama conceptual que muestra las interfaces p\u00fablicas y la superficie de gesti\u00f3n:<\/p>\n

\"www.radians.com.ar\"<\/a><\/p>\n

Core Directory Service<\/h4>\n

El servicio de directorio b\u00e1sico representa el coraz\u00f3n de Azure AD. Como servicio de directorio en la nube y con el objetivo de eliminar la necesidad de un almac\u00e9n espec\u00edfico de aplicaciones para informaci\u00f3n de identidad, Azure AD tiene como objetivo apoyar – dentro de los inquilinos propiedad de la organizaci\u00f3n – datos de inter\u00e9s com\u00fan en las aplicaciones de gran mayor\u00eda, Son aplicaciones de nube, SaaS, m\u00f3viles, etc., as\u00ed como las posibles relaciones entre esos datos.<\/p>\n

Modelo y esquema de datos<\/h4>\n

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\u00f3n. La informaci\u00f3n del servicio de directorio principal debe tener generalmente las siguientes caracter\u00edsticas:<\/p>\n

\u2022 P\u00fablico en el sentido de algo que es \u00fatil compartir en toda la organizaci\u00f3n, y no algo privado como el atributo de salario de un objeto de usuario,<\/p>\n

\u2022 Sobre todo est\u00e1tica durante el tiempo, y no cambiada a menudo,<\/p>\n

\u2022 Peque\u00f1o, generalmente punteros a la informaci\u00f3n contra la informaci\u00f3n s\u00ed mismo.<\/p>\n

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:<\/p>\n

\u2022 El servicio de directorio principal se divide en contextos de directorio, uno o varios por inquilino m\u00e1s un contexto del sistema. Cada contexto de directorio tiene un identificador de valor GUID no modificable, \u00fanico, 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.<\/p>\n

\u2022 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 \u00fanico y no exclusivo, es decir, un ID de objeto (ObjectId ).<\/p>\n

\u2022 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\u00e9 propiedades pueden aparecer en el objeto y la propiedad determina el tipo (cadena, binario, entero, estructura, etc.) y la multiplicidad de los valores.<\/p>\n

\u2022 Un objeto puede contener un conjunto de propiedades de navegaci\u00f3n que cada una corresponde a un enlace (o asociaci\u00f3n). Un enlace es una relaci\u00f3n 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\u00e1fico social de empresa tal como se discute en el blog de John Shewchuk. Los v\u00ednculos mantienen la integridad referencial: al eliminar el objeto de origen o de destino de la relaci\u00f3n se suprime impl\u00edcitamente el v\u00ednculo.<\/p>\n

\u2022 Las instancias de objeto (respectivamente enlace) pueden ser grupo en conjunto de<\/p>\n

Nota Para obtener informaci\u00f3n adicional, consulte el art\u00edculo 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\u00e1ndar LDAP v3 (y WSAD).<\/p>\n

Sin embargo, difiere de los directorios LDAP de las siguientes maneras:<\/p>\n

\u2022 A diferencia de las entradas de un directorio LDAP, los objetos no tienen nombres distinguidos y no est\u00e1n dispuestos en una jerarqu\u00eda multinivel distinguida. Los objetos pueden ser interpretados como teniendo varias relaciones jer\u00e1rquicas basadas en enlaces y valores de propiedad.<\/p>\n

\u2022 El directorio no admite la herencia de clase de objeto. En WSAD, esta capacidad se utiliz\u00f3 de manera muy limitada, pero a\u00f1adi\u00f3 una complejidad significativa al sistema.<\/p>\n

El esquema de directorio de Azure AD se define por versi\u00f3n espec\u00edfica. Puede evolucionar como fue el caso para el esquema del directorio de WSAD sobre el tiempo desde su primera introducci\u00f3n a principios de 2000. En general, las aplicaciones que consumen informaci\u00f3n 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:<\/p>\n

1. Una primera clase de aplicaci\u00f3n que corresponde a la gran mayor\u00eda no necesita extender el directorio y no tiene requisitos de extensibilidad a la direcci\u00f3n.<\/p>\n

2. Una segunda clase de aplicaciones tiene necesidades de extensibilidad muy simples donde necesitan publicar alguna informaci\u00f3n 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\u00edfico e hist\u00f3rico de los servicios de Microsoft, como Office 365.<\/p>\n

3. La clase final de aplicaciones es la que sin ninguna sorpresa que tiene necesidades de extensibilidad adicionales o extensas. Pueden mantener informaci\u00f3n importante sobre usuarios y otros objetos, y tambi\u00e9n 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\u00f3n.<\/p>\n

El uso de un almac\u00e9n local espec\u00edfico de la aplicaci\u00f3n para la extensibilidad podr\u00eda ser una opci\u00f3n en este caso. Con la llegada de la nube, las capacidades de almacenamiento est\u00e1n ampliamente disponibles a trav\u00e9s de servicios como el almacenamiento Azure y la base de datos Azure SQL. Una aplicaci\u00f3n que cae en este modelo puede mantener sus propias tablas en un servicio de almacenamiento. Un modelo t\u00edpico podr\u00eda ser que las filas de la tabla representen entidades de directorio Azure AD sobre las que la aplicaci\u00f3n mantiene su informaci\u00f3n. Una de las columnas de la tabla ser\u00eda una clave que identifica la entidad en el directorio (es decir, la clave de combinaci\u00f3n). Las otras columnas representan informaci\u00f3n espec\u00edfica de la aplicaci\u00f3n. La aplicaci\u00f3n 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\u00f3n.<\/p>\n

Dicho esto, Azure AD proporciona capacidad de extensibilidad de esquema personalizado (actualmente en vista previa p\u00fablica) en Azure AD Graph API que permite aumentar la entidad existente con atributos personalizados adicionales sin necesidad de un almac\u00e9n de datos externo. Un ejemplo com\u00fan puede consistir en almacenar un n\u00famero de n\u00f3mina para el usuario.<\/p>\n

A partir de esta escritura, las entidades mencionadas de Usuario, Grupo, TenantDetail, Dispositivo, Aplicaci\u00f3n 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\u00f3n para registrar, anular el registro, enumerar, leer, escribir y filtrar por propiedades de extensi\u00f3n. Las propiedades de extensi\u00f3n se registran en el objeto Aplicaci\u00f3n que corresponde a la aplicaci\u00f3n dentro del directorio. La aplicaci\u00f3n debe tener acceso de escritura para registrar una propiedad de extensi\u00f3n. 100 propiedades de extensi\u00f3n (a trav\u00e9s de TODOS los tipos y TODAS las aplicaciones) se pueden escribir en cualquier objeto individual.<\/p>\n

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

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<\/a>) y tambien Extending the Azure Graph Using the Azure Graph Store (http:\/\/msdn.microsoft.com\/en-us\/library\/azure\/dn720459.aspx<\/a>).<\/p>\n

Espero que les sea de interes y utilidad. Saludos. Roberto Di Lello<\/p>\n","protected":false},"excerpt":{"rendered":"

Hola, hoy vamos a seguir hablando sobre Azure Active Directory, principalmente vamos a hablar de…<\/p>\n","protected":false},"author":1,"featured_media":4291,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[303],"tags":[217,312],"class_list":["post-3331","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","tag-ad-domain-services","tag-azure"],"_links":{"self":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3331"}],"version-history":[{"count":1,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3331\/revisions"}],"predecessor-version":[{"id":3332,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3331\/revisions\/3332"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/media\/4291"}],"wp:attachment":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}