Shibboleth konfigurálása az egyszeri bejelentkezéshez

Közzétéve: 2012. június

Hatókör: Office 365, Windows Azure Active Directory, Windows Intune

Ez a témakör részletes utasításokat tartalmaz arról, hogy miként lehet konfigurálni a Shibboleth identitásszolgáltatót a Windows Azure AD szolgáltatással való összevonáshoz, hogy lehetővé tegye az egyszeri bejelentkezéssel történő hozzáférést egy vagy több Microsoft-felhőszolgáltatáshoz (például, Windows Intune és/vagy Office 365) a SAML 2.0 protokollal. Ebben a forgatókönyvben a Microsoft-felhőszolgáltatáshoz használt SAML 2.0 függő entitás a Windows Azure AD.

A Shibboleth identitásszolgáltató konfigurálásához egyszeri bejelentkezéssel történő használatra, végezze el az alábbi lépéseket:

1. Windows Azure AD-metaadatok hozzáadása

2. Windows Azure AD hozzáadása függő entitásként

3. A Shibboleth attribútumfeloldó konfigurálása

4. A Shibboleth attribútumszűrő konfigurálása

5. Választható: A Shibboleth ECP bővítmény telepítése

6. A Shibboleth újraindítása és működésének ellenőrzése

Windows Azure AD-metaadatok hozzáadása

A Shibboleth identitásszolgáltatónak információkra van szüksége a Windows Azure AD függő entitásról. A Windows Azure AD a metaadatokat ezen a helyen teszi közzé: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Ajánlott, hogy midig keresse meg a legújabb Windows Azure AD-metaadatokat. A metaadatok aktuális értéke az alábbi:

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

A Windows Azure AD metaadatainak a Shibboleth identitásszolgáltatóhoz történő hozzáadásához használhatja a fájlrendszer metaadat-szolgáltatója módszert – letöltheti a Windows Azure AD-metaadatokat, és tárolhatja azokat egy fájlban az IDP_HOME/metadata mappában.

Windows Azure AD hozzáadása függő entitásként

Engedélyeznie kell a Shibboleth identitásszolgáltató és a Windows Azure AD közötti kommunikációt egy új RelyingParty elem IDP_Home/conf/relying-party.xml fájlban történő meghatározásával. A Windows Azure AD számára módosítani kell az saml:SAML2Profile alapértelmezett beállításait a DefaultRelyingParty elemben.

Illessze be a következő szöveget a DefaultRelyingParty elem után, és győződjön meg arról, hogy a RelyingParty id érték megegyezik azzal az entityID értékkel, amelyet a Windows Azure AD-metaadatok hozzáadása című szakaszban meghatározott, például, "urn:federation:MicrosoftOnline". Arról is győződjön meg, hogy a provider megadott értéke megegyezik a DefaultRelyingParty elemben megadott Shibboleth identitásszolgáltató EntityID értékével, az alábbi példának megfelelően:

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

Azt is meg kell adnia a Shibboleth identitásszolgáltató számára, hogy hol található a Windows Azure AD metaadatait tartalmazó fájl, például, IDP_HOME/metadata/wlid-metadata.xml. Ezt megteheti egy bejegyzés hozzáadásával az IDP_Home/conf/relying-party.xml fájlhoz, a MetadataProvider csomópontban, az alábbi példának megfelelően:

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

A Shibboleth attribútumfeloldó konfigurálása

A Windows Azure AD szolgáltatásnak két adatra van szüksége a Shibboleth identitásszolgáltatótól az árnyékfiók megkereséséhez a hitelesítési platformon. Tudassa a Shibboleth identitásszolgáltatót ezekről a követelményekről az alábbi bejegyzések hozzáadásával az IDP_HOME/conf/attribute-resolver.xml fájlhoz:

