Compartir a través de

Introducción a los proveedores de identidades en Azure Stack Hub

  • Artículo

Azure Stack Hub requiere Microsoft Entra id. o Servicios de federación de Active Directory (AD FS) (AD FS), respaldado por Active Directory como proveedor de identidades. La elección de un proveedor es una decisión puntual que solo se toma la primera vez que implementa Azure Stack Hub. Los conceptos y la información detallada sobre la autorización que encontrará en este artículo pueden ayudarle a realizar su elección entre los proveedores de identidades.

La elección de Microsoft Entra id. o AD FS viene determinada por el modo en el que se implementa Azure Stack Hub:

  • Al implementarlo en un modo conectado, puede usar Microsoft Entra id. o AD FS.
  • Cuando se implementa en modo desconectado, sin una conexión a Internet, solo se admite AD FS.

Para más información sobre estas opciones, que dependen de su entorno de Azure Stack Hub, consulte los siguientes artículos:

Importante

Azure AD Graph está en desuso y se retirará el 30 de junio de 2023. Para obtener más información, consulte esta sección.

Conceptos comunes sobre los proveedores de identidades

En las secciones siguientes se tratan conceptos comunes sobre proveedores de identidades y su uso en Azure Stack Hub.

Terminología de proveedores de identidades

Organizaciones e inquilinos de directorios

Un directorio es un contenedor que alberga información sobre usuarios, aplicaciones, grupos y entidades de servicio.

Un inquilino de directorio es una organización, como Microsoft o su propia compañía.

  • Microsoft Entra id. admite varios inquilinos y puede admitir varias organizaciones, cada una en su propio directorio. Si usa Microsoft Entra id. y tiene varios inquilinos, puede conceder a las aplicaciones y usuarios de un inquilino acceso a otros inquilinos de ese mismo directorio.
  • AD FS solo admite un inquilino y, por lo tanto, una sola organización.

Usuarios y grupos

Las cuentas de usuario (identidades) son cuentas estándar que autentican a los usuarios mediante un identificador de usuario y una contraseña. Los grupos pueden incluir usuarios u otros grupos.

El modo en que cree y administre usuarios y grupos depende de la solución de identidad que use.

En Azure Stack Hub, las cuentas de usuario:

  • Se crean con el formato nombre_de_usuario@dominio. Aunque AD FS asigna las cuentas de usuario a una instancia de Active Directory, AD FS no admite el uso del formato \<dominio>\<alias>.
  • Se pueden configurar para usar autenticación multifactor.
  • Están restringidas al directorio donde primero se registran, que es el directorio de la organización.
  • Se pueden importar desde los directorios locales. Para obtener más información, consulte Integración de los directorios locales con Microsoft Entra id.

Al iniciar sesión en el portal del usuario de su organización, use la dirección URL https://portal.local.azurestack.external. Al iniciar sesión en el portal de Azure Stack Hub desde dominios que no sean el utilizado para registrar Azure Stack Hub, el nombre de dominio usado para registrar Azure Stack Hub se debe anexar a la dirección URL del portal. Por ejemplo, si Azure Stack Hub se ha registrado en fabrikam.onmicrosoft.com y el registro la cuenta de usuario es admin@contoso.com, la dirección URL que se usa para iniciar sesión en el portal de usuarios sería: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com..

Usuarios invitados

Los usuarios invitados son cuentas de usuario de otros inquilinos de directorio a los que se les ha concedido acceso a recursos de su directorio. Para admitir usuarios invitados, use Microsoft Entra id. y habilite la compatibilidad con multiinquilino. Una vez habilitada la compatibilidad, puede invitar a usuarios invitados a acceder a los recursos de su inquilino de directorio, lo que permite la colaboración con organizaciones externas.

Para invitar a usuarios invitados, los operadores de nube y los usuarios pueden usar Microsoft Entra colaboración B2B. Los usuarios invitados obtienen acceso a documentos, recursos y aplicaciones de su directorio, y usted mantiene el control sobre sus propios recursos y datos.

Como usuario invitado, puede iniciar sesión en otro inquilino de directorio de otras organizaciones. Para ello, debe anexar el nombre de directorio de esas organizaciones a la dirección URL del portal. Por ejemplo, si pertenece a la organización Contoso y desea iniciar sesión el directorio de Fabrikam, use https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Aplicaciones

