Compartir por

Escenario: Uso de Microsoft Entra ID para proteger el acceso a las plataformas y aplicaciones de SAP

  • Artigo

En este documento se proporcionan consejos sobre el diseño técnico y la configuración de las plataformas y aplicaciones de SAP a la hora de usar Microsoft Entra ID como principal servicio de autenticación del usuario para SAP Cloud Identity Services. SAP Cloud Identity Services incluye la autenticación de identidad, el aprovisionamiento de identidad, el directorio de identidad y la administración de autorización. Obtenga más información sobre la configuración inicial para la autenticación en la integración del inicio de sesión único (SSO) de Microsoft Entra con SAP Cloud Identity Services. Para obtener más información sobre el aprovisionamiento y otros escenarios, consulte Planificar la implementación de Microsoft Entra para el aprovisionamiento de usuarios con aplicaciones de origen y destino SAP y Administrar el acceso a las aplicaciones SAP.

Terminología usada en esta guía

Abreviatura Descripción
BTP SAP Business Technology Platform es una plataforma de innovación optimizada para aplicaciones SAP en la nube. La mayoría de las tecnologías de SAP que se analizan aquí forman parte de BTP. Los productos conocidos formalmente como SAP Cloud Platform forman parte de SAP BTP.
IAS SAP Cloud Identity Services - Identity Authentication, un componente de SAP Cloud Identity Services, es un servicio en la nube para la autenticación, el inicio de sesión único y la administración de usuarios en aplicaciones locales y en la nube de SAP. IAS ayuda a los usuarios a autenticarse en sus propias instancias de servicio de SAP BTP, como un proxy que se integra con el inicio de sesión único de Microsoft Entra.
IPS SAP Cloud Identity Services: Identity Provisioning, un componente de SAP Cloud Identity Services, es un servicio en la nube que le ayuda a aprovisionar identidades y su autorización a la nube de SAP y a la aplicación local.
XSUAA Servicios extendidos para la autenticación y las cuenta de usuario de Cloud Foundry. Cloud Foundry, una plataforma como servicio (PaaS) que se puede implementar en distintas infraestructuras, es el entorno en el que SAP creó SAP Business Technology Platform. XSUAA es un servidor de autorización de OAuth multiinquilino que consituye el componente de infraestructura central del entorno de Cloud Foundry. XSUAA proporciona autenticación y autorización de usuarios empresariales en SAP BTP.
Fiori El entorno web de SAP (frente al entorno de escritorio).

Introducción

En la pila tecnológica de SAP y Microsoft, hay muchos servicios y componentes que tienen un rol en los escenarios de autenticación y autorización de usuarios. Los principales servicios se enumeran en el diagrama siguiente.

Introducción al entorno de SAP

Dado que hay muchas permutaciones de los posibles escenarios que se pueden a configurar, nos centramos en un escenario que está en línea con una estrategia de primera identidad de Microsoft Entra. En este artículo, se considera que se dan todos estos factores:

  • Quiere gobernar todas las identidades de forma centralizada y solo desde Microsoft Entra ID.
  • Quiere reducir los esfuerzos de mantenimiento tanto como sea posible y automatizar la autenticación y el acceso a las aplicaciones en Microsoft y SAP.
  • Las instrucciones generales para Microsoft Entra ID con IAS se aplican tanto a las aplicaciones implementadas en BTP como a las aplicaciones SaaS de SAP configuradas en IAS. También se proporcionarán recomendaciones concretas cuando se pueda aplicar a BTP (por ejemplo, el uso de asignaciones de roles con grupos de Microsoft Entra ID) y aplicaciones SaaS de SAP (por ejemplo, el uso del servicio de aprovisionamiento de identidades para la autorización basada en roles).
  • Además, se supone que los usuarios ya están aprovisionados en Microsoft Entra ID y en cualquier sistema SAP que requiera que los usuarios estén aprovisionados para funcionar. Irrelevancia de la forma en que se haya logrado: el aprovisionamiento se puede hacer realizado de forma manual, desde un entorno local de Active Directory hasta Microsoft Entra Connect o a través de sistemas de RR. HH. como SAP SuccessFactors. Por consiguiente, en este documento, SuccessFactors se considera una aplicación como cualquier otra en la que los usuarios (existentes) van a iniciar sesión. No se cubre el aprovisionamiento real de usuarios que se realiza en SAP SuccessFactors desde SuccessFactors. Para obtener más información sobre cómo incorporar usuarios a Microsoft Entra ID para su uso con cargas de trabajo de SAP, consulte Planificar la implementación de Microsoft Entra para el aprovisionamiento de usuarios con aplicaciones de origen y destino SAP y Administrar el acceso a las aplicaciones SAP.

