Scénario – Utilisation de Microsoft Entra ID pour sécuriser l’accès aux plateformes et applications SAP

Ce document fournit des conseils sur la conception technique et la configuration des plateformes et applications SAP lors de l’utilisation de Microsoft Entra ID comme principal service d’authentification des utilisateurs. En savoir plus sur la configuration initiale dans ce tutoriel.

Terminologie utilisée dans ce guide

Abréviation	Description
BTP	SAP Business Technology Platform. L’ensemble de l’offre des technologies SAP. La plupart des technologies SAP présentées ici font partie de BTP. Les produits officiellement connus sous le nom de SAP Cloud Platform font partie de SAP BTP.
IAS	SAP Cloud Identity Services - Service d’authentification des identités. Service de fournisseur d’identité cloud multilocataire fourni par SAP. IAS aide les utilisateurs à s’authentifier auprès de leurs propres instances de service SAP.
IDS	SAP ID Service. Instance d’IAS utilisée par SAP pour authentifier les clients et les partenaires auprès des services PaaS et SaaS gérés par SAP.
IPS	SAP Cloud Identity Services - Service de provisionnement des identités. IPS permet de synchroniser les identités entre les différents magasins/systèmes cibles.
XSUAA	Extended Services for Cloud Foundry User Account and Authentication. XSUAA est un serveur d’autorisation OAuth multilocataire au sein de SAP BTP.
CF	Cloud Foundry. Cloud Foundry est l’environnement sur lequel SAP a conçu son offre multicloud pour BTP (AWS, Azure, GCP, Alibaba).
Fiori	L’expérience utilisateur web de SAP (par opposition à l’expérience de bureau).

Vue d’ensemble

La pile des technologies SAP et Microsoft inclut de nombreux services et composants qui jouent un rôle dans les scénarios d’authentification et d’autorisation des utilisateurs. Les principaux services sont répertoriés dans le diagramme ci-dessous.

Comme il existe de nombreuses permutations de scénarios possibles à configurer, nous nous concentrons sur un scénario adapté à une stratégie d’identité Microsoft Entra. Nous formulerons les hypothèses suivantes :

• Vous souhaitez gérer toutes vos identités de manière centralisée et seulement à partir de Microsoft Entra ID.
• Vous souhaitez réduire autant que possible les efforts de maintenance et automatiser l’authentification et l’accès aux applications sur Microsoft et SAP.
• L’aide d’ordre général pour Microsoft Entra ID avec IAS s’applique aux applications déployées sur BTP et aux applications SAP SaaS configurées dans IAS. Des recommandations spécifiques seront également fournies si elles s’appliquent à BTP (par exemple, l’utilisation des mappages de rôles avec des groupes Microsoft Entra) et aux applications SAP SaaS (par exemple, l’utilisation du service d’approvisionnement d’identités pour l’autorisation basée sur les rôles).
• Nous supposons également que les utilisateurs sont déjà attribués dans Microsoft Entra ID et dans tous les systèmes SAP dont le fonctionnement requiert l’attribution d’utilisateurs. Quelle que soit la méthode utilisée, l’attribution a pu se faire manuellement, localement à partir d’Active Directory via Microsoft Entra Connect, ou par le biais de systèmes RH comme SAP SuccessFactors. Dans ce document, SuccessFactors est donc considéré comme une simple application à laquelle les utilisateurs (existants) se connecteront. Nous ne couvrons pas l’attribution réelle des utilisateurs de SuccessFactors vers Microsoft Entra ID.

Sur la base de ces hypothèses, nous nous concentrons principalement sur les produits et services présentés dans le diagramme ci-dessous. Ce sont les différents composants les plus pertinents pour l'authentification et l'autorisation dans un environnement cloud.

Remarque

La plupart des conseils ici s'appliquent également à Azure Active Directory B2C, mais il existe quelques différences importantes. Consultez Utilisation d'Azure AD B2C comme fournisseur d'identité pour plus d'informations.

Avertissement