Puede registrar aplicaciones en Microsoft Entra id. o AD FS y, a continuación, ofrecer las aplicaciones a los usuarios de su organización.

Las aplicaciones incluyen:

  • Aplicaciones web: algunos ejemplos son Azure Portal y Azure Resource Manager. Estas aplicaciones admiten llamadas API web.
  • Cliente nativo: algunos ejemplos son Azure PowerShell, Visual Studio y la CLI de Azure.

Las aplicaciones pueden admitir dos tipos de inquilinos:

  • Inquilino único: admiten usuarios y servicios solo del mismo directorio donde está registrada la aplicación.

    Nota

    Dado que AD FS solo admite un único directorio, las aplicaciones que se crean en una topología de AD FS son, por naturaleza, de un único inquilino.

  • Multiinquilino: los pueden usar los usuarios y servicios tanto del directorio donde la aplicación está registrada como de otros directorios de inquilino. Con las aplicaciones multiinquilino, los usuarios de otro directorio de inquilinos (otro Microsoft Entra inquilino) pueden iniciar sesión en la aplicación.

    Para más información sobre la arquitectura multiinquilino, consulte Habilitación de servicios multiinquilino.

    Para más información sobre cómo desarrollar una aplicación multiinquilino, consulte Aplicaciones multiinquilino.

Al registrar una aplicación, se crean dos objetos:

  • Objeto de aplicación: representación global de la aplicación en todos los inquilinos. Esta relación es de uno a uno con la aplicación de software y solo existe en el directorio donde la aplicación se registra primero.

  • Objeto de entidad de servicio: credencial que se crea para una aplicación en el directorio en que la aplicación se registró por primera vez. Una entidad de servicio también se crea en el directorio de cada inquilino adicional donde se usa esa aplicación. Esta relación puede ser de uno a varios con la aplicación de software.

Para obtener más información sobre los objetos de aplicación y entidad de servicio, consulte Objetos de aplicación y entidad de servicio en Microsoft Entra id.

Entidades de servicio

Una entidad de servicio es un conjunto de credenciales para una aplicación o servicio que conceden acceso a los recursos de Azure Stack Hub. El uso de una entidad de servicio separa los permisos de aplicación de los permisos del usuario de la aplicación.

Una entidad de servicio se crea en cada inquilino donde se usa la aplicación. La entidad de servicio establece una identidad para el inicio de sesión y el acceso a los recursos (por ejemplo, los usuarios) que están protegidos por ese inquilino.

  • Una aplicación de inquilino único tiene solo una entidad de servicio, en el directorio donde se crea la primera vez. Esta entidad de servicio se crea y permite que se use durante el registro de la aplicación.
  • Una API o aplicación web multiinquilino tiene una entidad de servicio que se crea en cada inquilino donde un usuario de ese inquilino permite el uso de la aplicación.

Las credenciales de las entidades de servicio pueden ser una clave generada mediante Azure Portal o un certificado. El uso de un certificado es adecuado para la automatización porque los certificados se consideran más seguros que las claves.

Nota

Cuando se usa AD FS con Azure Stack Hub, solo el administrador puede crear entidades de servicio. Con AD FS, las entidades de servicio requieren certificados y se crean mediante el punto de conexión con privilegios (PEP). Para más información, consulte Uso de una identidad de aplicación para acceder a recursos.

Para más información sobre las entidades de servicio de Azure Stack Hub, consulte Creación de entidades de servicio.

Servicios

Los servicios de Azure Stack Hub que interactúan con el proveedor de identidades se registran en él como aplicaciones. Al igual que las aplicaciones, el registro permite que un servicio se autentique con el sistema de identidad.

Todos los servicios de Azure usan protocolos OpenID Connect y tokens JSON Web Tokens (JWT) para establecer su identidad. Dado que Microsoft Entra id. y AD FS usan protocolos de forma coherente, puede usar la Biblioteca de autenticación de Microsoft (MSAL) para obtener un token de seguridad para autenticarse en el entorno local o en Azure (en un escenario conectado). Con MSAL, también puede usar herramientas como Azure PowerShell y la CLI de Azure para la administración de recursos entre nubes y locales.

Identidades y el sistema de identidad

Las identidades de Azure Stack Hub incluyen cuentas de usuario, grupos y entidades de servicio.