En función de estas suposiciones, nos centramos principalmente en los productos y servicios que se presentan en el diagrama siguiente. Estos son los componentes más relevantes para la autenticación y autorización en un entorno basado en la nube.

Servicios de SAP en el ámbito

Si ha estado usando SAP Identity Management (IDM), puede migrar escenarios de administración de identidades de SAP IDM a Microsoft Entra. Para obtener más información, consulte Migrar escenarios de administración de identidades de SAP IDM a Microsoft Entra.

Nota:

La mayoría de las guías que se indican también se aplican a Azure Active Directory B2C, pero hay algunas diferencias importantes. Para obtener más información, consulte Uso de Azure AD B2C como el proveedor de identidades.

Advertencia

Tenga en cuenta los límites de la aserción SAML de SAP y el impacto de la longitud de los nombres de las recopilaciones de roles de Cloud Foundry de SAP y la cantidad de recopilaciones proxy por grupos en servicios de identidad en la nube de SAP. Para obtener más información, consulte la nota de SAP 2732890 en SAP for Me. Los límites superados dan lugar a problemas de autorización.

Recomendaciones

Resumen

1: Uso de la autenticación federada en SAP Business Technology Platform y aplicaciones SaaS de SAP a través de SAP Identity Authentication Service

Contexto

Las aplicaciones de BTP pueden usar proveedores de identidades a través de configuraciones de confianza para autenticar a los usuarios mediante el protocolo SAML 2.0 entre BTP/XSUAA y el proveedor de identidades. Tenga en cuenta que solo se admite SAML 2.0, aunque el protocolo openID Connect se usa entre la propia aplicación y BTP/XSUAA (no es relevante en este contexto).

En BTP, puede optar por configurar una configuración de confianza en SAP Cloud Identity Services - Identity Authentication (que es el valor predeterminado), pero cuando el directorio de usuario autoritativo es Microsoft Entra ID, puede configurar la federación para que los usuarios puedan iniciar sesión con sus cuentas de Microsoft Entra existentes.

Además de la federación, también puede configurar el aprovisionamiento de usuarios, con el fin de que los usuarios de Microsoft Entra se aprovisionen por adelantado en BTP. Sin embargo, no hay compatibilidad nativa para esta operación (solo para Microsoft Entra ID -> SAP Identity Authentication Service); una solución integrada con compatibilidad nativa sería el servicio BTP Identity Provisioning Service. El aprovisionamiento de cuentas de usuario por adelantado puede resultar útil para la autorización (por ejemplo, para agregar usuarios a roles). Sin embargo, según cuáles sean los requisitos, se puede lograr el mismo objetivo con grupos de Microsoft Entra (más abajo encontrará información al respecto), lo que puede significar que no se necesita el aprovisionamiento de usuarios.

Al configurar la relación de federación, hay varias opciones:

  • Puede optar por realizar la federación en Microsoft Entra ID directamente desde BTP/XSUAA.
  • Otra opción es realizar la federación con IAS, que a su vez está configurado para realizarla con Microsoft Entra ID como Proveedor de identidades corporativas (lo que también se conoce como "conexiones proxy de SAML").

En las aplicaciones SaaS de SAP, IAS está aprovisionado y preconfigurado, con el fin de facilitar la incorporación de usuarios finales (Algunos ejemplos de esto son SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud, entre otros). Este escenario es menos complejo, ya que IAS se conecta directamente con la aplicación de destino y no se conecta como proxy a XSUAA. En cualquier caso, para esta configuración se aplican las mismas reglas que para Microsoft Entra ID con IAS en general.

¿Qué se recomienda?

Cuando el directorio de usuario autoritativo es Microsoft Entra ID, se recomienda realizar una configuración de confianza en BTP hacia IAS. A su vez, IAS se configura para realizar la federación con Microsoft Entra ID como Proveedor de identidades corporativas.

Configuración de confianza de SAP