Tenez compte des limites d’assertion SAP SAML et de l’impact de la longueur des noms de collection de rôles SAP Cloud Foundry et du nombre de collections proxysées par des groupes dans SAP Cloud Identity Service. Si vous souhaitez obtenir plus d’informations, consultez la note SAP 2732890. Des limites dépassées entraînent des problèmes d’autorisation.

Recommandations

Résumé

• 1 - Utiliser l’authentification fédérée dans la plateforme SAP Business Technology et les applications SaaS SAP par le biais du service SAP Identity Authentication
• 2 – Utiliser Microsoft Entra ID pour l’authentification et IAS/BTP pour l’autorisation
• 3 – Utiliser des groupes Microsoft Entra pour l’autorisation par le biais de regroupements de rôles dans IAS/BTP
• 4 - Utiliser un seul sous-compte BTP pour les applications qui ont des exigences d’identité similaires
• 5 - Utiliser le locataire IAS de production pour l’ensemble de l’authentification et de l’autorisation de l’utilisateur final
• 6 - Définir un processus pour la substitution des certificats de signature SAML

1 - Utiliser l’authentification fédérée dans la plateforme SAP Business Technology et les applications SaaS SAP par le biais du service SAP Identity Authentication

Context

Vos applications dans BTP peuvent utiliser des fournisseurs d’identité via des configurations d’approbation pour authentifier les utilisateurs à l’aide du protocole SAML 2.0 entre BTP/XSUAA et le fournisseur d’identité. Notez que seul SAML 2.0 est pris en charge, même si le protocole OpenID Connect est utilisé entre l'application elle-même et BTP/XSUAA (non pertinent dans ce contexte).

Dans BTP, vous pouvez choisir de configurer une configuration de confiance pour SAP ID Service (qui est la valeur par défaut), mais quand votre annuaire d’utilisateurs faisant autorité est Microsoft Entra ID, vous pouvez configurer la fédération afin que les utilisateurs puissent se connecter avec leurs comptes Microsoft Entra existants.

En plus de la fédération, vous pouvez également configurer l’attribution d’utilisateurs afin que les utilisateurs Microsoft Entra soient attribués au préalable dans BTP. Toutefois, il n’existe pas de prise en charge native pour cela (uniquement pour Microsoft Entra ID -> service SAP Identity Authentication) ; le service d’approvisionnement d’identités BTP constitue une solution intégrée avec prise en charge native. Un provisionnement initial des comptes d’utilisateurs peut être utile à des fins d’autorisation (par exemple, pour ajouter des utilisateurs à des rôles). Cependant, selon les besoins, vous pouvez également atteindre cet objectif avec des groupes Microsoft Entra (voir ci-dessous), ce qui pourrait signifier qu’aucune attribution d’utilisateurs n’est nécessaire.

La configuration de la relation de fédération offre plusieurs options :

• Vous pouvez choisir de fédérer vers Microsoft Entra ID directement à partir de BTP/XSUAA.
• Vous pouvez choisir de fédérer avec IAS qui, à son tour, est configuré pour fédérer avec Microsoft Entra ID en tant que fournisseur d’identité d’entreprise (également appelé « proxy SAML »).

Pour les applications SaaS SAP, IAS est provisionné et préconfiguré pour une intégration facile des utilisateurs finaux. (Les exemples incluent SuccessFactors, Marketing Cloud, Cloud4Customer, Sales Cloud, entre autres). Ce scénario est moins complexe, car l'IAS est directement connecté à l'application cible et n'est pas transmis par proxy à XSUAA. Dans tous les cas, les mêmes règles s’appliquent pour cette configuration que pour Microsoft Entra ID avec IAS en général.

Que recommandons-nous ?

Quand votre annuaire d’utilisateurs faisant autorité est Microsoft Entra ID, nous recommandons de mettre en place une configuration de confiance dans BTP vers IAS. À son tour, IAS est configuré pour fédérer avec Microsoft Entra ID en tant que fournisseur d’identité d’entreprise.

