Konfigurere Shibboleth for bruk med enkel pålogging

  • Artikkel

Utgitt: juni 2012

Gjelder for: Office 365, Windows Azure Active Directory, Windows Intune

Obs!

Dette emnet inneholder hjelpeinformasjon som gjelder for flere Microsoft-skytjenester, inkludert Windows Intune og Office 365.

Dette emnet inneholder detaljerte instruksjoner om hvordan du konfigurerer Shibboleth-identitetsleverandøren til å opprette forbund med Windows Azure AD for å aktivere tilgang med enkel pålogging til en eller flere Microsoft-skytjenester (for eksempel Windows Intune og/eller Office 365) med SAML 2.0-protokollen. SAML 2.0-avhengighetspartneren som brukes for en Microsoft-skytjeneste i dette scenariet, er Windows Azure AD.

Viktig

Dette scenariet for enkel pålogging støtter bare et begrenset sett med klienter, som følger:

  • Nettbaserte klienter som Exchange Web Access og SharePoint Online

  • E-postrike klienter som bruker grunnleggende godkjenning og en støttet Exchange-tilgangsmetode som IMAP, POP, Active Sync, MAPI osv. (den utvidede klientprotokollens endepunkt må være distribuert), inkludert:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 og 9

    • iPhone (ulike iOS-versjoner)

    • Windows Phone 7

Ingen andre klienter støttes i dette scenariet for enkel pålogging med Shibboleth Identity Provider. Det betyr at for eksempel Lync 2010 skrivebordsklient støttes ikke for pålogging til tjenesten med Shibboleth Identity Provider konfigurert for enkel pålogging.

Viktig

Før du kan fullføre noen av trinnene i dette emnet for å konfigurere Shibboleth Identity Provider for enkel pålogging, må du lese gjennom og følge instruksjonene i Klargjøre for enkel pålogging.

Du finner generell informasjon om enkel pålogging i Veikart for enkel pålogging.

Konfigurer Shibboleth Identity Provider for bruk med enkel pålogging slik:

  1. Legge til Windows Azure AD-metadata

  2. Legge til Windows Azure AD som avhengighetspartner.

  3. Konfigurere Shibboleth attributtløser

  4. Konfigurere Shibboleth attributtfilter

  5. Valgfritt: Installere Shibboleths ECP-utvidelse

  6. Starte Shibboleth på nytt og kontrollere funksjonaliteten

Viktig

I alle eksemplene i dette emnet er IDP_HOME grunnkatalogen der du har installert Shibboleth Identity Provider, for eksempel c:\shibboleth2idp. Etter hvert som du følger instruksjonene i dette emnet for å konfigurere Shibboleth, må du huske å erstatte IDP_HOME med banen til din installasjon.

Legge til Windows Azure AD-metadata

Shibboleth Identity Provider trenger informasjon om Windows Azure AD-avhengighetspartneren. Windows Azure AD publiserer metadata på https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Vi anbefaler at du alltid passer på å bruke de nyeste Windows Azure AD-metadataene. Dette er gjeldende verdi for metadataene:

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

Når du skal legge til Windows Azure AD-metadataene i Shibboleth Identity Provider, kan du bruke metoden med filsystemets metadataleverandør og laste ned og lagre Windows Azure AD-metadataene manuelt i en fil i mappen IDP_HOME/metadatamappe.

Viktig

I alle eksemplene i dette emnet er IDP_HOME grunnkatalogen der du har installert Shibboleth Identity Provider, for eksempel c:\shibboleth2idp. Etter hvert som du følger instruksjonene i dette emnet for å konfigurere Shibboleth, må du huske å erstatte IDP_HOME med banen til din installasjon.

Legge til Windows Azure AD som avhengighetspartner.

Du må aktivere kommunikasjonen mellom Shibboleth Identity Provider og Windows Azure AD ved å definere et nytt RelyingParty-element i filen IDP_Home/conf/relying-party.xml. Windows Azure AD krever endringer i standardinnstillingene for saml:SAML2Profile i DefaultRelyingParty-elementet.

Sett inn følgende tekst etter DefaultRelyingParty-elementet, og sørg for at verdien RelyingParty id samsvarer med entityID-verdien du har angitt i Legge til Windows Azure AD-metadata, for eksempel "urn:federation:MicrosoftOnline". Kontroller også at verdien for provider stemmer overens med EntityID som er angitt for elementet DefaultRelyingParty i Shibboleth Identity Provider, som vist i dette eksemplet:

<!-- 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 må også angi i Shibboleth Identity Provider hvor filen som inneholder Windows Azure AD-metadataene, ligger, for eksempel IDP_HOME/metadata/wlid-metadata.xml. Dette kan du gjøre ved å legge til en oppføring i filen IDP_Home/conf/relying-party.xml i noden MetadataProvider, som vist i dette eksemplet:

<!—- 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 attributtløser

Windows Azure AD krever to dataelementer fra Shibboleth Identity Provider for å kunne finne skyggekontoen på godkjenningsplattformen. For å gi Shibboleth denne informasjonen, legger du til følgende oppføringer i filen IDP_HOME/conf/attribute-resolver.xml:

  • Windows Azure AD ImmutableID

    Windows Azure AD krever at du velger en unik identifikator for hver bruker i brukerkatalogen. Du må også konfigurere Shibboleth til å sende dette attributtet ved hver forbundne pålogging til Windows Azure AD i SAML 2.0 NameID-deklarasjonen. Denne identifikatoren kan ikke endres for denne brukeren så lenge brukeren ligger i systemet. Windows Azure AD-tjenesten kaller dette attributtet "ImmutableID". Verdien for denne unike identifikatoren kan ikke inneholde domeneinformasjon, og den skiller mellom store og små bokstaver.

    Du kan for eksempel ikke bruke bruker@contoso.com. I den anbefalte koden nedenfor brukes den base64-kodede objectGUID-egenskapen i Active Directory. Ved oppretting av kontoer må du sikre at ImmutableID behandles på samme måte, ellers vil brukeren ikke kunne logge seg på Microsoft-skytjenesten. Katalogsynkroniseringsverktøyet for Microsoft Online Services Directory bruker automatisk objectGUID i Active Directory som ImmutableID-verdi og behandler ImmutableID på samme måte som i eksemplet nedenfor:

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

    Viktig

    Oppdatere LDAP Data Connector i attribute-resolver.xml for å angi objectGUID som binær.

    Pass på at du legger til denne linjen i LDAP Data Connector-oppføringen. Det vil sikre at objectGUID håndteres riktig 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 Azure AD bruker-ID

    Windows Azure AD krever at Windows Azure AD bruker-ID, for eksempel jon@contoso.com, sendes ved hjelp av den egendefinerte oppføringen som beskrevet i eksemplet nedenfor. I dette eksemplet er verdien lagret i LDAP-attributtet 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 attributtfilter

Shibboleth Identity Provider må konfigureres til å frigi de nødvendige attributtene til Windows Azure AD. Legg til følgende tekst i filen IDP_HOME/conf/attribute-filter.xml for å frigi attributtene til Windows Azure AD.

Innstillingene som vises her, frigir de nødvendige attributtene bare til Windows Azure AD- og Windows Live-tjenester. Innstillingene bruker spesifikke AttributeFilterPolicy-IDer for å indikere at attributtene kreves av 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>

Valgfritt: Installere Shibboleths ECP-utvidelse

Selv om dette trinnet er valgfritt, anbefaler vi at du gjør dette. Hvis du bruker Shibboleth som STS, må du installere Shibboleth Identity Providers ECP-utvidelse for at enkel pålogging skal fungere med smarttelefoner, Microsoft Outlook eller andre klienter.

Den forbedrede klient-/proxyutvidelsen (ECP) er inkludert i Shibboleth 2.3.3 og senere. For tidligere versjoner av Shibboleth 2.x kan du laste ned og installere ECP-utvidelsen. Hvis du vil ha mer informasjon, kan du se: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Med ECP-utvidelsen for Shibboleth Identity Provider ECP kan du aktivere integrering av skrivebordsprogrammer for e-post med Windows Azure AD. Denne utvidelsen implementerer SAML 2.0 ECP-spesifikasjonen. Når du konfigurerer enkel pålogging med Windows Azure AD, kan du angi URL-adressen til ECP-utvidelsen, for eksempel https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Godkjenningen i ECP-utvidelsen for Shibboleth er for øyeblikket begrenset til grunnleggende godkjenning.

Starte Shibboleth på nytt og kontrollere funksjonaliteten

Stopp og start Apache Tomcat for å starte Shibboleth Identity Provider på nytt og kontrollere at de oppdaterte XML-filene er lastet inn. Det er mulig at Shibboleth ikke vil starte hvis det er problemer med én eller flere av konfigurasjonsfilene. Kontroller loggfilene for Shibboleth etter omstarten for å kontrollere at det ikke er rapportert om feil. Vi anbefaler også at du prøver å logge deg på og åpne en tidligere konfigurert Shibboleth-tjenesteleverandør på nettverket.

Obs!

Kontroller at klokken på Shibboleth-serveren er synkronisert med en nøyaktig tidskilde. En unøyaktig klokke kan føre til mislykkede forbundne pålogginger.

Se også

Konsepter

Bruke Shibboleth Identity Provider for å implementere enkel pålogging