En la configuración de confianza de BTP, se recomienda habilitar "Create Shadow Users During Logon" (Crear usuarios paralelos durante el inicio de sesión). De este modo, los usuarios que aún no se han creado en BTP obtienen automáticamente una cuenta cuando inician sesión a través de IAS/Microsoft Entra ID por primera vez. Si esta configuración se deshabilita, solo podrán iniciar sesión los usuarios que se hayan aprovisionado previamente.

Motivos para esta recomendación

Cuando use la federación, puede elegir definir la configuración de confianza en el nivel de subcuenta de BTP. En ese caso, debe repetir la configuración de las demás subcuentas que use. El uso de IAS como configuración de confianza intermedia, no solo le permite beneficiarse de una configuración centralizada en varias subcuentas, sino que también le permite usar características de IAS como la autenticación basada en riesgos y el enriquecimiento de atributos de aserción centralizado. Para proteger la experiencia del usuario, estas características de seguridad avanzadas no se deben aplicar en más de una ubicación, Este puede ser IAS o si se mantiene Microsoft Entra ID como almacén de usuario autoritativo único (como es el caso de este documento), la administración de acceso condicional de Microsoft Entra lo controlaría centralmente.

Nota: En el caso de IAS, cada subcuenta se considera una "aplicación", aunque dentro de ella se puedan implementar una o varias aplicaciones. Dentro de IAS, cada aplicación de este tipo se puede configurar para la federación con el mismo Proveedor de identidades corporativas (en este caso, Microsoft Entra ID).

Resumen de la implementación

En Microsoft Entra ID:

En Microsoft Entra ID e IAS:

  • Siga los pasos que encontrará en la documentación para conectar Microsoft Entra ID a IAS en modo de federación (proxy) (documentación de SAP, documentación de Microsoft). Fíjese en el valor NameID de la configuración del inicio de sesión único en Microsoft Entra ID, ya que los nombres principales de usuario no son necesariamente direcciones de correo electrónico.
  • Configure la "aplicación agrupada" para que use Microsoft Entra ID; para ello, vaya a la página de "Autenticación condicional" y como "Proveedor de identidades de autenticación predeterminado" elija el Proveedor de identidades corporativas que represente su directorio de Microsoft Entra.

En BTP:

  • Realice una configuración de confianza para IAS (documentación de SAP) y asegúrese de que las opciones "Available for User Logon" (Disponible para inicio de sesión de usuario) como "Create Shadow Users During Logon" (Crear usuarios paralelos durante el inicio de sesión) estén habilitadas.
  • Opcionalmente, deshabilite "Disponible para inicio de sesión de usuario" en la configuración de confianza predeterminada de "SAP ID Service" para que los usuarios siempre se autentiquen a través de Microsoft Entra ID y no les aparezca ninguna pantalla en la que puedan elegir su proveedor de identidades.

2: Uso de Microsoft Entra ID para la autenticación e IAS/BTP para la autorización

Context

Si BTP e IAS se han configurado para que la autenticación de usuarios se realice a través de la federación hacia Microsoft Entra ID, hay varias opciones para configurar la autorización:

  • En Microsoft Entra ID, puede asignar usuarios y grupos de Microsoft Entra a la aplicación empresarial que representa la instancia de IAS de SAP en Microsoft Entra ID.
  • En IAS, puede usar la autenticación basada en riesgos para permitir o bloquear los inicios de sesión y, de esa forma, impedir el acceso a la aplicación en BTP.
  • En BTP, puede usar colecciones de roles para definir qué usuarios y grupos pueden acceder a la aplicación y obtener determinados roles.

¿Qué se recomienda?

Se recomienda no colocar ninguna autorización directamente en el propio Microsoft Entra y desactivar explícitamente "Asignación de usuarios necesaria" en la aplicación empresarial de Microsoft Entra ID. Tenga en cuenta que, en el caso de las aplicaciones SAML, este valor está habilitado de forma predeterminada, por lo que es preciso realizar una acción explícita para deshabilitarlo.

Motivos para esta recomendación