Pour la configuration de confiance dans BTP, nous recommandons d’activer l’option « Créer des utilisateurs cachés lors de l’ouverture de session ». De cette façon, les utilisateurs qui n’ont pas encore été créés dans BTP obtiennent automatiquement un compte lorsqu’ils se connectent pour la première fois via IAS/Microsoft Entra ID. Si ce paramètre est désactivé, seuls les utilisateurs préprovisionnés seront autorisés à se connecter.

Pourquoi cette recommandation ?

Lorsque vous utilisez la fédération, vous pouvez choisir de définir la configuration de confiance au niveau du sous-compte BTP. Dans ce cas, vous devez répéter la configuration pour chaque autre sous-compte que vous utilisez. En utilisant IAS comme configuration de confiance intermédiaire, vous bénéficiez d’une configuration centralisée sur plusieurs sous-comptes et vous pouvez utiliser des fonctionnalités IAS, telles que l’authentification basée sur les risques et l'enrichissement centralisé des attributs d’assertion. Pour préserver l'expérience de l'utilisateur, ces fonctionnalités de sécurité avancées ne doivent être appliquées qu'à un seul emplacement. Il peut s’agir d’un service IAS ou d’une instance Microsoft Entra ID en tant que magasin d’utilisateurs faisant autorité unique (comme c’est le principe de ce document), qui est géré de manière centralisée par la gestion de l’accès conditionnel de Microsoft Entra.

Remarque : pour IAS, chaque sous-compte est considéré comme une « application », même si une ou plusieurs applications peuvent être déployées dans ce sous-compte. Dans IAS, chaque application de ce type peut être configurée pour la fédération avec le même fournisseur d’identité d’entreprise (Microsoft Entra ID dans ce cas).

Résumé de l'implémentation

Dans Microsoft Entra ID :

• Configurez éventuellement Microsoft Entra ID pour l’authentification unique transparente (Seamless SSO), qui connecte automatiquement les utilisateurs quand leurs appareils d’entreprise sont connectés au réseau de l’entreprise. Quand cette fonctionnalité est activée, les utilisateurs n’ont plus besoin de taper leur mot de passe pour se connecter à Microsoft Entra ID ni même, dans la plupart des cas, leur nom d’utilisateur.

Dans Microsoft Entra ID et IAS :

• Consultez la documentation pour connecter Microsoft Entra ID au service IAS en mode de fédération (proxy) (documentation SAP, documentation Microsoft). Faites attention au paramètre NameID de votre configuration SSO dans Microsoft Entra ID, car les UPN ne sont pas nécessairement des adresses e-mail.
• Configurez « l’application groupée » pour qu’elle utilise Microsoft Entra ID en accédant à la page « Authentification conditionnelle » et en définissant le « fournisseur d’identité authentifiant par défaut » sur le fournisseur d’identité d’entreprise représentant votre annuaire Microsoft Entra.

Dans BTP :

• Mettez en place une configuration de confiance vers IAS (doc SAP) et assurez-vous que les options « Disponible pour l’ouverture de session utilisateur » et « Créer des utilisateurs cachés lors de l’ouverture de session » sont toutes les deux activées.
• Désactivez éventuellement l’option « Disponible pour l’ouverture de session utilisateur » sur la configuration de confiance par défaut « SAP ID Service » afin que les utilisateurs s’authentifient toujours via Microsoft Entra ID sans passer par un écran leur demandant de choisir leur fournisseur d’identité.

2 – Utiliser Microsoft Entra ID pour l’authentification et IAS/BTP pour l’autorisation

Context

Quand les paramètres BTP et IAS ont été configurés pour l’authentification des utilisateurs par le biais de la fédération pour Microsoft Entra ID, il existe plusieurs options pour configurer l’autorisation :

