Shibboleth configureren voor gebruik met eenmalige aanmelding

Gepubliceerd: juni 2012

Van toepassing op: Office 365, Windows Azure Active Directory, Windows Intune

Dit onderwerp bevat gedetailleerde instructies om de Shibboleth-identiteitsprovider te configureren voor het maken van federatieve domeinen met Windows Azure AD en toegang via eenmalige aanmelding tot een of meer Microsoft-cloudservices (bijvoorbeeld Windows Intune en/of Office 365) in te schakelen met het SAML 2.0-protocol. De SAML 2.0 relying party voor een Microsoft-cloudservice die in dit scenario wordt gebruikt, is Windows Azure AD.

Als u de Shibboleth-identiteitsprovider wilt configureren voor gebruik met eenmalige aanmelding, voltooit u de volgende stappen:

1. Windows Azure AD-metagegevens toevoegen

2. Windows Azure AD toevoegen als relying party

3. Shibboleth attribute resolver configureren

4. Shibboleth attribute filter configureren

5. Optioneel: de ECP-extensie van Shibboleth installeren

6. Shibboleth opnieuw starten en de functionaliteit verifiëren

Windows Azure AD-metagegevens toevoegen

De Shibboleth-identiteitsprovider heeft informatie nodig over de Windows Azure AD relying party. Windows Azure AD publiceert metagegevens op https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. U wordt aanbevolen altijd te controleren of nieuwe Windows Azure AD-metagegevens beschikbaar zijn. Hier volgt de huidige waarde van de metagegevens:

<?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>

Als u de Windows Azure AD-metagegevens wilt toevoegen aan de Shibboleth-identiteitsprovider, kunt u de methode Filesystem Metadata Provider gebruiken. U kunt Windows Azure AD-metagegevens handmatig downloaden en opslaan in een bestand in de map IDP_HOME/metadata.

Windows Azure AD toevoegen als relying party

U moet communicatie tussen de Shibboleth-identiteitsprovider en Windows Azure AD inschakelen door een nieuwe element RelyingParty te definiëren in het bestand IDP_Home/conf/relying-party.xml. Windows Azure AD vereist wijzigingen in de standaardinstellingen saml:SAML2Profile in het element DefaultRelyingParty.

Voeg de volgende tekst in achter het element DefaultRelyingParty en zorg ervoor dat de waarde voor RelyingParty id overeenkomt met de waarde voor entityID die u hebt opgegeven in Windows Azure AD-metagegevens toevoegen, bijvoorbeeld "urn:federation:MicrosoftOnline". Zorg er ook voor dat uw waarde voor provider overeenkomt met de EntityID van uw Shibboleth-identiteitsprovider die is opgegeven in het element DefaultRelyingParty, zoals wordt weergegeven in het volgende voorbeeld:

<!-- Windows 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>

U moet voor de Shibboleth-identiteitsprovider ook opgeven waar het bestand met de Windows Azure AD-metagegevens kan worden gevonden, bijvoorbeeld IDP_HOME/metadata/wlid-metadata.xml. Hiervoor kunt u aan het bestand IDP_Home/conf/relying-party.xml een vermelding toevoegen in het knooppunt MetadataProvider, zoals wordt weergegeven in het volgende voorbeeld:

<!—- Windows 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"/>

Shibboleth attribute resolver configureren

Windows Azure AD vereist twee gegevensstukken van de Shibboleth-identiteitsprovider om het schaduwaccount te vinden in het verificatieplatform. Als u Shibboleth de informatie over deze vereisten wilt geven, moet u de volgende vermeldingen toevoegen aan het bestand IDP_HOME/conf/attribute-resolver.xml:

• Windows Azure AD ImmutableID

  Windows Azure AD vereist dat u een unieke id selecteert voor elke gebruiker in de lijst met gebruikers. U moet Shibboleth ook configureren om dit kenmerk bij elke federatieve aanmelding bij Windows Azure AD in de SAML 2.0 NameID-verklaring te verzenden. Deze id mag niet wijzigen voor deze gebruiker zolang de gebruiker aanwezig is in uw systeem. In de Windows Azure AD-service wordt dit kenmerk 'ImmutableID' genoemd. De waarde voor de unieke id mag geen domeingegevens bevatten en is hoofdlettergevoelig.

  Gebruik bijvoorbeeld niet gebruiker@contoso.com. In de aanbevolen code hieronder is de gebruikte waarde de base64-gecodeerde Active Directory objectGUID-eigenschap. Wanneer u accounts maakt, moet u ervoor zorgen dat de ImmutableID op dezelfde wijze wordt verwerkt. Anders kan de gebruiker zich niet aanmelden bij de Microsoft-cloudservice. Het hulpprogramma voor Microsoft Online Services-adreslijstsynchronisatie maakt voor de ImmutableID-waarde automatisch gebruik van de Active Directory objectGUID en verwerkt de ImmutableID op dezelfde wijze als in het volgende voorbeeld:

  <!-- 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> 
  

  Belangrijk

  Werk de LDAP Data Connector in het bestand attribute-resolver.xml bij om objectGUID op te geven als een binaire waarde.

  Voeg deze regel toe aan de vermelding voor de LDAP Data Connector. Zo zorgt u ervoor dat de objectGUID correct wordt verwerkt en base64-gecodeerd is.

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

  Bijvoorbeeld:

  <!-- ========================================== -->
  <!--      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>
  

• Windows Azure AD User ID

  Windows Azure AD vereist dat de Windows Azure AD User ID, bijvoorbeeld jeroen@contoso.com, wordt verzonden met de aangepaste vermelding, zoals in het onderstaande voorbeeld is beschreven. In dit voorbeeld wordt de waarde opgeslagen in het LDAP-kenmerk userPrincipalName.

  <!-- UserPrincipalName for Windows 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> 
  

Shibboleth attribute filter configureren

De Shibboleth-identiteitsprovider moet worden geconfigureerd om de vereiste kenmerken vrij te geven aan Windows Azure AD. Voeg de volgende tekst toe aan het bestand IDP_HOME/conf/attribute-filter.xml om de kenmerken vrij te geven aan Windows Azure AD.

De instellingen die hier worden weergegeven, geven de vereiste kenmerken alleen vrij aan Windows Azure AD en Windows Live-services. De instellingen gebruiken specifieke AttributeFilterPolicy-id's om aan te geven dat de kenmerken zijn vereist voor Windows Azure AD.

<!-- Release userPrincipalName as Windows Azure AD User ID -->
<afp:AttributeFilterPolicy id="UserId">
   <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>

      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

</afp:AttributeFilterPolicy>


<!-- Release Immutable ID to Windows Azure AD -->
<afp:AttributeFilterPolicy id="ImmutableID">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline"/>

      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

 </afp:AttributeFilterPolicy>

Optioneel: de ECP-extensie van Shibboleth installeren

Hoewel dit een optionele stap is, wordt u aanbevolen deze toch uit te voeren. Als u Shibboleth als uw STS gebruikt, installeert u de ECP-extensie van de Shibboleth-identiteitsprovider om ervoor te zorgen dat eenmalige aanmelding correct werkt met smartphones, Microsoft Outlook of andere clients.

De ECP-extensie (Enhanced Client/Proxy) is beschikbaar in Shibboleth 2.3.3 en hoger. Voor lagere versies van Shibboleth 2.x kunt u de ECP-extensie downloaden en installeren. Zie https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension voor meer informatie.

Met de ECP-extensie van de Shibboleth-identiteitsprovider kunt u desktoptoepassingen voor e-mail integreren met Windows Azure AD. Deze extensie implementeert de SAML 2.0 ECP-specificatie. Wanneer u eenmalige aanmelding configureert met Windows Azure AD, kunt u de URL voor de ECP-extensie opgeven, bijvoorbeeld https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Voor de ECP-extensie van Shibboleth is momenteel alleen basisverificatie beschikbaar.

Shibboleth opnieuw starten en de functionaliteit verifiëren

Stop en start Apache Tomcat om de Shibboleth-identiteitsprovider opnieuw te starten en zorg ervoor dat de bijgewerkte XML-bestanden worden geladen. Shibboleth kan mogelijk niet worden gestart als er een probleem is met een of meer configuratiebestanden. Controleer na het opnieuw starten van Shibboleth of in de logboekbestanden voor Shibboleth geen fouten worden gemeld. Meld u aan en probeer toegang te krijgen tot een eerder geconfigureerde Shibboleth-serviceprovider in uw netwerk.

Zie ook

Concepten

Eenmalige aanmelding implementeren met de Shibboleth-identiteitsprovider