Cuando la aplicación se federa a través de IAS, desde el punto de vista de Microsoft Entra ID el usuario se "autentica en IAS" durante el flujo del inicio de sesión. Esto significa que Microsoft Entra ID no tiene información sobre la aplicación BTP final en la que el usuario intenta iniciar sesión. También implica que la autorización en Microsoft Entra ID solo se puede usar para realizar una autorización muy general, por ejemplo, permitir que el usuario inicie sesión en cualquier aplicación de BTP o en ninguna. Esto también resalta la estrategia de SAP para aislar las aplicaciones y los mecanismos de autenticación en el nivel de subcuenta de BTP.

Aunque podría ser una razón válida para usar la opción "Asignación de usuarios necesaria", significa que ahora hay potencialmente dos lugares diferentes donde es preciso mantener la información de autorización: tanto en Microsoft Entra ID, en la aplicación empresarial (donde se aplica a todas las aplicaciones de BTP), como en cada subcuenta de BTP. Esto podría provocar confusión y errores de configuración cuando la configuración de autorización se actualiza en un lugar, pero no en el otro. Por ejemplo, se permitió a un usuario en BTP, pero no se le asignó a la aplicación en Microsoft Entra ID, por lo que se produce un error de autenticación.

Resumen de la implementación

En la aplicación empresarial de Microsoft Entra ID que representa la relación de federación con IAS, deshabilite "Asignación de usuarios necesaria". Esto también significa que se puede omitir de forma segura la asignación de usuarios.

3: Uso de grupos de Microsoft Entra para la autorización mediante colecciones de roles en IAS/BTP

Context

Si desea configurar la autorización para las aplicaciones de BTP, hay varias opciones:

  • Puede configurar un control de acceso específico dentro de la propia aplicación, en función del usuario que ha iniciado sesión.
  • Puede especificar el acceso a través de roles y colecciones de roles en BTP, en función de las asignaciones de usuarios o de grupos.

La implementación final puede usar una combinación de ambas estrategias. Sin embargo, en el caso de la asignación a través de colecciones de roles, se puede hacer usuario a usuario, o bien se pueden utilizar grupos del proveedor de identidades configurado.

¿Qué se recomienda?

Si desea usar Microsoft Entra ID como origen autoritativo para la autorización específica, es aconsejable usar grupos de Microsoft Entra y asignarlos a colecciones de roles en BTP. Conceder a los usuarios acceso a determinadas aplicaciones significa simplemente agregarlas a los grupos de Microsoft Entra pertinentes, no es preciso configurar nada en IAS/BTP.

Con esta configuración, se recomienda usar el identificador de grupo (id. de objeto) del grupo de Microsoft Entra ID como identificador único del grupo, no el nombre para mostrar ("sAMAccountName"). Esto significa que debe usar el identificador de grupo como aserción de "Grupos" en el token SAML emitido por Microsoft Entra ID. Además, el identificador de grupo se usa para la asignación a la colección de roles en BTP.

Uso de colecciones de roles en SAP

Motivos para esta recomendación

Si desea asignar usuarios directamente a colecciones de roles en BTP, no va a centralizar las decisiones de autorización en Microsoft Entra ID. También significa que el usuario ya debe existir en IAS para poder asignarse a una colección de roles en BTP (y dado que se recomienda la federación, en lugar del aprovisionamiento de usuarios, significa que es posible que la cuenta paralela del usuario no exista todavía en IAS en el momento en que quiera realizar la asignación de usuario). Con el uso de grupos de Microsoft Entra y su asignación a colecciones de roles desaparecen estos problemas.

Es posible que parezca que la asignación de grupos a colecciones de roles contradice la recomendación anterior de no usar Microsoft Entra ID para la autorización. Sin embargo, hasta en este caso la decisión de autorización todavía se toma en BTP, solo que ahora se basa en la pertenencia a grupos mantenida en Microsoft Entra ID.

Se recomienda usar el identificador de grupo del grupo de Microsoft Entra, en lugar de su nombre, porque el identificador de grupo es único globalmente, inmutable y nunca se puede reutilizar para otro grupo más adelante. Sin embargo, el uso del nombre del grupo podría provocar problemas si se cambia el nombre, y se puede eliminar un grupo y crear otro con el mismo nombre, pero con usuarios que no deberían tener acceso a la aplicación, lo que supone un riesgo para la seguridad.

Resumen de la implementación