• Dans Microsoft Entra ID, vous pouvez attribuer des utilisateurs et des groupes Microsoft Entra à l’application d’entreprise représentant votre instance SAP IAS dans Microsoft Entra ID.
• Dans IAS, vous pouvez utiliser l’authentification basée sur le risque pour autoriser ou bloquer les ouvertures de session et empêcher ainsi l’accès à l'application dans BTP.
• Dans BTP, vous pouvez utiliser les collections de rôles pour définir les utilisateurs et les groupes qui peuvent accéder à l'application et obtenir certains rôles.

Que recommandons-nous ?

Nous vous recommandons de ne pas placer d’autorisation directement dans Microsoft Entra et de désactiver explicitement le paramètre « Affectation de l’utilisateur obligatoire » dans l’application d’entreprise dans Microsoft Entra ID. Notez que pour les applications SAML, ce paramètre est activé par défaut, et vous devez donc prendre des mesures explicites pour le désactiver.

Pourquoi cette recommandation ?

Quand l’application est fédérée par le biais d’IAS, du point de vue de Microsoft Entra ID, l’utilisateur « s’authentifie sur IAS » lors du processus de connexion. Cela signifie que Microsoft Entra ID ne dispose d’aucune information sur l’application BTP finale à laquelle l’utilisateur tente de se connecter. Cela implique également que l’autorisation dans Microsoft Entra ID ne peut être utilisée que pour effectuer des autorisations très sommaires, par exemple pour permettre à l’utilisateur de se connecter à n’importe quelle application dans BTP, ou à aucune. Cela souligne également la stratégie SAP d'isolement des applications et les mécanismes d'authentification au niveau des sous-comptes BTP.

Même s’il s’agit d’une raison valable pour utiliser le paramètre « Affectation de l’utilisateur obligatoire », cela signifie qu’il existe peut-être maintenant deux emplacements différents où les informations d’autorisation doivent être conservées : dans Microsoft Entra ID dans l’application d’entreprise (s’applique à toutes les applications BTP), ainsi que dans chaque sous-compte BTP. Cela peut entraîner une certaine confusion et générer des erreurs de configuration lorsque les paramètres d'autorisation sont mis à jour dans un emplacement, mais pas dans l’autre. Par exemple : un utilisateur a été autorisé dans BTP mais n’a pas été attribué à l’application dans Microsoft Entra ID, ce qui a entraîné un échec d’authentification.

Résumé de l'implémentation

Dans l’application d’entreprise Microsoft Entra représentant la relation de fédération avec IAS, désactivez le paramètre « Affectation de l’utilisateur obligatoire ». Cela signifie également que vous pouvez ignorer l’affectation d’utilisateurs.

3 – Utiliser des groupes Microsoft Entra pour l’autorisation par le biais de regroupements de rôles dans IAS/BTP

Context

Lorsque vous souhaitez configurer l'autorisation pour vos applications BTP, vous disposez de plusieurs options :

• Vous pouvez configurer un contrôle d'accès affiné dans l'application elle-même, en fonction de l'utilisateur connecté.
• Vous pouvez spécifier l'accès par le biais de rôles et de collections de rôles dans BTP, en fonction d’affectations d'utilisateurs ou d’affectations de groupes.

L'implémentation finale peut utiliser une combinaison de ces deux stratégies. Mais pour l'affectation par le biais de collections de rôles, vous pouvez effectuer cette opération utilisateur par utilisateur, ou utiliser des groupes du fournisseur d'identité configuré.

Que recommandons-nous ?

Si vous souhaitez utiliser Microsoft Entra ID comme source faisant autorité pour une autorisation affinée, nous vous recommandons d’utiliser des groupes Microsoft Entra et de les attribuer à des collections de rôles dans BTP. Pour accorder aux utilisateurs l’accès à certaines applications, il suffit alors de les ajouter au(x) groupe(s) Microsoft Entra correspondant(s), sans qu’aucune autre configuration ne soit nécessaire dans IAS/BTP.

