Avertissement : Vous trouverez la version la plus récente de ce guide technique dans le Wiki de Shibboleth. Sa version française sera actualisée à intervalles réguliers.

Table des matières

Aperçu
Procuration de l’IdP : aspect et perspectives
Procuration de l’IdP : à quoi ressemble le flux de proxys?
Mettre la solution en place
1^re étape. Établir un lien de confiance entre l’IdP d’Azure AD et l’IdP Shibboleth
2^e étape. Configurer l’IdP pour qu’il se comporte comme un IdP de procuration
Essai
Documentation / Lectures recommandées

Aperçu

La configuration de l’IdP Shibboleth proposée ici tire parti des possibilités de procuration de la norme SAML pour établir la connexion avec Azure AD tout en laissant Shibboleth prendre en charge les fonctionnalités recherchées par de nombreux modèles de confiance de la fédération R‑E. Grâce à cette approche, l’IdP ne sert que de proxy SAML sans qu’on doive y ajouter d’autres éléments.

Nous examinerons deux approches en matière de procuration :

une procuration passe-système complète dont le jeu d’attributs se borne aux attributs d’Azure AD;
une procuration hybride supposant l’usage des attributs d’Azure AD et d’autres attributs du protocole LDAP, y compris ceux de l’Active Directory local.

Les étapes décrites dans ce document peuvent s’appliquer à l’installation de n’importe quel IdP. Elles présument toutefois que la version 4.0.1 de la plateforme IdP est en place. Lors des essais de configuration, on s’est servi du conteneur Internet2 Trusted Access Platform de l’IdP, qui a pris en charge certaines tâches parmi les plus laborieuses (par exemple, le serveur Web, la version de Java et l’externalisation de la configuration).

Public visé

La configuration suppose une certaine connaissance de l’IdP Shibboleth et de son architecture, ainsi que de la façon d’installer et de maintenir des logiciels. Les étapes décrites sont valables pour n’importe quel type de plateforme et devraient fonctionner avec les versions Windows et Unix de l’IdP.

Où procéder à l’installation

La configuration peut s’appliquer à un IdP local ou en nuage. L’emplacement de l’IdP peut dépendre de l’endroit où se trouvent les données. À moins que vous ne gardiez toutes vos données dans Azure AD, sans doute opterez-vous pour l’approche hybride qui combine les attributs d’Azure AD et ceux habituellement résolus par l’IdP Shibboleth.

Remarque : Cette nouvelle fonctionnalité de procuration SAML dérive de l’adoption de plus en plus grande de services en nuage qui ne satisfont pas naturellement à tous les besoins du milieu R‑E. L’idée est de parvenir à un équilibre entre la solution que propose le fournisseur et les exigences du milieu R-E concernant l’interopérabilité entre ses membres.

Remerciements : Nous remercions Matthew Slowe, l’équipe de Shibboleth et d’autres pour leurs conseils avisés et leur participation à la rédaction de ce document.

Procuration de l’IdP : aspect et perspectives

Il arrive que les techniques de procuration sèment la confusion. C’est pourquoi il vaut la peine de prendre un moment pour bien saisir l’approche et la remettre en perspective:

Azure AD

Pour Azure AD, l’IdP Shibboleth V4 ressemble à une « partie de confiance ».
En d’autres termes, il aura l’aspect d’une application unique ne figurant pas dans la galerie du portail Enterprise Apps.
- L’accès conditionnel et les règles s’appliquent donc à tout l’IdP, PAS à chaque partie de confiance de Shibboleth.
- Ceci signifie également que les règles de l’authentification multifacteur (MFA) que contrôle Azure AD sont valables pour l’IdP au complet, PLUTÔT que pour telle ou telle partie de confiance de Shibboleth.

Partie de confiance (fournisseur de services) de la collectivité R-E/du groupe de confiance multilatéral

Elle prendra la forme d’un IdP entièrement fonctionnel acceptant la multilatéralité.
Elle ne nécessitera aucune modification à la manière dont se comporte le fournisseur de services (SP).
Les attributs confirmés à la connexion correspondent à ceux auxquels s’attend le SP (à savoir, ils ne seront PAS perçus comme des « revendications »).

Utilisateur