• Windows Azure AD ImmutableID

  A Windows Azure AD számára szükséges, hogy egyedi azonosítót válasszon a felhasználói címtár minden felhasználójához. A Shibboleth identitásszolgáltatót pedig úgy kell konfigurálnia, hogy elküldje ezt az attribútumot minden összevont bejelentkezés alkalmával a Windows Azure AD szolgáltatásnak az SAML 2.0 NameID helyességi feltételben. Ennek az azonosítónak nem szabad megváltoznia, amíg a felhasználó a rendszerben van. A Windows Azure AD szolgáltatásban ennek az attribútumnak „ImmutableID” a neve. Az egyedi azonosító értéke nem tartalmazhat tartományadatokat, és a rendszer megkülönbözteti a kis- és nagybetűket.

  Ne használja például a user@contoso.com értéket. Az alábbi ajánlott kódban használt érték az Active Directory objectGUID tulajdonsága, amely base64 kódolású. Fiókok létrehozásakor az ImmutableID értékét ugyanazon a módon kell feldolgozni, különben a felhasználó nem fog tudni bejelentkezni a Microsoft-felhőszolgáltatásba. A Microsoft Online Services – Címtár-szinkronizáló eszköz automatikusan az Active Directory objectGUID értékét használja az ImmutableID értékeként, és az ImmutableID feldolgozásához ugyanazt a módszert használja, mint az alábbi ajánlott példa:

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

  Fontos

  Frissítse az LDAP Data Connector értékét az attribute-resolver.xml fájlban az objectGUID bináris értékként történő megadásához.

  Adja hozzá ezt a sort az LDAP Data Connector bejegyzéséhez, ez biztosítja az objectGUID helyes kezelését, és hogy base64 kódolású legyen.

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

  Példa:

  <!-- ========================================== -->
  <!--      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 felhasználói azonosító

  A Windows Azure AD számára szükséges, hogy a Windows Azure AD felhasználói azonosítóját, például, joe@contoso.com, az alábbi példában ismertetett testre szabott bejegyzéssel küldjék. Ebben a példában az értéket az LDAP userPrincipalName attribútum tárolja.

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

A Shibboleth attribútumszűrő konfigurálása

A Shibboleth identitásszolgáltatót konfigurálni kell, hogy a kibocsássa a szükséges attribútumokat a Windows Azure AD számára. Az attribútumok Windows Azure AD számára történő kibocsátásához adja hozzá az alább szöveget az IDP_HOME/conf/attribute-filter.xml fájlhoz.

Az itt bemutatott beállítások a kívánt attribútumokat csak a Windows Azure AD és a Windows Live szolgáltatások számára bocsátják ki. A beállítások meghatározott AttributeFilterPolicy-azonosítókat használnak annak jelzésére, hogy az attribútumokra a Windows Azure AD szolgáltatásnak van szüksége.

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

Választható: A Shibboleth ECP bővítmény telepítése

Annak ellenére, hogy ez a lépés nem kötelező, ajánlott megtenni. Ha biztonsági jegykiadó szolgáltatásként (STS) a Shibboleth szolgáltatót használja, feltétlenül telepítse a Shibboleth identitásszolgáltató ECP bővítményét, hogy az egyszeri bejelentkezés működjön okostelefonokkal, a Microsoft Outlook ügyféllel és más ügyfelekkel.

Az kibővített ügyfél/proxy (enhanced client/proxy – ECP) bővítményt a Shibboleth 2.3.3 és újabb verziói tartalmazzák. A Shibboleth 2.x régebbi verzióihoz az ECP bővítményt letöltheti és telepítheti. További információk: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

A Shibboleth identitásszolgáltató ECP bővítménye lehetővé teszi az asztali e-mail alkalmazások integrálását a Windows Azure AD szolgáltatással. Ez a bővítmény az SAML 2.0 ECP specifikációt alkalmazza. Amikor konfigurálja az egyszeri bejelentkezést a Windows Azure AD szolgáltatáshoz, megadhatja az ECP bővítmény URL-címét, például, https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. A Shibboleth ECP bővítménnyel végzett hitelesítés jelenleg alapszintű hitelesítésre korlátozott.

A Shibboleth újraindítása és működésének ellenőrzése

Állítsa le, majd indítsa újra az Apache Tomcat kiszolgálót a Shibboleth identitásszolgáltató újraindításához, és győződjön meg arról, hogy a frissített XML-fájlok betöltődtek. Előfordulhat, hogy a Shibboleth nem indul el, ha probléma adódott egy vagy több konfigurációs fájllal. Újraindítás után ellenőrizze a Shibboleth naplófájljait, hogy nem tartalmaznak-e jelentést hibákról. Továbbá javasoljuk, hogy próbáljon bejelentkezni egy korábban konfigurált Shibboleth-szolgáltatóba és elérni azt a hálózatán.

Lásd még

Fogalmak

a Shibboleth identitásszolgáltató használata az egyszeri bejelentkezés megvalósításához