Avec cette configuration, nous recommandons d’utiliser l’ID de groupe (ID de l’objet) du groupe Microsoft Entra comme identificateur unique du groupe, et non le nom d’affichage (« sAMAccountName »). Cela signifie que vous devez utiliser l’ID de groupe comme assertion « Groupes » dans le jeton SAML émis par Microsoft Entra ID. En outre, l'ID du groupe est utilisé pour l'affectation à la collection de rôles dans BTP.

Pourquoi cette recommandation ?

Si vous attribuez des utilisateurs directement aux collections de rôles dans BTP, vous ne centralisez pas les décisions d’autorisation dans Microsoft Entra ID. Cela signifie également que l'utilisateur doit déjà exister dans IAS avant de pouvoir être affecté à une collection de rôles dans BTP. Et étant donné que nous recommandons la fédération plutôt que le provisionnement des utilisateurs, cela signifie que le compte fictif de l’utilisateur n’existe peut-être pas dans IAS au moment où vous voulez effectuer l’affectation de l’utilisateur. L’utilisation de groupes Microsoft Entra et leur attribution à des collections de rôles corrigent ces problèmes.

L’attribution de groupes aux collections de rôles peut sembler contredire la recommandation précédente de ne pas utiliser Microsoft Entra ID pour l’autorisation. Mais même dans ce cas, la décision d’autorisation est toujours prise dans BTP. Elle est désormais simplement basée sur l’appartenance à un groupe gérée dans Microsoft Entra ID.

Nous recommandons d’utiliser l’ID de groupe du groupe Microsoft Entra ID plutôt que son nom, car l’ID de groupe est unique, immuable et ne peut jamais être réutilisé pour un autre groupe par la suite, tandis que l’utilisation du nom de groupe peut entraîner des problèmes en cas de changement de nom. Il existe par ailleurs un risque de sécurité quand un groupe est supprimé et qu’un autre est créé avec le même nom, mais avec des utilisateurs qui ne devraient pas avoir accès à l’application.

Résumé de l'implémentation

Dans Microsoft Entra ID :

• Créez des groupes auxquels peuvent être ajoutés les utilisateurs qui ont besoin d’accéder aux applications dans BTP (par exemple, créez un groupe Microsoft Entra pour chaque collection de rôles dans BTP).
• Dans l’application d’entreprise Microsoft Entra représentant la relation de fédération avec IAS, configurez les attributs et revendications d’utilisateur SAML pour ajouter une revendication de groupe aux groupes de sécurité :

  • Définissez l’attribut Source sur « ID de groupe » et le nom sur Groups (orthographié exactement ainsi, avec un « G » majuscule).

  • De plus, pour limiter les charges utiles des revendications et éviter de se heurter au fait que Microsoft Entra ID limite le nombre de revendications de groupe à 150 dans les assertions SAML, nous recommandons vivement de limiter les groupes renvoyés dans les revendications aux seuls groupes qui ont été explicitement attribués :

    • Sous « Quels groupes associés à l’utilisateur doivent être retournés dans la revendication ? », répondez par « Groupes attribués à l’application ». Ensuite, pour les groupes que vous voulez inclure comme revendications, affectez-les à l'application d'entreprise en utilisant la section « Utilisateurs et groupes » et en sélectionnant « Ajouter un utilisateur/groupe» .

    

Dans IAS :

• Dans la configuration du fournisseur d’identité d’entreprise, sous les options de la fédération d’identité, veillez à désactiver l’option « Utiliser le magasin d’utilisateurs Identity Authentication », sinon les informations de groupe provenant de Microsoft Entra ID ne seront pas conservées dans le jeton SAML vers BTP et l’autorisation échouera.

Remarque

Si vous devez utiliser le magasin d’utilisateurs Identity Authentication (par exemple, pour inclure des revendications qui ne peuvent pas provenir de sources Microsoft Entra ID mais qui sont disponibles dans le magasin d’utilisateurs IAS), vous pouvez laisser ce paramètre activé. Cependant, dans ce cas, vous devez configurer les attributs par défaut envoyés à l’application pour inclure les revendications pertinentes provenant de Microsoft Entra ID (par exemple avec le format ${corporateIdP.Groups}).

