Konfigurere Shibboleth til brug med enkeltlogon

  • Artikel

Udgivet: juni 2012

Gælder for: Office 365, Windows Azure Active Directory, Windows Intune

Bemærk

Dette emne indeholder onlinehjælp, der gælder for flere af Microsofts skytjenester, herunder Windows Intune og Office 365.

Dette emne indeholder en detaljeret vejledning i, hvordan du konfigurerer Shibboleth-identitetsudbyderen til at indgå i organisationsnetværk med Windows Azure AD for at give mulighed for enkeltlogonadgang til en eller flere Microsoft-skytjenester (f.eks. Windows Intune og/eller Office 365) ved hjælp af SAML 2.0-protokollen. Den SAML 2.0 Relying Party for en Microsoft-sky-tjeneste, der bruges i dette scenarie, er Windows Azure AD.

Vigtigt

Dette enkeltlogonscenarie understøtter kun et begrænset sæt klienter, nemlig:

  • Webbaserede klienter som f.eks. Exchange Web Access og SharePoint Online

  • Klienter med e-mail-funktion, der bruger grundlæggende godkendelse og en understøttet Exchange-adgangsmetode som f.eks. IMAP, POP, Active Sync, MAPI osv. (det udvidede slutpunkt for klientprotokollen skal være installeret), herunder:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 og 9

    • IPhone (forskellige iOS-versioner)

    • Windows Phone 7

Alle andre klienter understøttes ikke i dette enkeltlogonscenarie med Shibboleth-identitetsudbyderen. For eksempel understøttes Lync 2010-klienten ikke til logon på tjenesten med Shibboleth-identitetsudbyderen konfigureret til enkeltlogon.

Vigtigt

Før du kan færdiggøre nogle af trinnene i dette emne for at konfigurere Shibboleth-identitetsudbyderen til enkeltlogon, skal du gennemgå og følge vejledningen i Forberede enkeltlogon.

Du kan finde generelle oplysninger om enkeltlogon under Vejledning til enkeltlogon.

For at konfigurere Shibboleth-identitetsudbyderen til brug med enkeltlogon, skal du udføre følgende trin:

  1. Tilføje Windows Azur AD-metadata

  2. Tilføje Windows Azure AD som Relying Party

  3. Konfigurere Shibboleth-attributfortolkeren

  4. Konfigurere Shibboleth-attributfilteret

  5. Valgfri: Installere Shibboleth ECP-udvidelse

  6. Genstarte Shibboleth, og kontrollere funktionaliteten

Vigtigt

I alle eksemplerne i dette emne er IDP_HOME den basismappe, hvor du installerede Shibboleth-identitetsudbyderen, f.eks. c:\shibboleth2idp. Når du følger vejledningen i dette emne for at konfigurere Shibboleth, skal du sørge for at erstatte IDP_HOME med din specifikke sti.

Tilføje Windows Azur AD-metadata

Shibboleth-identitetsudbyderen kræver oplysninger om den Windows Azur AD Relying Party. Windows Azur AD udgiver metadata på https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Det anbefales, at du altid kontrollerer, om du bruger de nyeste Windows Azur AD-metadata. Her er metadataenes aktuelle værdi:

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

Hvis du vil føje Windows Azure AD-metadataene til Shibboleth-identitetsudbyderen, kan du bruge metoden The Filesystem Metadata Provider – du kan download og gemme Windows Azure AD-metadata manuelt i en fil i mappen IDP_HOME/metadata.

Vigtigt

I alle eksemplerne i dette emne er IDP_HOME den basismappe, hvor du installerede Shibboleth-identitetsudbyderen, f.eks. c:\shibboleth2idp. Når du følger vejledningen i dette emne for at konfigurere Shibboleth, skal du sørge for at erstatte IDP_HOME med din specifikke sti.

Tilføje Windows Azure AD som Relying Party

Du skal aktivere kommunikation mellem Shibboleth-identitetsudbyderen og Windows Azure AD ved at definere et nyt RelyingParty-element i filen IDP_Home/conf/relying-party.xml. Windows Azure AD kræver, at der foretages ændringer i standardindstillingerne for saml:SAML2Profile i elementet DefaultRelyingParty.

Indsæt følgende tekst efter elementet DefaultRelyingParty, og sørg for, at værdien i RelyingParty id er identisk med værdien for entityID, du har angivet under Tilføje Windows Azur AD-metadata, f.eks. "urn:federation:MicrosoftOnline". Sørg også for, at din udbyder-værdi svarer til enheds-id'et for din Shibboleth-identitetsudbyder, der er angivet i elementet DefaultRelyingParty, som vist i følgende eksempel:

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

Du skal også angive, hvor Shibboleth-identitetsudbyderen skal finde den fil, der indeholder Windows Azure AD-metadataene, f.eks. IDP_HOME/metadata/wlid-metadata.xml. Du kan gøre dette ved at tilføje en post i filen IDP_Home/conf/relying-party.xml i noden MetadataProvider som vist i følgende eksempel:

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