L’utilisateur se connectera à Azure AD.
En tant qu’agent de procuration (proxy), l’IdP Shibboleth redirigera la connexion s’il y a lieu de le faire.
En réalité, l’utilisateur ouvrira deux séances :
- la première sur Azure AD;
- la seconde sur l’IdP Shibboleth.

Exploitant de la fédération

L’entité inscrite à la fédération R-E est l’IdP Shibboleth. Celui-ci a été conçu par et pour les membres du milieu R-E. Il devrait donc en respecter toutes les exigences techniques, comme le ferait n’importe quel IdP Shibboleth.
Cette harmonisation avec les attentes fondamentales de la fédération ne se borne pas aux logiciels, mais aussi à la manière dont on gère et utilise ceux-ci. L’exploitant de l’IdP en garde le contrôle, comme il le ferait pour n’importe quel IdP.

Procuration de l’IdP : à quoi ressemble le flux de proxys?

Voici ce qui se produit habituellement quand l’utilisateur établit la connexion.

1. L’IdP Shibboleth reçoit une demande d’authentification.

2. Il détermine si la configuration correspond à celle d’une connexion SAML et la relaie à un IdP en amont (Azure AD). Les paramètres correspondants se trouvent dans :

a. properties
b. authn/saml-authn-config.xml

3. L’identité de l’utilisateur est confirmée ou celui-ci est connecté à un IdP en amont (Azure AD).

4. L’IdP en amont (Azure AD) génère une assertion SAML avec un ou plusieurs attributs, puis la transmet à l’IdP Shibboleth avec l’utilisateur.

5. L’IdP Shibboleth reçoit l’assertion.

a. Il s’assure qu’elle émane bien d’une entité fiable, configurée dans metadata-providers.xml.
b. Il applique à l’assertion les règles établies dans attribute-filter.xml.
c. Il en extrait l’utilisateur réel, conformément à ce qui a été configuré dans attribute-based subject c14n.

i. Il parcourt la liste d’attributs du résolveur dans AttributesToResolve et vérifie chacun d’eux.
ii. Il compare les attributs résultants à ceux dans AttributeSourceIds et sélectionne le premier valable comme nom principal dont il se servira plus tard.

d. Le nom d’utilisateur réel fiable obtenu sert de $resolutionContext.principal (c.-à-d. de connecteur LDAP pour la transmission des données, etc.) lors du processus « normal » de résolution des attributs.

Mettre la solution en place

Prérequis

Vous devrez disposer de ce qui suit et y avoir accès avant de débuter.

Un fournisseur d’identités (IdP) de version quatre (V4) ou plus récente fonctionnel, activé quelque part.
Un locataire d’Azure AD dont vous avez le contrôle en tant qu’administrateur.
La capacité de créer une application SAML pour entreprise ne figurant pas dans la galerie avec Azure AD.
Un attribut convenable dont les deux IdP pourront se servir pour procéder aux vérifications locales, s’il y a lieu.

Terminologie et paramètres

Cette partie présente quelques expressions et paramètres importants mentionnés ailleurs dans le document. Il est préférable de garder ces éléments à portée de la main pour accélérer la configuration.

L’identifiant (EntityID) de l’IdP d’origine : https://idp.example.com/idp
L’identifiant (EntityID) de l’IdP en amont, c’est-à-dire celui d’Azure : https://sts.windows.net/<sts_tenant_id>/
- La manière la plus simple de trouver sts_tenant_id consiste à créer une partie de confiance avec laquelle vous travaillerez dans Azure AD :
  - connectez-vous au portail d’Azure AD > sélectionnez Enterprise Applications > Create New Application > Non Gallery Application> créez une application > sélectionnez SAML Sign On > puis SAML Sign On Settings
  - l’identifiant d’Azure AD se trouve à la partie 4 (inclure le trait oblique).
- L’attribut de procuration qui unit les deux services :
  - SamAccountName est souvent un bon choix. L’attribut comprend souvent le suffixe « name » dans les revendications.
    - Il prendra la forme d’un nom d’utilisateur étendu.
    - L’extension correspond au domaine de l’organisation et est habituellement conviviale pour l’Internet (pas quelquechose.local ou quelquechose.int).
  - Partie de confiance/Fournisseur de services : Microsoft utilise parfois « partie de confiance » comme synonyme de « fournisseur de services ».

