Konfigurera Shibboleth för enkel inloggning

  • Artikel

Utgivet: juni 2012

Gäller för: Office 365, Windows Azure Active Directory, Windows Intune

Anteckning

Det här avsnittet innehåller onlinehjälp som gäller flera Microsoft-molntjänster, däribland Windows Intune och Office 365.

Det här avsnittet innehåller detaljerade instruktioner om hur du konfigurerar Shibboleth Identity Provider för federering med Windows Azure AD och på så sätt möjliggör åtkomst med enkel inloggning till en eller flera Microsoft-molntjänster (till exempel Windows Intune och/eller Office 365) via protokollet SAML 2.0. Den förlitande SAML 2.0-part för en Microsoft-molntjänst som används i det här scenariot är Windows Azure AD.

Viktigt

I det här scenariot för enkel inloggning stöds endast en begränsad uppsättning klienter, enligt följande:

  • Webbaserade klienter som Exchange Web Access och SharePoint Online

  • Tjocka e-postklienter som använder grundläggande autentisering och en Exchange-åtkomstmetod som stöds, t.ex. IMAP, POP, Active Sync, MAPI osv. (ECP-slutpunkten (Enhanced Client Protocol) måste ha distribuerats), exempelvis:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 och 9

    • iPhone (olika iOS-versioner)

    • Windows Phone 7

Inga andra klienter stöds i det här scenariot för enkel inloggning med Shibboleth Identity Provider. Exempelvis stöds inte Lync 2010-skrivbordsklienten för inloggning i tjänsten med Shibboleth Identity Provider konfigurerat för enkel inloggning.

Viktigt

Innan du kan slutföra några av stegen i den här avsnittet för att konfigurera Shibboleth Identity Provider för enkel inloggning måste du läsa igenom och följa instruktionerna i Förbereda för enkel inloggning.

Allmän information om enkel inloggning finns i Översikt över enkel inloggning.

Om du vill konfigurera Shibboleth Identity Provider för att användas med enkel inloggning gör du följande:

  1. Lägga till Windows Azure AD-metadata

  2. Lägga till Windows Azure AD som en förlitande part

  3. Konfigurera attributmatcharen för Shibboleth

  4. Konfigurera attributfiltret för Shibboleth

  5. Valfritt: Installera ECP-tillägget för Shibboleth

  6. Starta om Shibboleth och kontrollera funktionen

Viktigt

I exemplen i det här avsnittet är IDP_HOME den baskatalog där du har installerat Shibboleth Identity Provider, till exempel c:\shibboleth2idp. När du följer instruktionerna i det här avsnittet för att konfigurera Shibboleth ska du byta ut IDP_HOME mot din egen sökväg.

Lägga till Windows Azure AD-metadata

Shibboleth Identity Provider behöver information om den förlitande Windows Azure AD-parten. Windows Azure AD publicerar metadata på https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Du rekommenderas att alltid söka efter senaste Windows Azure AD-metadata. Detta är det aktuella värdet för metadata:

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

Om du vill lägga till Windows Azure AD-metadata i Shibboleth Identity Provider kan du använda Filesystem Metadata Provider-metoden – du kan manuellt hämta och spara Windows Azure AD-metadata i en fil i mappen IDP_HOME/metadata.

Viktigt

I exemplen i det här avsnittet är IDP_HOME den baskatalog där du har installerat Shibboleth Identity Provider, till exempel c:\shibboleth2idp. När du följer instruktionerna i det här avsnittet för att konfigurera Shibboleth ska du byta ut IDP_HOME mot din egen sökväg.

Lägga till Windows Azure AD som en förlitande part

Du måste aktivera kommunikation mellan Shibboleth Identity Provider och Windows Azure AD genom att definiera ett nytt RelyingParty-element i filen IDP_Home/conf/relying-party.xml. Windows Azure AD kräver att standardinställningarna ändras för saml:SAML2Profile i DefaultRelyingParty-elementet.

Infoga följande text efter DefaultRelyingParty-elementet och kontrollera att värdet för RelyingParty id motsvarar värdet för entityID som du angav i Lägga till Windows Azure AD-metadata, till exempel "urn:federation:MicrosoftOnline". Kontrollera också att värdet för provider motsvarar EntityID för den Shibboleth Identity Provider som har angetts i DefaultRelyingParty-elementet, som i följande exempel:

<!-- 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åste dessutom ange för Shibboleth Identity Provider var filen som innehåller Windows Azure AD-metadata finns, till exempel IDP_HOME/metadata/wlid-metadata.xml. Det gör du genom att lägga till en post i filen IDP_Home/conf/relying-party.xml i MetadataProvider-noden, som i följande exempel:

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