En Microsoft Entra ID:

  • Cree grupos a los que se puedan agregar aquellos usuarios que necesiten acceder a las aplicaciones de BTP (por ejemplo, cree un grupo de Microsoft Entra para cada colección de roles de BTP).
  • En la aplicación empresarial de Microsoft Entra que representa la relación de federación con IAS, configure los atributos de usuario notificaciones de SAML para agregar una notificación de grupo para los grupos de seguridad:

    • Establezca el atributo Source (Origen) en "Id. de grupo" y Name (Nombre) en Groups (escrito exactamente así, con "G" mayúscula).

    • Además, para que el tamaño de las cargas útiles de las notificaciones no aumente y no llegar al límite que impone Microsoft Entra ID en el número de notificaciones de grupo (150) en las aserciones de SAML, se recomienda encarecidamente limitar los grupos que se devuelven en las notificaciones a solo los que se asignaron explícitamente:

      • En "¿Qué grupos asociados con el usuario se deben devolver en la notificación?" responda con "Grupos asignados a la aplicación". A continuación, para los grupos que desea incluir como notificaciones, asígnelos a la aplicación empresarial mediante la sección "Usuarios y grupos" y seleccionando "Agregar usuario/grupo".

      Configuración de notificaciones de grupo de Microsoft Entra

En IAS:

  • En la configuración del Proveedor de identidades corporativas, en las opciones de Federación de identidades, asegúrese de deshabilitar "Utilizar almacén de usuarios de Identity Authentication"; de lo contrario, la información de los grupos de Microsoft Entra ID no se conservaría en el token SAML hacia BTP y se produciría un error en la autorización.

Nota:

Si necesita usar el almacén de usuarios de Identity Authentication (por ejemplo, para incluir notificaciones que no se pueden obtener de Microsoft Entra ID pero que están disponibles en el almacén de usuarios de IAS), puede mantener habilitada esta configuración. Sin embargo, en ese caso necesitará configurar los atributos predeterminados enviados a la aplicación para incluir las notificaciones pertinentes que provienen de Microsoft Entra ID (por ejemplo, con el formato ${corporateIdP.Groups}).

En BTP:

  • En las colecciones de roles que usan las aplicaciones de esa subcuenta, asigne las colecciones de roles a grupos de usuarios, para lo que debe agregar una configuración para el proveedor de identidades de IAS y seleccionar en Nombre el identificador de grupo (id. de objeto) del grupo de Microsoft Entra.

Nota:

En caso de que tenga otra notificación en Microsoft Entra ID que contenga la información de autorización que se va a usar en BTP, no es necesario que use el nombre de la notificación Groups. Esto es lo que BTP usa cuando se asignan las colecciones de roles a grupos de usuarios como se hizo anteriormente, pero también puede asignar las colecciones de roles a los atributos de usuario, lo que brinda un poco más de flexibilidad.

4: Uso de una subcuenta de BTP individual solo para las aplicaciones que tienen requisitos de identidad similares

Contexto

En BTP, cada subcuenta puede contener varias aplicaciones. Sin embargo, desde el punto de vista de IAS, una "aplicación agrupada" es una subcuenta de BTP completa, no las aplicaciones más granulares que contiene. Esto significa que toda la configuración de confianza y la configuración de autenticación y acceso, así como las opciones de personalización de marca y diseño de IAS se aplican a todas las aplicaciones dentro de esa subcuenta. Del mismo modo, todas las configuraciones de confianza y colecciones de roles de BTP también se aplican a todas las aplicaciones de esa subcuenta.

¿Qué se recomienda?

Se recomienda combinar varias aplicaciones en una sola subcuenta de BTP solo si tienen requisitos similares en el nivel de identidad (usuarios, grupos, proveedores de identidades, roles, configuración de confianza, personalización de marca, etc.).

Motivos para esta recomendación

Al combinar varias aplicaciones que tienen requisitos de identidad muy diferentes en una sola subcuenta de BTP, podría acabar con una configuración que no sea segura o que sea más fácil que se configure incorrectamente. Por ejemplo: cuando se realiza un cambio de configuración en un recurso compartido como un proveedor de identidades para una sola aplicación de BTP, todas las aplicaciones que dependen de ese recurso compartido resultan afectadas.

Resumen de la implementación

Considere detenidamente cómo desea agrupar varias aplicaciones entre las subcuentas de BTP. Para más información, consulte la documentación del modelo de cuenta de SAP.