Dans BTP :

• Sur les collections de rôles utilisées par les applications de ce sous-compte, mappez les collections de rôles aux groupes d’utilisateurs en ajoutant une configuration pour le fournisseur d’identité IAS, puis en définissant le nom sur l’ID de groupe (ID de l’objet) du groupe Microsoft Entra.

Remarque

Au cas où vous auriez une autre revendication dans Microsoft Entra ID pour contenir les informations d’autorisation à utiliser dans BTP, vous n’avez pas besoin d’utiliser le nom de la revendication Groups. C’est ce que BTP utilise lorsque vous mappez les collections de rôles à des groupes d’utilisateurs comme indiqué ci-dessus, mais vous pouvez également mapper les collections de rôles aux attributs utilisateur, ce qui vous offre un peu plus de flexibilité.

4 - Utiliser un seul sous-compte BTP pour les applications qui ont des exigences d’identité similaires

Context

Dans BTP, chaque sous-compte peut contenir plusieurs applications. Cependant, du point de vue d’IAS, une « application regroupée » représente un sous-compte BTP complet, et non les applications plus granulaires qui le composent. Cela signifie que tous les paramètres de confiance, l'authentification et la configuration de l’accès, ainsi que les options de personnalisation et de disposition d'IAS s’appliquent à toutes les applications de ce sous-compte. De même, toutes les configurations de confiance et les collections de rôles dans BTP s'appliquent également à toutes les applications de ce sous-compte.

Que recommandons-nous ?

Nous vous recommandons de combiner plusieurs applications dans un seul sous-compte BTP uniquement si elles ont des exigences similaires au niveau de l'identité (utilisateurs, groupes, fournisseurs d'identité, rôles, configuration de confiance, personnalisation, etc.).

Pourquoi cette recommandation ?

En combinant plusieurs applications ayant des exigences très différentes en matière d'identité dans un seul sous-compte du BTP, vous risquez de vous retrouver avec une configuration non sécurisée ou pouvant être plus facilement mal configurée. Par exemple, lorsqu’un changement de configuration d’une ressource partagée, par exemple un fournisseur d'identité, est effectué pour une seule application dans BTP, ce changement affecte toutes les applications qui dépendent de cette ressource partagée.

Résumé de l'implémentation

Réfléchissez bien à la manière dont vous souhaitez regrouper plusieurs applications dans différents sous-comptes de BTP. Pour plus d’informations, consultez la documentation sur le modèle de compte SAP.

5 - Utiliser le locataire IAS de production pour l’ensemble de l’authentification et de l’autorisation de l’utilisateur final

Context

Lorsque vous utilisez IAS, vous avez généralement un locataire de production et un locataire de développement/test. Pour différents sous-comptes ou applications dans BTP, vous pouvez choisir le fournisseur d'identité (locataire IAS) à utiliser.

Que recommandons-nous ?

Nous recommandons de toujours utiliser le locataire IAS de production pour toute interaction avec les utilisateurs finaux, même dans le contexte d'une version ou d'un environnement de développement/test de l'application à laquelle ils doivent se connecter.

Nous recommandons d’utiliser d’autres locataires IAS uniquement pour tester la configuration liée à l'identité, ce qui doit être réalisé de manière isolée du locataire de production.

Pourquoi cette recommandation ?

Comme IAS est le composant centralisé qui a été configuré pour se fédérer avec Microsoft Entra ID, il n’existe qu’un seul endroit où la configuration de la fédération et des identités doit être configurée et gérée. La duplication de ce système dans d'autres locataires IAS peut entraîner des erreurs de configuration ou des incohérences entre les environnements au niveau de l'accès des utilisateurs finaux.

6 - Définir un processus pour la substitution des certificats de signature SAML

Context