Konfigurere Shibboleth-attributfortolkeren

Windows Azure AD skal bruge to sæt data fra Shibboleth-identitetsudbyderen for at kunne finde skyggekontoen på godkendelsesplatformen. For at oplyse Shibboleth om disse krav skal du tilføje følgende poster i filen IDP_HOME/conf/attribute-resolver.xml:

  • Windows Azure AD ImmutableID

    Windows Azur AD kræver, at du vælger et entydigt id for hver bruger i din brugermappe. Du skal også konfigurere Shibboleth til at sende denne attribut ved hvert organisationsnetværkslogon til Windows Azure AD i SAML 2.0 NameID-assertion. Dette id må ikke ændres for denne bruger i den tid, brugeren er i systemet. Tjenesten Windows Azure AD kalder denne attribut "ImmutableID". Værdien for det entydige id må ikke indeholde domæneoplysninger og skelner mellem store og små bogstaver.

    Undgå f.eks. at bruge user@contoso.com. I den anbefalede kode herunder vil den anvendte værdi være den Active Directory objectGUID-egenskab, der er base64-kodet. Når du opretter konti, skal du sørge for, at ImmutableID behandles på samme måde. Ellers vil brugeren ikke kunne logge på Microsoft-skytjenesten. Værkøjet Microsoft Online Services – Katalogsynkronisering anvender automatisk Active Directory objectGUID til værdien ImmutableID og behandler ImmutableID på samme måde som i det følgende anbefalede eksempel:

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

    Vigtigt

    Opdatere LDAP Data Connector i attributten resolver.xml for at angive objectGUID som en binær.

    Sørg for at føje denne linje til din LDAP-dataforbindelsespost. Det sikrer, at objectGUID behandles korrekt og er base64-kodet.

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

    Eksempel:

    <!-- ========================================== -->
<!--      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 Azur AD bruger-id

    Windows Azure AD kræver, at Windows Azure AD-bruger-id'et, f.eks. joe@contoso.com, sendes ved hjælp af den brugerdefinerede post, sådan som beskrevet i eksemplet herunder. I dette eksempel gemmes værdien i attributten LDAP- attributten 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>

Konfigurere Shibboleth-attributfilteret

Shibboleth-identitetsudbyderen skal være konfigureret til at frigive de påkrævede attributter til Windows Azur AD. Tilføj følgende tekst i filen IDP_HOME/conf/attribute-filter.xml for at frigøre attributterne til Windows Azure AD.

De indstillinger, der er vist her, frigør kun de krævede attributter til Windows Azure AD- og Windows Live-tjenester. Indstillingerne bruger specifikke AttributeFilterPolicy-id'er til at angive, at attributterne er påkrævet af 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>

Valgfri: Installere Shibboleth ECP-udvidelse

Selvom det er et valgfrit trin, anbefales det, at det udføres. Hvis du bruger Shibboleth som STS, skal du sørge for at installere Shibboleth ECP-udvidelsen, så enkeltlogon kan fungere med en smartphone, Microsoft Outlook eller andre klienter.

Forbedret klient/proxy (ECP)-udvidelsen er inkluderet i Shibboleth 2.3.3 og nyere versioner. Du kan downloade og installere ECP-udvidelse til en tidligere version af Shibboleth 2.x. Du kan finde flere oplysninger under: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Shibboleth Identity Provider ECP-udvidelsen giver dig mulighed for at integrere computer-e-mail-programmer med Windows Azure AD. Denne udvidelse implementerer SAML 2.0 ECP-specifikationen. Når du konfigurerer enkeltlogon med Windows Azure AD, kan du angive URL-adressen for ECP-udvidelsen, f.eks. https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Shibboleth ECP-udvidelsen godkendelse er i øjeblikket begrænset til basisgodkendelse.

Genstarte Shibboleth, og kontrollere funktionaliteten

Stop og start Apache Tomcat for at genstarte Shibboleth-identitetsudbyderen, og kontrollér, at de opdaterede XML-filer indlæses. Shibboleth starter muligvis ikke, hvis der er et problem med en eller flere af konfigurationsfilerne. Kontrollér Shibboleth-logfilerne efter genstart for at sikre, at ingen fejl er rapporteret. Det anbefales også, at du prøver at logge på og åbne få adgang til en tidligere konfigureret Shibboleth-tjenesteudbyder på dit netværk.

Bemærk

Kontrollér, at uret på Shibboleth-serveren synkroniseres med en nøjagtig tidskilde. Et unøjagtigt klokkeslæt kan resultere i, at organisationsnetværkslogon mislykkes.

Se også

Koncepter

Brug af identitetsprovideren Shibboleth til at implementere enkeltlogon