Configurer Shibboleth pour l'utilisation avec l'authentification unique

  • Article

Mise à jour : 25 juin 2015

S’applique à : Azure, Office 365, Power BI, Windows Intune

Cette rubrique contient des instructions détaillées sur la configuration du fournisseur d’identité Shibboleth pour fédérer avec Azure AD afin d’activer l’accès à l’authentification unique à un ou plusieurs services cloud Microsoft (par exemple, Microsoft Intune et/ou Office 365) à l’aide du protocole SAML 2.0. La partie utilisatrice de SAML 2.0 pour un service de cloud Microsoft utilisée dans ce scénario est Azure AD.

Important

Seul un ensemble limité de clients est pris en charge dans ce scénario d'authentification unique, à savoir :

  • Clients web (p. ex., Exchange Web Access et SharePoint Online)

  • Clients de messagerie riches utilisant l'authentification de base et une méthode d'accès Exchange prise en charge comme IMAP, POP, Active Sync, MAPI, etc. (nécessité de déployer le point de terminaison Enhanced Client Protocol), y compris :

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 et 9

    • iPhone (différentes versions d'iOS)

    • Windows Phone 7

Tous les autres clients ne sont pas pris en charge dans ce scénario d’authentification unique avec Shibboleth Identity Provider.  Par exemple, le client de bureau Lync 2010 n’est pas pris en charge pour se connecter au service avec Shibboleth Identity Provider configuré pour l’authentification unique.

Important

Avant de pouvoir effectuer l’une des étapes décrites dans cette rubrique pour configurer Shibboleth Identity Provider pour l’authentification unique, vous devez passer en revue et suivre les instructions fournies dans Préparer l’authentification unique.

Pour plus d’informations sur l’authentification unique, consultez la feuille de route de l’authentification unique.

Pour configurer le fournisseur d'identité Shibboleth pour une utilisation avec l'authentification unique, procédez comme suit :

  1. Ajouter les métadonnées Azure AD

  2. Ajouter Azure AD en tant que partie utilisatrice

  3. Configuration du programme de résolution d'attributs Shibboleth

  4. Configuration du filtre d'attributs Shibboleth

  5. Facultatif : installer l’extension ECP Shibboleth

  6. Redémarrage de Shibboleth et vérification des fonctionnalités

Important

Dans les exemples de cette rubrique, IDP_HOME est le répertoire de base dans lequel vous avez installé le fournisseur d'identité Shibboleth, par exemple, c:\shibboleth2idp. Pendant que vous suivez les instructions de cette rubrique pour configurer Shibboleth, veillez à remplacer IDP_HOME par votre chemin d'accès spécifique.

Ajouter les métadonnées Azure AD

Le fournisseur d'identité Shibboleth a besoin d'informations sur la partie de confiance Azure AD. Azure AD publie des métadonnées dans https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Nous vous recommandons de toujours vérifier les métadonnées Azure AD les plus récentes. Voici la valeur actuelle des métadonnées :

<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="urn:federation:MicrosoftOnline">
  <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0" isDefault="true"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://login.microsoftonline.com/login.srf" index="1"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf" index="2" />
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    </NameIDFormat>
    <NameIDFormat>
      urn:mace:shibboleth:1.0:nameIdentifier
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    </NameIDFormat>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    </NameIDFormat>
  </SPSSODescriptor>
</EntityDescriptor>

Pour ajouter les métadonnées Azure AD au fournisseur d'identité Shibboleth, vous pouvez utiliser la méthode The Filesystem Metadata Provider ; vous pouvez télécharger et stocker manuellement les métadonnées Azure AD dans un fichier situé dans le dossier IDP_HOME/metadata.

Important

Dans les exemples de cette rubrique, IDP_HOME est le répertoire de base dans lequel vous avez installé le fournisseur d'identité Shibboleth, par exemple, c:\shibboleth2idp. Pendant que vous suivez les instructions de cette rubrique pour configurer Shibboleth, veillez à remplacer IDP_HOME par votre chemin d'accès spécifique.

Ajouter Azure AD en tant que partie utilisatrice

Vous devez autoriser les communications entre le fournisseur d'identité Shibboleth et Azure AD en définissant un nouvel élément RelyingParty dans le fichier IDP_Home/conf/relying-party.xml. Azure AD nécessite la modification des paramètres saml:SAML2Profile par défaut dans l'élément DefaultRelyingParty.

Insérez le texte suivant après l’élément DefaultRelyingParty et vérifiez que la valeur d’ID RelyingParty correspond à la valeur entityID que vous avez spécifiée dans Ajouter des métadonnées Azure AD, par exemple « urn:federation:MicrosoftOnline ». Assurez-vous également que votre valeur provider correspond à la valeur EntityID de votre fournisseur d'identité Shibboleth spécifiée dans l'élément DefaultRelyingParty comme indiqué dans l'exemple suivant :

<!-- Azure AD -->
<rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.com/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
         
     <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
signAssertions="conditional"
encryptAssertions="never"
encryptNameIds="never" />
             
</rp:RelyingParty>

Vous devez également spécifier au fournisseur d'identité Shibboleth où trouver le fichier qui contient les métadonnées Azure AD, par exemple, IDP_HOME/metadata/windows-azure-ad-metadata.xml. Pour ce faire, ajoutez une entrée dans le fichier IDP_Home/conf/relying-party.xml dans le nœud MetadataProvider, comme illustré dans l'exemple suivant :

<!—- Azure AD Metadata -->
<metadata:MetadataProvider id="OrgID" xsi:type="metadata:ResourceBackedMetadataProvider">
<metadata:MetadataResource xsi:type="resource:FilesystemResource" file="C:\opt\shibboleth-idp/metadata/WindowsAzureAD-metadata.xml"/>

Configuration du programme de résolution d'attributs Shibboleth

Azure AD a besoin de deux éléments de données auprès du fournisseur d'identité Shibboleth pour rechercher le compte fictif dans la plateforme d'authentification. Pour informer Shibboleth de ces exigences, ajoutez les entrées suivantes au fichier IDP_HOME/conf/attribute-resolver.xml :

  • Azure AD ImmutableID

    Azure AD nécessite la sélection d'un identificateur unique pour chaque utilisateur présent dans votre annuaire d'utilisateurs. Vous devez également configurer Shibboleth pour envoyer cet attribut à chaque connexion d'accès fédérée à Azure AD dans l'assertion NameID de SAML 2.0. Cet identificateur ne doit pas changer au cours de la durée de vie de l'utilisateur dans votre système. Le service Azure AD appelle cet attribut « ImmutableID ». La valeur de l'identificateur unique ne doit pas contenir d'informations de domaine et respecte la casse.

    Par exemple, n’utilisez user@contoso.compas . Dans le code recommandé ci-dessous, la valeur utilisée est la propriété objectGUID Active Directory codée en base64. Lorsque vous créez des comptes, vous devez vous assurer que l'attribut ImmutableID est traité de la même manière, sinon l'utilisateur ne sera pas en mesure de se connecter au service de cloud computing Microsoft. L’outil de synchronisation Microsoft Azure Active Directory utilise automatiquement l’objetGUID Active Directory pour la valeur ImmutableID et traite l’ImmutableID de la même façon que dans l’exemple recommandé suivant :

    <!-- Use AD objectGUID for ImmutableID -->
<resolver:AttributeDefinition id="ImmutableID" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
          sourceAttributeID="objectGUID">
   <resolver:Dependency ref="myLDAP" />

   <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
   nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
  </resolver:AttributeDefinition>

    Important

    Mettez à jour le connecteur de données LDAP dans attribute-resolver.xml pour spécifier objectGUID comme binaire.

    Assurez-vous que vous ajoutez cette ligne à votre entrée de connecteur de données LDAP pour garantir que la propriété objectGUID est gérée correctement et codée en base 64.

    <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

    Par exemple :

    <!-- ========================================== -->
<!--      Data Connectors                       -->
<!-- ========================================== -->
<!-- Live@edu LDAP Connector -->
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                   ldapURL="ldap://MyADServer:389"
                   baseDN="CN=Users,DC=MyDomain,DC=ORG"
                   principal="CN=Administrator,CN=Users,DC=MyDomain,DC=ORG"
                   principalCredential="A.useful.p!w.d">
  <FilterTemplate>
    <![CDATA[
                (uid=$requestContext.principalName)
            ]]>
  </FilterTemplate>

  <LDAPProperty name="java.naming.ldap.attributes.binary" value="objectGUID"/>

</resolver:DataConnector>

  • ID d’utilisateur Azure AD

    Azure AD nécessite que l’ID d’utilisateur Azure AD, par exemple, joe@contoso.comsoit envoyé à l’aide de l’entrée personnalisée, comme décrit dans l’exemple ci-dessous. Dans cet exemple, la valeur est stockée dans l'attribut LDAP userPrincipalName.

    <!-- UserPrincipalName for Azure AD User ID -->
<resolver:AttributeDefinition id="UserId" xsi:type="ad:Simple" sourceAttributeID="userPrincipalName">
      <resolver:Dependency ref="myLDAP" />
      <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="IDPEmail" friendlyName="UserId" />
</resolver:AttributeDefinition>

Configuration du filtre d'attributs Shibboleth

Le fournisseur d'identité Shibboleth doit être configuré pour libérer les attributs requis pour Azure AD. Ajoutez le texte suivant dans le fichier IDP_HOME/conf/attribute-filter.xml pour libérer les attributs vers Azure AD.

Les paramètres présentés ici libèrent les attributs requis uniquement pour les services Azure AD et Windows Live. Les paramètres utilisent des ID AttributeFilterPolicy spécifiques pour indiquer les attributs requis par Azure AD.

<!-- Attribute Filter Policy for Azure AD -->
<afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline" />

<!-- Release userPrincipalName as Azure AD User ID -->
      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Release Immutable ID to Azure AD -->
      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Note: it is not recommended to send transientId to Azure AD -->
<afp:AttributeRule attributeID="transientId">
   <afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>

</afp:AttributeFilterPolicy>

Facultatif : installer l’extension ECP Shibboleth

Bien que facultative, cette étape est recommandée. Si vous utilisez Shibboleth en tant que STS, assurez-vous d'installer l'extension Shibboleth Identity Provider ECP pour que l'authentification unique fonctionne avec un smartphone, Microsoft Outlook ou d'autres clients.

L'extension client/proxy améliorée (ECP) est incluse dans Shibboleth 2.3.3 et versions ultérieures. Pour les versions antérieures de Shibboleth 2.x, vous pouvez télécharger et installer l'extension ECP. Pour plus d’informations, consultez https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

L'extension ECP de fournisseur d'identité Shibboleth vous permet d'activer l'intégration d'applications de messagerie de bureau avec Azure AD. Cette extension implémente la spécification ECP de SAML 2.0. Lorsque vous configurez une authentification unique avec Azure AD, vous pouvez spécifier l'URL de l'extension ECP, par exemple, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. L'authentification de l'extension ECP de Shibboleth est actuellement limitée à l'authentification de base.

Effectuez les étapes suivantes si vous avez choisi d'installer l'extension ECP de Shibboleth :

  1. Ajoutez le code suivant à votre fichier de métadonnées Azure AD local, situé dans IDP_HOME/metadata :

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>

  2. Ajoutez l'entrée « saml:SAML2ECPProfile » au nœud de configuration Azure AD RelyingParty dans le fichier relying-party.xml situé dans IDP_HOME/config :

    <rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">  
                <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
                                signAssertions="conditional" 
                                encryptAssertions="never"                          
                                encryptNameIds="never" />                                                      
                <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile"                                                           
                                signAssertions="always"                  
                                encryptAssertions="never"                  
                                encryptNameIds="never"/>                                                             
</rp:RelyingParty>

Redémarrage de Shibboleth et vérification des fonctionnalités

Arrêtez et démarrez Apache Tomcat pour redémarrer le fournisseur d'identité Shibboleth et assurer le chargement des fichiers XML mis à jour. Shibboleth peut ne pas démarrer s'il existe un problème avec un ou plusieurs des fichiers de configuration. Vérifiez les fichiers journaux de Shibboleth après redémarrage afin de garantir qu'aucune erreur n'est signalée. Nous vous recommandons également d'essayer de vous connecter et d'accéder à un fournisseur de service Shibboleth précédemment configuré sur votre réseau.

Notes

Vérifiez que l'horloge sur votre serveur Shibboleth est synchronisée avec une source de temps précise. Une heure inexacte peut entraîner l’échec des connexions fédérées.

Voir aussi

Concepts

Utiliser le fournisseur d'identité Shibboleth pour implémenter l'authentification unique