Konfigurace poskytovatele identit Shibboleth pro použití s jednotným přihlašováním

Publikováno: červen 2012

Platí pro: Office 365, Windows Azure Active Directory, Windows Intune

V tomto tématu naleznete podrobné pokyny ke konfiguraci poskytovatele identit Shibboleth za účelem federace se službou Windows Azure AD, aby bylo možné povolit přístup prostřednictvím jednotného přihlašování ke cloudovým službám společnosti Microsoft (například Windows Intune nebo Office 365) pomocí protokolu SAML 2.0. Předávající stranou SAML 2.0 pro cloudovou službu společnosti Microsoft používanou v tomto scénáři je služba Windows Azure AD.

Pokud budete chtít nakonfigurovat poskytovatele identit Shibboleth na používání jednotného přihlašování, proveďte následující kroky:

1. Přidání metadat služby Windows Azure AD

2. Přidání služby Windows Azure AD jako předávající strany

3. Konfigurace řešitele atributů Shibboleth

4. Konfigurace filtru atributů Shibboleth

5. Volitelné: Instalace rozšíření ECP poskytovatele identit Shibboleth

6. Restartování poskytovatele identit Shibboleth a ověření funkčnosti

Přidání metadat služby Windows Azure AD

Poskytovatel identit Shibboleth potřebuje informace o předávající straně služby Windows Azure AD. Služba Windows Azure AD publikuje metadata zde: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Doporučujeme vždy zkontrolovat nejnovější metada služby Windows Azure AD. Zde je aktuální hodnota metadat:

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

Chcete-li přidat metadata služby Windows Azure AD do poskytovatele identit Shibboleth, můžete použít metodu Filesystem Metadata Provider – můžete ručně stáhnout a uložit metadata služby Windows Azure AD do souboru ve složce IDP_HOME/metadata.

Přidání služby Windows Azure AD jako předávající strany

Je nutné povolit komunikaci mezi poskytovatelem identit Shibboleth a službou Windows Azure AD, a to nadefinováním nového elementu RelyingParty v souboru IDP_Home/conf/relying-party.xml. Služba Windows Azure AD vyžaduje změny výchozího nastavení saml:SAML2Profile v elementu DefaultRelyingParty.

Vložte následující text za element DefaultRelyingParty a zajistěte, aby hodnota RelyingParty id odpovídala hodnotě entityID, kterou jste zadali v části Přidání metadat služby Windows Azure AD, například "urn:federation:MicrosoftOnline". Také zajistěte, aby hodnota provider odpovídala identifikátoru EntityID vašeho poskytovatele identit Shibboleth zadanému v elementu DefaultRelyingParty, jak je vidět v následujícím příkladu:

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

Je nutné, abyste také pro poskytovatele identit Shibboleth určili, kde lze najít soubor obsahující metadata služby Windows Azure AD, například IDP_HOME/metadata/wlid-metadata.xml. Můžete to provést tak, že přidáte položku do souboru IDP_Home/conf/relying-party.xml v uzlu MetadataProvider, jak je vidět v následujícím příkladu:

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

Konfigurace řešitele atributů Shibboleth

Služba Windows Azure AD vyžaduje od poskytovatele identit Shibboleth dva druhy dat, aby bylo možné najít stínový účet v rámci ověřovací platformy. Informujte poskytovatele identit Shibboleth o těchto požadavcích tak, že do souboru IDP_HOME/conf/attribute-resolver.xml přidáte následující položky:

• Windows Azure AD ImmutableID

  Služba Windows Azure AD vyžaduje, abyste vybrali jedinečný identifikátor pro každého uživatele ve svém adresáři uživatelů. Poskytovatele identit Shibboleth je také nutné nakonfigurovat tak, aby odesílal tento atribut u každého federovaného přihlášení ke službě Windows Azure AD ve výrazu SAML 2.0 NameID. Tento identifikátor se pro tohoto uživatele za celou dobu existence uživatele ve vašem systému nesmí změnit. V rámci služby Windows Azure AD se tento atribut nazývá ImmutableID. Hodnota jedinečného identifikátoru nesmí obsahovat informace o doméně a rozlišují se u ní malá a velká písmena.

  Nepoužívejte například hodnotu user@contoso.com. V níže uvedeném doporučeném kódu bude použitou hodnotou vlastnost Active Directory objectGUID v kódování base64. Při vytváření účtů je nutné zajistit, aby bylo ImmutableID zpracováno stejným způsobem, v opačném případě se uživatel nebude moci přihlásit ke cloudové službě společnosti Microsoft. Nástroj pro synchronizaci adresáře služeb Microsoft Online Services automaticky používá Active Directory objectGUID pro hodnotu ImmutableID a zpracovává ImmutableID stejným způsobem jako v následujícím doporučeném příkladu:

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

  Důležité

  Aktualizujte LDAP Data Connector v souboru attribute-resolver.xml – zadejte objectGUID jako binární objekt.

  Nezapomeňte přidat tento řádek do své položky LDAP Data Connector. Tím bude zajištěno, že bude identifikátor objectGUID zpracován správně a bude v kódování base64.

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

  Například:

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

  Služba Windows Azure AD vyžaduje, aby ID uživatele (User ID) služby Windows Azure AD, například joe@contoso.com, bylo odesláno pomocí vlastní položky, jak je popsáno v následujícím příkladu. V tomto příkladu je hodnota uložena v atributu LDAP 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> 
  

Konfigurace filtru atributů Shibboleth

Poskytovatel identit Shibboleth musí být nakonfigurován tak, aby uvolňoval požadované atributy pro službu Windows Azure AD. Přidejte následující text do souboru IDP_HOME/conf/attribute-filter.xml, aby byly atributy uvolněny pro službu Windows Azure AD.

Nastavení, které se zobrazuje zde, uvolňuje požadované atributy pouze pro službu Windows Azure AD a pro služby Windows Live. Nastavení používá specifická ID AttributeFilterPolicy k označení atributů požadovaných službou 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>

Volitelné: Instalace rozšíření ECP poskytovatele identit Shibboleth

Přestože je tento krok volitelný, doporučujeme ho provést. Pokud jako svoje služby STS používáte poskytovatele identit Shibboleth, nezapomeňte nainstalovat rozšíření ECP poskytovatele identit Shibboleth, aby jednotné přihlašování fungovalo se smartphonem, aplikací Microsoft Outlook a dalšími klienty.

Rozšíření ECP (enhanced client/proxy) je součástí poskytovatele identit Shibboleth 2.3.3 a vyšší verze. V případě předchozí verze poskytovatele identit Shibboleth 2.x si můžete rozšíření ECP stáhnout a nainstalovat. Další informace naleznete zde: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Rozšíření ECP poskytovatele identit Shibboleth vám umožní do služby Windows Azure AD integrovat e-mailové aplikace klasické pracovní plochy. Toto rozšíření implementuje specifikaci SAML 2.0 ECP. Při konfiguraci jednotného přihlašování pro službu Windows Azure AD můžete pro rozšíření ECP zadat adresu URL, například https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Ověřování rozšíření ECP Shibboleth je aktuálně omezeno na základní ověřování.

Restartování poskytovatele identit Shibboleth a ověření funkčnosti

Zastavte a potom znovu spusťte Apache Tomcat za účelem restartování poskytovatele identit Shibboleth a zajistěte, aby byly načteny aktualizované soubory XML. Poskytovatele identit Shibboleth se nemusí podařit spustit, pokud dojde k potížím s některými konfiguračními soubory. Po restartování zkontrolujte v souborech protokolů Shibboleth, že nejsou hlášeny žádné chyby. Také doporučujeme zkusit se přihlásit a získat přístup k dříve nakonfigurovanému poskytovateli služeb Shibboleth ve vaší síti.

Viz také

Koncepty

Implementace jednotného přihlášení pomocí poskytovatele identit Shibboleth