Cuando se instala Azure Stack Hub, varias aplicaciones y servicios integrados se registran automáticamente en el proveedor de identidades del inquilino de directorio. Algunos servicios que se registran se usan para la administración. Otros servicios están disponibles para los usuarios. Los registros predeterminados proporcionan identidades de servicio básicas que pueden interactuar unas con otras, y con identidades que se agreguen posteriormente.

Si configura Microsoft Entra identificador con varios inquilinos, algunas aplicaciones se propagan a los nuevos directorios.

Autenticación y autorización

Autenticación de usuarios y aplicaciones

Identidad entre capas de Azure Stack Hub

En el caso de aplicaciones y usuarios, la arquitectura de Azure Stack Hub se define en cuatro capas. Las interacciones entre cada una de estas capas pueden usar diferentes tipos de autenticación.

Nivel Autenticación entre capas
Herramientas y clientes, como el portal de administración Para acceder a un recurso de Azure Stack Hub o modificarlo, las herramientas y los clientes usan un token web JSON para realizar una llamada a Azure Resource Manager.
Azure Resource Manager valida el token web JSON e inspecciona las notificaciones del token emitido para estimar el nivel de autorización que el usuario o la entidad de servicio tienen en Azure Stack Hub.
Azure Resource Manager y sus servicios principales Azure Resource Manager se comunica con los proveedores de recursos para transferir la comunicación de los usuarios.
Las transferencias usan llamadas imperativas directas o llamadas declarativas mediante plantillas de Azure Resource Manager.
Proveedores de recursos Las llamadas pasadas a los proveedores de recursos están protegidas con autenticación basada en certificados.
Azure Resource Manager y el proveedor de recursos permanecen en comunicación mediante una API. El proveedor de recursos utiliza ese certificado para validar cada llamada recibida que se recibe de Azure Resource Manager.
Infraestructura y lógica de negocios Los proveedores de recursos se comunican con la lógica de negocios y la infraestructura mediante el modo de autenticación de su elección. Los proveedores de recursos predeterminados que se envían con Azure Stack Hub usan la autenticación de Windows para proteger esta comunicación.

Información necesaria para la autenticación

Autenticarse en Azure Resource Manager

Para autenticarse con el proveedor de identidades y recibir un token JWT, debe tener la siguiente información:

  1. Dirección URL del sistema de identidad (autoridad) : dirección URL a través de la que se puede acceder al proveedor de identidades. Por ejemplo, https://login.windows.net.
  2. Identificador URI del identificador de aplicación de Azure Resource Manager: el identificador único de Azure Resource Manager que se registra en el proveedor de identidades. También es único para cada instalación de Azure Stack Hub.
  3. Credenciales: la credencial que se usa para autenticarse con el proveedor de identidades.
  4. Dirección URL de Azure Resource Manager: la dirección URL es la ubicación del servicio Azure Resource Manager. Por ejemplo, https://management.azure.com o https://management.local.azurestack.external.

Cuando una entidad de seguridad (cliente, aplicación o usuario) realiza una solicitud de autenticación para acceder a un recurso, esa solicitud debe incluir:

  • Las credenciales de la entidad de seguridad.
  • El URI de identificador de aplicación del recurso al que la entidad de seguridad desea acceder.

Las credenciales se validan mediante el proveedor de identidades. El proveedor de identidades también valida que el URI del identificador de aplicación sea para una aplicación registrada y que la entidad de seguridad tenga los privilegios correctos para obtener un token para ese recurso. Si la solicitud es válida, se concede un JSON Web Token.

El token debe pasar entonces el encabezado de una solicitud a Azure Resource Manager. Azure Resource Manager realiza lo siguiente, sin un orden específico:

  • Valida la notificación issuer (iss) para confirmar que el token procede del proveedor de identidades correcto.
  • Valida la notificación audience (aud) para confirmar que el token se emitió a Azure Resource Manager.
  • Valida que el token JWT esté firmado con un certificado que se haya configurado mediante OpenID y que sea conocido para Azure Resource Manager.
  • Revisa las notificaciones issued at (iat) y expiry (exp) para confirmar que el token está activo y se puede aceptar.

Una vez realizadas todas las validaciones, Azure Resource Manager usa las notificaciones object id (oid) y groups para crear una lista de los recursos a los que puede acceder la entidad de seguridad.

Diagrama del protocolo de intercambio de tokens