5: Uso del inquilino de IAS de producción para toda la autenticación y autorización del usuario final

Contexto

Cuando se trabaja con IAS, normalmente se tiene un inquilino de producción y otro de desarrollo/pruebas. En el caso de las diferentes subcuentas o aplicaciones de BTP, puede elegir qué proveedor de identidades (inquilino de IAS) desea usar.

¿Qué se recomienda?

Se recomienda usar siempre el inquilino de IAS de producción para cualquier interacción con los usuarios finales, incluso en el contexto de una versión de desarrollo/pruebas o un entorno de la aplicación en la que tienen que iniciar sesión.

Se recomienda usar otros inquilinos de IAS solo para probar la configuración relacionada con las identidades, que debe realizarse de forma aislada del inquilino de producción.

Motivos para esta recomendación

Dado que IAS es el componente centralizado que se ha configurado para realizar la federación con Microsoft Entra ID, hay un único lugar en el que debe configurarse y mantenerse la configuración de la federación y de las identidades. La duplicación en otros inquilinos de IAS puede provocar errores de configuración o incoherencias en el acceso de los usuarios finales entre entornos.

6: Definición de un proceso para la sustitución de certificados de firma de SAML

Context

Al configurar la federación entre Microsoft Entra ID e IAS, así como entre IAS y BTP, se intercambian los metadatos de SAML que contienen certificados X.509 usados para el cifrado y las firmas criptográficas de los tokens SAML que se envían entre ambas partes. Estos certificados tienen fechas de expiración y deben actualizarse periódicamente (por ejemplo, incluso en situaciones de emergencia en las que un certificado ha corrido peligro).

Nota: El período de validez predeterminado del certificado de Microsoft Entra inicial que se usa para firmar las aserciones de SAML es de 3 años (y tenga en cuenta que el certificado es específico de la aplicación empresarial, a diferencia de los tokens de OpenID Connect y OAuth 2.0 firmados por un certificado global en Microsoft Entra ID). Puede optar por generar un nuevo certificado con otra fecha de expiración o crear e importar su propio certificado.

Cuando los certificados expiran, no se pueden volver a usar y se deben configurar certificados nuevos. Por tanto, se debe establecer un proceso para mantener actualizada la configuración del certificado dentro del usuario de confianza (que necesita validar las firmas) con los certificados reales que se usan para firmar los tokens SAML.

En algunos casos, el usuario de confianza puede hacerlo automáticamente, ya que se proporciona un punto de conexión de metadatos que devuelve dinámicamente la información más reciente de los metadatos, es decir, normalmente una dirección URL a la que se puede acceder públicamente desde la que el usuario de confianza puede recuperar periódicamente los metadatos y actualizar su almacén de configuración interno.