Konfigurera attributmatcharen för Shibboleth

Windows Azure AD kräver två datablock från Shibboleth Identity Provider för att kunna hitta skuggkontot på autentiseringsplattformen. Informera Shibboleth om de här kraven genom att lägga till följande poster i filen IDP_HOME/conf/attribute-resolver.xml:

  • Windows Azure AD ImmutableID

    Windows Azure AD kräver att du väljer en unik identifierare för varje användare i användarkatalogen. Du måste även konfigurera Shibboleth så att det här attributet skickas vid varje federerad inloggning i Windows Azure AD i samband med SAML 2.0 NameID-kontrollen. Den här identifieraren får inte ändras för användaren under hela den tid som användaren finns i systemet. I Windows Azure AD-tjänsten kallas det här attributet för ImmutableID. Värdet för den unika identifieraren får inte innehålla domäninformation och det är skiftlägeskänsligt.

    Exempelvis ska du inte använda namn@contoso.com. I den rekommenderade koden nedan blir det värde som används den objectGUID-egenskap för Active Directory som är base64-kodad. När du skapar konton måste du se till att ImmutableID bearbetas på samma sätt, annars kommer användaren inte att kunna logga in i Microsoft-molntjänsten. I katalogsynkroniseringsverktyget för Microsoft Online Services används objectGUID för Active Directory automatiskt som värde för ImmutableID och ImmutableID bearbetas på samma sätt som i följande rekommenderade exempel:

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

    Viktigt

    Uppdatera LDAP-dataanslutningen i attribute-resolver.xml så att objectGUID anges som binary.

    Kom ihåg att lägga till den här raden i din LDAP-dataanslutningspost. Den ser till att objectGUID hanteras korrekt och blir base64-kodad.

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

    Exempel:

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

  • Användar-ID för Windows Azure AD

    Windows Azure AD kräver att användar-ID:t för Windows Azure AD, exempelvis joe@contoso.com, skickas med hjälp av den anpassade post som beskrivs i exemplet nedan. I det här exemplet lagras värdet i userPrincipalName-attributet för LDAP.

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

Konfigurera attributfiltret för Shibboleth

Shibboleth Identity Provider måste konfigureras för frigöra de obligatoriska attributen för Windows Azure AD. Lägg till följande text i filen IDP_HOME/conf/attribute-filter.xml för att frigöra attributen för Windows Azure AD.

Inställningarna som visas här frigör endast de obligatoriska attributen för tjänsterna Windows Azure AD och Windows Live. I inställningarna används specifika AttributeFilterPolicy-ID:n för att ange vilka attribut som krävs 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>

Valfritt: Installera ECP-tillägget för Shibboleth

Det här steget är valfritt, men rekommenderas. Om du använder Shibboleth som STS måste du installera ECP-tillägget Shibboleth Identity Provider så att enkel inloggning fungerar med en Smartphone, Microsoft Outlook och andra klienter.

ECP-tillägget (Enhanced Client/Proxy) ingår i Shibboleth 2.3.3 och senare. Med tidigare versioner av Shibboleth 2.x kan du hämta och installera ECP-tillägget. Mer information finns i https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Med ECP-tillägget för Shibboleth Identity Provider kan du aktivera integrering av skrivbordsprogram för e-post med Windows Azure AD. Med det här tillägget implementeras ECP-specifikationen för SAML 2.0. När du konfigurerar enkel inloggning med Windows Azure AD kan du ange URL-adressen för ECP-tillägget, till exempel https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Autentiseringen för ECP-tillägget för Shibboleth är för närvarande begränsad till grundläggande autentisering.

Starta om Shibboleth och kontrollera funktionen

Stoppa och starta Apache Tomcat för att starta om Shibboleth Identity Provider och kontrollera att de uppdaterade XML-filerna läses in. Shibboleth kanske inte startar problem har uppstått med en eller flera av konfigurationsfilerna. Kontrollera loggfilerna för Shibboleth efter omstarten för att kontrollera att inga fel har rapporterats. Du rekommenderas även att försöka logga in och komma åt en tidigare konfigurerad Shibboleth-tjänstleverantör i nätverket.

Anteckning

Kontrollera att klockan på din Shibboleth-server har synkroniserats med en korrekt tidkälla. En felaktig klocktid kan göra så att federerade inloggningar misslyckas.

Se även

Koncept

Använda Shibboleth Identity Provider för att implementera enkel inloggning