Lors de la configuration de la fédération entre Microsoft Entra ID et IAS, ainsi qu’entre IAS et BTP, des métadonnées SAML sont échangées. Elles contiennent des certificats X.509 utilisés pour le chiffrement et les signatures de chiffrement des jetons SAML envoyés entre les deux parties. Ces certificats contiennent des dates d'expiration et doivent être régulièrement mis à jour (même dans les situations d'urgence où un certificat a été compromis par exemple).

Remarque : la période de validité par défaut du certificat Microsoft Entra initial utilisé pour signer les assertions SAML est de 3 ans (notez que le certificat est spécifique à l’application d’entreprise, contrairement aux jetons OpenID Connect et OAuth 2.0 qui sont signés par un certificat global dans Microsoft Entra ID). Vous pouvez choisir de générer un nouveau certificat avec une date d'expiration différente, ou créer et importer votre propre certificat.

Lorsque les certificats expirent, ils ne peuvent plus être utilisés, et de nouveaux certificats doivent être configurés. Par conséquent, un processus doit être mis en place pour maintenir à jour la configuration des certificats au sein de la partie de confiance (qui doit valider les signatures) avec les certificats réels utilisés pour signer les jetons SAML.

Dans certains cas, la partie de confiance peut le faire automatiquement en lui fournissant un point de terminaison de métadonnées qui renvoie les dernières informations de métadonnées de manière dynamique, c'est-à-dire généralement une URL accessible au public à partir de laquelle la partie de confiance peut récupérer régulièrement les métadonnées et mettre à jour son magasin de configuration interne.

Toutefois, IAS ne permet de configurer les fournisseurs d’identité d’entreprise que par le biais d’une importation du fichier XML de métadonnées. Il ne fournit aucun point de terminaison de métadonnées pour la récupération dynamique des métadonnées Microsoft Entra (par exemple, https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). De même, BTP ne permet pas de configurer une nouvelle configuration de confiance à partir du point de terminaison des métadonnées IAS (par exemple https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), il nécessite également un chargement unique d'un fichier XML de métadonnées.

Que recommandons-nous ?

Lors de la configuration de la fédération d’identité entre deux systèmes (par exemple, Microsoft Entra ID et IAS, ainsi qu’entre IAS et BTP), veillez à noter la date d’expiration des certificats utilisés. Assurez-vous que ces certificats peuvent être remplacés bien à l'avance et qu'il existe un processus documenté pour mettre à jour les nouvelles métadonnées dans toutes les parties de confiance qui dépendent de ces certificats.

Comme nous l’avons vu précédemment, nous recommandons de mettre en place une configuration de confiance dans BTP vers IAS, qui à son tour est configuré pour se fédérer avec Microsoft Entra ID en tant que fournisseur d’identité d’entreprise. Dans ce cas, les certificats suivants (utilisés pour la signature et le chiffrement de SAML) sont importants :

• Le certificat du sous-compte dans BTP : lorsque celui-ci change, la configuration SAML 2.0 de l'application dans IAS doit être mise à jour.
• Le certificat du locataire dans IAS : quand celui-ci change, la configuration SAML 2.0 de l’application d’entreprise dans Microsoft Entra ID et la configuration de confiance dans BTP doivent être mises à jour.
• Le certificat de l’application d’entreprise dans Microsoft Entra ID : quand celui-ci change, la configuration SAML 2.0 du fournisseur d’identité d’entreprise dans IAS doit être mise à jour.

SAP propose des exemples d'implémentations pour les notifications de certificats clients avec SAP Cloud Integration et la gestion de la quasi-expiration. Cette approche pourrait être adaptée avec Azure Integration Services ou PowerAutomate. Mais il faudrait adapter ces éléments pour qu’ils fonctionnent avec des certificats de serveur. Une telle approche nécessite une implémentation personnalisée.

Pourquoi cette recommandation ?

Si on laisse les certificats expirer, ou s’ils sont remplacés à temps, mais que les parties de confiance qui en dépendent ne sont pas mises à jour avec les nouvelles informations du certificat, les utilisateurs ne pourront plus se connecter à aucune application par le biais de la fédération. Cela peut signifier un temps d’arrêt important pour tous les utilisateurs pendant que vous restaurez le service en reconfigurant les métadonnées.