Sin embargo, IAS solo permite que los proveedores de identidades corporativas se configuren mediante la importación del archivo XML de metadatos, no admite proporcionar un punto de conexión de metadatos para la recuperación dinámica de los metadatos de Microsoft Entra (por ejemplo, https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Del mismo modo, BTP no permite que se realice una nueva configuración de confianza desde el punto de conexión de metadatos de IAS (por ejemplo, https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), también necesita una carga única de un archivo XML de metadatos.

¿Qué se recomienda?

Al configurar la federación de identidades entre dos sistemas cualesquiera (por ejemplo, Microsoft Entra ID e IAS, así como IAS y BTP), asegúrese de capturar la fecha de expiración de los certificados que se usan. Asegúrese de que estos certificados se pueden reemplazar con antelación y de que hay un proceso documentado para actualizar los nuevos metadatos en todos los usuarios de confianza que dependen de los certificados.

Como se ha indicado antes, es aconsejable establecer una configuración de confianza en BTP hacia IAS, que a su vez se configura para federarse con Microsoft Entra ID como Proveedor de identidades corporativas. En ese caso, los siguientes certificados (que se usan para la firma y el cifrado de SAML) son importantes:

  • El certificado de subcuenta en BTP: cuando cambia, se debe actualizar la configuración de SAML 2.0 de la aplicación en IAS.
  • El certificado de inquilino en IAS: cuando esto cambia, se deben actualizar tanto la configuración de SAML 2.0 de la aplicación empresarial en Microsoft Entra ID como la configuración de confianza en BTP.
  • El certificado de la aplicación empresarial de Microsoft Entra ID: cuando esto cambia, se debe actualizar la configuración de SAML 2.0 del proveedor de identidades corporativo en IAS.

Reversión de los certificados de firma de SAML

SAP tiene implementaciones de ejemplo para las notificaciones de certificados de cliente con SAP Cloud Integration y gestión de vencimiento próximo. Esto se podría adaptar con Azure Integration Services o Power Automate. Sin embargo, tendrían que adaptarse para trabajar con certificados de servidor. Este enfoque requiere una implementación personalizada.

Motivos para esta recomendación

Si se permite que los certificados expiren o cuando se reemplazan a tiempo, pero los usuarios de confianza que dependen de ellos no se actualizan con la nueva información de los certificados, los usuarios no podrán volver a iniciar sesión en ninguna aplicación a través de la federación. Esto puede implicar un tiempo de inactividad significativo para todos los usuarios mientras se restaura el servicio mediante la reconfiguración de los metadatos.

Resumen de la implementación

Agregue una dirección de notificación por correo electrónico para la expiración del certificado en Microsoft Entra ID y establézcala en un buzón de grupo para que no se envíe a una sola persona (que incluso puede que ya no tenga una cuenta en el momento en que el certificado esté a punto de expirar). De forma predeterminada, el usuario que creó la aplicación empresarial será el único que va a recibir una notificación.

Considere la posibilidad de crear automatización para ejecutar todo el proceso de sustitución de certificados. Por ejemplo, se pueden comprobar periódicamente los certificados que expiran y reemplazarlos al actualizar todos los usuarios de confianza por los nuevos metadatos.

Uso de Azure AD B2C como el proveedor de identidades

Azure Active Directory B2C proporciona identidad de negocio a cliente como servicio. Como la integración con Azure AD B2C es similar a cómo permitiría que los usuarios empresariales inicien sesión con Microsoft Entra ID, las recomendaciones anteriores se siguen aplicando principalmente cuando se quiere usar Azure AD B2C para los clientes, consumidores o ciudadanos y permitir que usen las identidades de cuentas locales, empresariales o sociales que prefieran.

Sin embargo, hay algunas diferencias importantes. La configuración de Azure AD B2C como proveedor de identidades corporativas en IAS y la configuración de la federación entre ambos inquilinos se describe con mayor detalle en esta entrada del blog.

Registro de una aplicación SAML en Azure AD B2C

Azure AD B2C no tiene una galería de aplicaciones empresariales que puede usar a fin de configurar fácilmente la relación de confianza hacia el proveedor de identidades corporativas en IAS. En su lugar, deberá usar directivas personalizadas para registrar una aplicación SAML en Azure AD B2C. Sin embargo, esta aplicación SAML desempeña el mismo rol lógico que la aplicación empresarial en Microsoft Entra ID, por lo que, por ejemplo, se aplica la misma guía respecto de la sustitución de certificados SAML.

Autorización con Azure AD B2C

Azure AD B2C no admite de manera nativa el uso de grupos para crear colecciones de usuarios a los que puede asignar acceso, lo que significa que la guía para usar grupos de Microsoft Entra para la autorización a través de las colecciones de roles en BTP se debe implementar de otra manera.

Afortunadamente, Azure AD B2C es muy personalizable, por lo que puede configurar los tokens SAML que envía a IAS a fin de incluir cualquier tipo de información personalizada. Para ver las diversas opciones de cómo admitir las notificaciones de autorización, consulte la documentación que acompaña al ejemplo de roles de aplicación de Azure AD B2C; pero, en resumen, a través de su mecanismo de extensibilidad del conector de API, también puede usar grupos, roles de aplicaciones o, incluso, una base de datos personalizada a fin de determinar a qué puede acceder el usuario.

Independientemente del origen de la información de autorización, también se puede emitir como el atributo Groups dentro del token SAML mediante la configuración de ese nombre de atributo como el tipo de notificación del asociado predeterminado en el esquema de notificaciones o mediante el reemplazo del tipo de notificación del asociado en las notificaciones de salida. Sin embargo, tenga en cuenta que BTP le permite asignar colecciones de roles a los atributos de usuario, lo que significa que se puede usar cualquier nombre de atributo para las decisiones de autorización, incluso si no usa el nombre de atributo Groups.

Pasos siguientes