Étapes et tâches

1^re étape. Établir un lien de confiance entre l’IdP d’Azure AD et l’IdP Shibboleth

Trois configurations principales doivent être modifiées.

Dans l’IdP Shibboleth :

Les métadonnées doivent inclure SPSSODescriptor, au cas où on récupèrerait les métadonnées de l’IdP par l’URL.
Les métadonnées doivent comprendre une entrée pour l’IdP d’Azure AD afin qu’on puisse configurer le fournisseur de métadonnées.

Dans Azure AD :

Établir le lien entre Azure AD et l’IdP Shibboleth au moyen d’une partie de confiance.

1^re tâche : mettez à jour les métadonnées de l’IdP

Puisque votre IdP assumera le rôle d’un SP (fournisseur de services), vous devrez ajouter des blocs aux métadonnées de l’entité.

Mettez à jour le fichier idp-metadata.xml pour qu’il inclue un bloc <SPSSODescriptor>.
Copiez les certificats de signature et d’encryptage dans les métadonnées de l’IdP et remplacez l’URI de base (https://idp.example.com/idp) par celui de votre IdP.

<EntityDescriptor entityID="https://idp.example.com/idp" ...>

 

<!—Existe déjà dans les données de l’IdP -->

<IDPSSODescriptor ...>

...

</IDPSSODescriptor>

 

<AttributeAuthorityDescriptor>

...

</AttributeAuthorityDescriptor>

 

 

<!—Nouveau bloc SP -->

<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

 

<KeyDescriptor use="signing">

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>

...Signing Certificate from IdP...

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>

<KeyDescriptor use="encryption">

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>

...Encryption Certificate from IdP...

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>

 

<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.example.com/idp/profile/Authn/SAML2/POST/SSO" index="0"/>

</SPSSODescriptor>

 

</EntityDescriptor>

2^e tâche : enregistrez votre IdP dans Azure AD

Vous devez créer une application d’entreprise du genre « application ne figurant pas dans la galerie » dans Azure AD, puis la configurer pour qu’elle accepte le standard SAML.

Étapes

Ouvrir une séance sur le portail Azure AD > sélectionner Enterprise Applications > New Application > Application ne figurant pas dans la galerie > la créer > sélectionner SAML Sign On > puis SAML Sign On Settings

Une fois l’application créée, les deux éléments que voici devront être modifiés dans la partie « Configuration SAML de base » :

l’identificateur (ID d’entité) : https://idp.example.com/idp/shibboleth (il devrait être le même que celui de l’IdP);
l’URL de réponse (Assertion Consumer Service) : https://idp.example.com/idp/profile/Authn/SAML2/POST/SSO.

On pourra ajouter d’autres éléments comme l’URL de déconnexion, mais puisque Shibboleth n’en tiendra pas compte, il est préférable de s’en abstenir.

Ne fermez pas l’éditeur de la partie de confiance, vous en aurez besoin pour l’étape suivante.

3^e tâche : enregistrez localement les métadonnées de l’IdP en amont

L’IdP Shibboleth ne connaît pas l’IdP d’Azure AD, donc vous devez l’ajouter localement. Pour cela, procédez comme vous le feriez pour n’importe quelle autre métadonnée. L’information peut être ajoutée à votre metadata-providers.xml comme s’il s’agissait d’un nouveau <MetadataProvider>.

Exemple :

<MetadataProvider id="AzureAD-idp-metadata"

xsi:type="FilesystemMetadataProvider"

metadataFile="/opt/idp/metadata/AzureAD-idp.xml" />

Le fichier AzureAD-idp.xml doit inclure un SML2 xml valable pour l’identifiant d’entité du locataire incluant ce qui suit :

un bloc IDPSSODescriptor comprenant un élément shibmd:scope saisi manuellement;
un élément X509Descriptor avec use=signing;
deux éléments SingleSignOnService;
un élément SingleLogOut (pour le renvoi des erreurs à Azure).

La façon la plus simple de procéder consiste à cliquer « XML de métadonnées de fédération » dans les informations sur la partie de confiance d’Azure AD (troisième partie). Cependant, une certaine épuration est requise pour obtenir une version plus légère des métadonnées.

Astuce : ceux qui utilisent un ordinateur Mac ou Unix trouveront sans doute plus commode de faire transiter le fichier par xmllint -format downloadedfile.xml > downloadedfile-formated.xml

Modifier les métadonnées qui ont été téléchargées en ajoutant à la fois le NameSpace en XML et une valeur pour shibmd:scope dans le bloc IDPSSODescriptor.

Ajouter ce qui suit à EntityDescriptor, dans les métadonnées qui ont été téléchargées : xmlns:shibmd= »urn:mace:shibboleth:metadata:1.0
Ajouter l’élément Extensions dans le bloc IDPSSODescriptor pour qu’il y ait concordance avec la portée validée selon la règle Proxy Task 2 ci-dessous :

<Extensions>
<shibmd:Scope regexp="false">your_scope_domain.here</shibmd:Scope>
</Extensions>

Quand vous aurez terminé, ajoutez une entrée à metadata-providers.xml. Si vous la récupérez d’ailleurs ou recourez à un autre moyen (par ex., cURL ou autrement), assurez-vous de bien en connaître l’origine et ne lui accordez pas une confiance aveugle. Effectuez d’abord les vérifications qui s’imposent.

Remarque

Au sujet des certificats

Le certificat produit par Azure AD n’est valable que trois ans et ne crée un lien de confiance qu’entre Azure et le proxy Shibboleth.
Attendez-vous à ce que ce lien se rompe à l’expiration du certificat.
Prévoyez aussi que l’équipe qui administre l’IdP devra effectuer le transfert de certificat entre Azure AD et votre instance de l’IdP.

Au sujet du téléchargement des métadonnées

Il n’y a pas de changement de ligne entre les lignes.
Les métadonnées contiennent des éléments superflus qu’on peut retrancher pour réduire la taille du fichier, à savoir :
- la signature qui apparaît au début du fichier;
- la partie Fed:ClaimTypesOffered.

4^e tâche : configurez la diffusion des attributs d’Azure AD en fonction de l’IdP Shibboleth

Dans l’éditeur de la partie de confiance, configurez les attributs dont l’IdP Shibboleth aura besoin pour fonctionner.

Pour une procuration passe-système

Les attributs émanent tous d’Azure AD et doivent être diffusés à la partie de confiance pour que l’IdP Shibboleth puisse gérer les données en aval.

Pour une procuration hybride

Techniquement, vous n’aurez besoin que de l’attribut servant à authentifier l’utilisateur.

Remarque : user.userprincipalname est l’identifiant principal habituellement retenu pour l’utilisateur, mais examinez attentivement vos procédures concernant son emploi et sa réutilisation éventuelle, car cet aspect prend une importance capitale avec l’authentification multifacteur et les attestations. Vous devez vous assurer que l’identifiant est unique et ne change pas.

2^e étape. Configurer l’IdP pour qu’il se comporte comme un IdP de procuration

Vous devrez effectuer les changements que voici pour que l’IdP en devienne un de procuration.

Modifier le processus d’authentification pour une authentification SAML
Établir l’entité qui prendra le flux en charge
Actualiser le filtre des attributs pour autoriser l’ingestion passage des attributs entrants
Adapter l’extraction des attributs par mise en forme canonique de l’objet (c14n et résolveur)

1^re tâche : changez le processus d’authentification de l’IdP pour l’authentification SAML

La modification s’effectue en trois temps.

1. Modifiez authn/saml-authn-config.xml pour que EntityID corresponde à l’identifiant d’entité d’Azure AD

Décommentez l’objet authn.SAML.discoveryFunction et modifiez target:
REMPLACEZ sts_tenant_id par votre identifiant.

Remarque : inclure le trait oblique

<bean id="shibboleth.authn.SAML.discoveryFunction" parent="shibboleth.Functions.Constant"

c:target="https://sts.windows.net/<sts_tenant_id>/" />

2. Autorisez le passage des données en modifiant authn.flows dans idp.properties pour SAML :

idp.authn.flows=SAML

2^e tâche : actualisez le filtre des attributs

L’IdP n’ingèrera pas les attributs de l’IdP Azure AD en amont si un filtre ne le permet pas.

Ajoutez une <AttributeFilterPolicy> pour autoriser le traitement des attributs.
Remplacez sts_tenant_id par votre identifiant.

Remarque : inclure le trait oblique.

Remarque : Une règle ScopeMatchesShibMDScope s’applique au « nom » de l’attribut (appelé azureName sur la plateforme).

Cette règle garantit la concordance de id.properties:idp scope avec le champ d’Azure AD, pour éviter les anomalies. S’il y a discordance, la règle déclenche une interruption qui empêchera l’utilisateur de se connecter.

Pour que tout fonctionne correctement, assurez-vous que les métadonnées de l’IdP correspondent à la bonne plage de l’IdP d’Azure AD.

<AttributeFilterPolicy id="FilterPolicyObject-Proxy-FromAzure-byIssuer-Type">

<PolicyRequirementRule xsi:type="Issuer" value="https://sts.windows.net/<sts_tenant_id>/" />

 

<AttributeRule attributeID="azureDisplayname" permitAny="true" />

<AttributeRule attributeID="azureGivenname" permitAny="true" />

<AttributeRule attributeID="azureSurname" permitAny="true" />

<AttributeRule attributeID="azureAuthnmethodsreferences" permitAny="true" />

<AttributeRule attributeID="azureIdentityprovider" permitAny="true" />

<AttributeRule attributeID="azureTenantid" permitAny="true" />

<AttributeRule attributeID="azureEmailaddress" permitAny="true" />

<AttributeRule attributeID="azureObjectidentifier" permitAny="true" />

<AttributeRule attributeID="azureName">

<PermitValueRule xsi:type="ScopeMatchesShibMDScope" />

</AttributeRule>

</AttributeFilterPolicy>

3^e tâche : amenez l’IdP à accepter les revendications d’Azure AD

Les assertions SAML que diffuse Azure AD prennent la forme de revendications, car elles sont nommées selon une convention centrée sur la fédération des services Web d’Azure (WS-Fed).

Pour contourner l’obstacle, nous ajouterons un nouveau fichier de mappage des attributs qui autorisera l’analyse des revendications et leur qualification d’attribut interne, afin que le résolveur puisse les utiliser.

S’il n’en existe pas déjà un, ajoutez à l’IdP un fichier que vous baptiserez attributes/azureClaims.xml. Vous y inclurez tous les attributs d’Azure AD dont vous vous servirez avec le résolveur.

Sans être exhaustif, l’exemple qui suit est assez détaillé pour que vous débutiez avec le fichier des revendications.

Par mesure de sécurité, on appliquera une règle de portée à azName. La plage DOIT correspondre à l’extension <shibmd:Scope> qui figure dans les métadonnées de l’IdP en amont.
La propriété de la règle « saml2.nameFormat » est urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified, car les revendications ne sont pas formatées de la manière appropriée.

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:context="http://www.springframework.org/schema/context"

xmlns:util="http://www.springframework.org/schema/util"

xmlns:p="http://www.springframework.org/schema/p"

xmlns:c="http://www.springframework.org/schema/c"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd

http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd

http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"

 

default-init-method="initialize"

default-destroy-method="destroy">

 

<bean parent="shibboleth.TranscodingRuleLoader">

<constructor-arg>

<list>

<!-- claims relevant to person record -->

<bean parent="shibboleth.TranscodingProperties">

<property name="properties">

<props merge="true">

<prop key="id">azureName</prop>

<prop key="transcoder">SAML2ScopedStringTranscoder</prop>

<prop key="saml2.name">http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name</prop>

<prop key="saml2.nameFormat">urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified</prop>

<prop key="displayName.en">Name</prop>

<prop key="description.en">Azure UPN of an account expecting to be scoped thus transcoded that way</prop>

</props>

</property>

</bean>

<bean parent="shibboleth.TranscodingProperties">

<property name="properties">

<props merge="true">

<prop key="id">azureEmailaddress</prop>

<prop key="transcoder">SAML2StringTranscoder</prop>

<prop key="saml2.name">http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</prop>

<prop key="saml2.nameFormat">urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified</prop>

<prop key="displayName.en">Mail</prop>

<prop key="description.en">Azure emailaddress field of an account</prop>

</props>

</property>

</bean>

<bean parent="shibboleth.TranscodingProperties">

<property name="properties">

<props merge="true">

<prop key="id">azureDisplayname</prop>

<prop key="transcoder">SAML2StringTranscoder</prop>

<prop key="saml2.name">http://schemas.microsoft.com/identity/claims/displayname</prop>

<prop key="saml2.nameFormat">urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified</prop>

Maintenant que l’IdP peut interpréter les revendications d’Azure AD, il faut en autoriser l’utilisation pour la mise en forme canonique et peupler le fichier d’attributs.

4^e tâche : procédez à la mise en forme canonique de l’objet

Cette tâche consiste à prendre l’assertion entrante pour en extraire des données et procéder à la mise en forme canonique (documentation/normalisation) du nom de l’utilisateur qui se connecte à Azure.

Pour Azure AD, on utilisera la revendication: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name qui a été mappée à l’interne dans l’IdP sous la forme azName.

Ajoutez une <AttributeDefinition> à attribute-resolver.xml de la manière indiquée ci-dessous.

Ceci modifiera l’attribut azName de l’objet (données extraites de la revendication entrante) en pour créer un attribut canonicalNameToUseForJoin qu’on utilisera ailleurs.

<AttributeDefinition xsi:type="SubjectDerivedAttribute"

forCanonicalization="true"

id="canonicalNameToUseForJoin"

principalAttributeName="azureName" />

Ensuite, configurez les attributs que la fonction c14n doit résoudre.

Définissez les objets shibboleth.c14n.attribute.AttributesToResolve et shibboleth.c14n.attribute.AttributeSourceIds dans c14n/attribute-sourced-subject-c14n-config.xml en leur attribuant l’identifiant défini dans <AttributeDefinition> ci-dessus :

<util:list id="shibboleth.c14n.attribute.AttributesToResolve">

<value>canonicalNameToUseForJoin</value>

</util:list>

<util:list id="shibboleth.c14n.attribute.AttributeSourceIds">

<value>canonicalNameToUseForJoin</value>

</util:list>

Il se peut qu’il y ait plus d’un attribut selon la méthode de procuration. En ce qui concerne Azure AD cependant, nous nous concentrerons sur un seul.

Vous devriez maintenant disposer d’un nom d’utilisateur valable, déchiffrable localement et pouvant être relayé au résolveur « normal » en opération à certains endroits comme :

$resolutionContext.principal

5^e tâche : configurez la résolution passe-système ou hybride des attributs

Les attributs d’Azure AD sont référencés dans attribute-resolver.xml comme ceci :

N’oubliez pas d’ajouter un commentaire à l’ancienne définition des noms dans attribute-resolver.xml sinon vous pourriez obtenir des résultats inattendus.

AttributeDefinition xsi:type="SubjectDerivedAttribute"

forCanonicalization="false"

id="mail"

principalAttributeName="azureEmailaddress" />

 

<AttributeDefinition xsi:type="SubjectDerivedAttribute"

forCanonicalization="false"

id="displayName"

principalAttributeName="azureDisplayname" />

 

<AttributeDefinition xsi:type="SubjectDerivedAttribute"

id="eduPersonPrincipalName"

principalAttributeName="azureName" />

Essai

Relancez l’IdP pour activer les modifications. Puisque la procuration que vous avez configurée repose sur SAML, il n’y a aucun sens à utiliser l’interface de commande aacli, car elle ne disposera d’aucune information.

Il arrive qu’on crée un compte de développement dont le locataire permet d’effectuer des essais totalement à l’écart du locataire de production. Une autre solution consiste à créer une application SAML hors de la galerie d’Azure AD pour chaque IdP – soit une pour la production, une pour la pré-production, etc. Il n’existe aucune règle toute faite ou immuable sur la façon idéale de procéder, cependant le compte de développement est gratuit et se prête bien à la séparation des justificatifs d’identité, car le domaine du témoin (cookie) est entièrement différent.

Documentation / Lectures recommandées

Shibboleth

SSO et SAML d’Azure AD

Comprendre l’authentification unique basée sur SAML : https://docs.microsoft.com/fr-ca/azure/active-directory/manage-apps/configure-saml-single-sign-on
Série « Démarrage rapide » : https://docs.microsoft.com/fr-ca/azure/active-directory/manage-apps/view-applications-portal

FCA – Comment se connecter à Azure AD en utilisant la procuration SAML dans l’IdP Shibboleth