Résumé de l'implémentation

Ajoutez une adresse de notification par e-mail pour l’expiration du certificat dans Microsoft Entra ID et définissez-la sur une boîte aux lettres de groupe afin que la notification ne soit pas envoyée à une seule personne (qui ne possède peut-être plus de compte au moment où le certificat va expirer). Par défaut, seul l’utilisateur qui a créé l’application d'entreprise recevra une notification.

Vous pouvez mettre en place une automatisation pour exécuter l'ensemble du processus de renouvellement des certificats. Par exemple, il est possible de consulter régulièrement les certificats qui expirent et les remplacer tout en mettant à jour toutes les parties de confiance avec les nouvelles métadonnées.

Configurer Azure AD B2C en tant que fournisseur d’identité

Azure Active Directory B2C fournit une identité entreprise- client en tant que service. Étant donné que l’intégration à Azure AD B2C est similaire à la façon dont vous autorisez les utilisateurs d’entreprise à se connecter avec Microsoft Entra ID, les recommandations ci-dessus s’appliquent généralement toujours quand vous souhaitez utiliser Azure AD B2C pour vos clients, vos consommateurs ou vos citoyens et leur permettre d’utiliser leurs identités de compte social, d’entreprise ou local préférées.

Bien qu’il y ait quelques différences de taille : La configuration d’Azure AD B2C en tant que fournisseur d’identité d’entreprise dans IAS et la configuration de la fédération entre les deux locataires sont décrites plus en détail dans ce billet de blog.

Inscrire une application SAML dans Azure AD B2C

Azure AD B2C ne dispose pas d’une galerie d’applications d’entreprise que vous pouvez utiliser pour configurer facilement la relation d’approbation vers le fournisseur d’identité d’entreprise dans IAS. Au lieu de cela, vous devrez utiliser des stratégies personnalisées pour enregistrer une application SAML dans Azure AD B2C. Toutefois, cette application SAML joue le même rôle logique que l’application d’entreprise dans Microsoft Entra ID, donc les mêmes instructions relatives à la substitution des certificats SAML s’appliquent, par exemple.

Autorisation avec Azure AD B2C

Azure AD B2C ne prend pas en charge en mode natif l’utilisation de groupes pour créer des regroupements d’utilisateurs auxquels vous pouvez affecter l’accès, ce qui signifie que l’aide relative à l’utilisation des groupes Microsoft Entra pour l’autorisation via les collections de rôles dans BTP doit être implémentée différemment.

Heureusement, Azure AD B2C est hautement personnalisable. vous pouvez donc configurer les jetons SAML qu’il envoie à IAS pour inclure des informations personnalisées. Pour connaître les différentes options de prise en charge des revendications d’autorisation, consultez la documentation accompagnant l'exemple de rôles d’application Azure AD B2C, mais en résumé : grâce à son mécanisme d’extensibilité de connecteur d’API, vous pouvez éventuellement utiliser des groupes, des rôles d’application ou même une base de données personnalisée pour déterminer à qui l’utilisateur est autorisé à accéder.

Indépendamment de l’origine des informations d’autorisation, il peut être émis comme l’attribut Groups dans le jeton SAML en configurant ce nom d’attribut en tant que type de revendication partenaire par défaut sur le schéma de revendication ou en remplaçant le type de revendication partenaire sur les revendications de sortie. Notez cependant que BTP vous permet de mapper des collections de rôles sur des attributs utilisateur, ce qui signifie que n'importe quel nom d'attribut peut être utilisé pour les décisions d'autorisation, même si vous n'utilisez pas le nom d'attribut Groups.

Étapes suivantes

• En savoir plus sur la configuration initiale dans ce tutoriel
• Découvrir d’autres scénarios d’intégration SAP avec Microsoft Entra ID et au-delà