Nota

Después de la implementación, no se requiere Microsoft Entra permiso de administrador global. Sin embargo, algunas operaciones pueden requerir las credenciales de administrador global (por ejemplo, un script del instalador del proveedor de recursos o una nueva característica que necesita la concesión de un permiso). Puede restablecer temporalmente los permisos de administrador global de la cuenta o usar una cuenta de administrador global independiente que sea propietaria de la suscripción del proveedor predeterminada.

Uso del control de acceso basado en rol

El control de acceso basado en rol (RBAC) de Azure Stack Hub es coherente con la implementación de Microsoft Azure. Puede administrar el acceso a los recursos mediante la asignación del rol de RBAC adecuado a los usuarios, los grupos y las aplicaciones. Para más información sobre cómo usar RBAC con Azure Stack Hub, consulte los artículos siguientes:

Autenticación con Azure PowerShell

Para más información sobre el uso de Azure PowerShell para autenticarse con Azure Stack Hub, consulte Configuración del entorno de PowerShell del usuario de Azure Stack Hub.

Autenticación con la CLI de Azure

Para más información sobre cómo usar Azure PowerShell para autenticarse con Azure Stack Hub, consulte Instalación y configuración de la CLI de Azure para su uso con Azure Stack Hub.

Azure Policy

Azure Policy ayuda a aplicar los estándares de la organización y a evaluar el cumplimiento a gran escala. Mediante su panel de cumplimiento, proporciona una vista agregada para evaluar el estado general del entorno, con la posibilidad de explorar en profundidad hasta el nivel de recurso y directiva. También ayuda al cumplimiento de los recursos gracias a la corrección masiva de los recursos existentes y la corrección automática de nuevos recursos.

Entre los casos de uso comunes de Azure Policy se incluye la implementación de la gobernanza para la coherencia de los recursos, el cumplimiento normativo, la seguridad, el costo y la administración. Las definiciones de directiva de estos casos de uso comunes ya están integrados en el entorno de Azure para ayudarle a comenzar.

Nota

Azure Policy no se admite actualmente en Azure Stack Hub.

Azure AD Graph

Microsoft Azure ha anunciado el desuso de Azure AD Graph el 30 de junio de 2020 y su fecha de retirada del 30 de junio de 2023. Microsoft ha informado a los clientes sobre este cambio por correo electrónico. Para obtener información más detallada, consulte el blog retirada de Azure AD Graph y desuso del módulo de PowerShell .

En la sección siguiente se describe cómo afecta este desuso a Azure Stack Hub.

El equipo de Azure Stack Hub está trabajando estrechamente con el equipo de Azure Graph para asegurarse de que los sistemas sigan funcionando más allá del 30 de junio de 2023, si es necesario, para garantizar una transición fluida. Lo más importante es asegurarse de cumplir con la directiva de mantenimiento de Azure Stack Hub. Los clientes recibirán una alerta en el portal de administración de Azure Stack Hub, y deberán actualizar el directorio principal y todos los directorios invitados incorporados.

La mayor parte de la migración se realizará mediante la experiencia de actualización del sistema integrada; Los clientes necesitarán un paso manual para conceder nuevos permisos a esas aplicaciones, lo que requerirá permisos de administrador global en cada directorio de Microsoft Entra que se use con los entornos de Azure Stack Hub. Una vez que el paquete de actualización con estos cambios finaliza la instalación, se genera una alerta en el portal de administración que le dirige para completar este paso mediante la interfaz de usuario multiinquilino o los scripts de PowerShell. Esta es la misma operación que se realiza al incorporar directorios o proveedores de recursos adicionales; para más información, consulte Configuración de multiinquilino en Azure Stack Hub.

Si usa AD FS como sistema de identidades con Azure Stack Hub, estos cambios de Graph no afectarán directamente al sistema. Sin embargo, las versiones más recientes de herramientas, como la CLI de Azure, Azure PowerShell, etc., requieren las nuevas API de Graph y no funcionarán. Asegúrese de usar solo las versiones de estas herramientas que sean explícitamente compatibles con la compilación de Azure Stack Hub determinada.

Además de la alerta en el portal de administración, comunicaremos los cambios a través de las notas de la versión de actualización, e informaremos qué paquete de actualización requiere actualizar el directorio principal y todos los directorios invitados incorporados.

Pasos siguientes