Exportovat (0) Tisk
Rozbalit vše

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

Publikováno: červen 2012

Aktualizováno: únor 2013

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

notePoznámka
V tomto tématu je k dispozici obsah online nápovědy, který se vztahuje na více cloudových služeb společnosti Microsoft, včetně služby Windows Intune a služeb Office 365.

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.

ImportantDůležité
V tomto scénáři používání jednotného přihlašování je podporována pouze omezená skupina klientů, konkrétně jde o tyto:

  • Weboví klienti, například Exchange Web Access či SharePoint Online

  • Rozšíření klienti s podporou e-mailu využívající základní ověřování a podporovanou metodu přístupu k systému Exchange, například IMAP, POP, Active Sync, MAPI atd. (musí být nasazen koncový bod s rozšířeným klientským protokolem), včetně následujících:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 a 9

    • iPhone (různé verze systému iOS)

    • Windows Phone 7

Žádní jiní klienti nejsou v tomto scénáři jednotného přihlašování s poskytovatelem identit Shibboleth podporováni. Například klientská aplikace Lync 2010 klasické pracovní plochy není podporována pro přihlášení ke službě pomocí poskytovatele identit Shibboleth nakonfigurovaného pro jednotné přihlašování.

ImportantDůležité
Než pomocí některého z kroků v tomto tématu začnete konfigurovat poskytovatele identit Shibboleth na jednotné přihlašování, je potřeba, abyste si prošli pokyny v části Příprava jednotného přihlašování a postupovali přesně podle nich.

Obecné informace týkající se jednotného přihlašování naleznete v tématu Jednotné přihlašování: rozcestník.

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

ImportantDůležité
V příkladech uváděných v tomto tématu představuje IDP_HOME základní adresář, ve kterém je nainstalován poskytovatel identit Shibboleth, například c:\shibboleth2idp. Při konfiguraci poskytovatele identit Shibboleth podle postupu v tomto tématu je potřeba nahradit cestu IDP_HOME konkrétní cestou.

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.

ImportantDůležité
V příkladech uváděných v tomto tématu představuje IDP_HOME základní adresář, ve kterém je nainstalován poskytovatel identit Shibboleth, například c:\shibboleth2idp. Při konfiguraci poskytovatele identit Shibboleth podle postupu v tomto tématu je potřeba nahradit cestu IDP_HOME konkrétní cestou.

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> 
    
    
    ImportantDů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.

notePoznámka
Ověřte, že jsou hodiny na serveru Shibboleth sesynchronizovány s přesným zdrojem času. Nepřesný čas hodin může způsobovat chyby federovaných přihlášení.

Viz také

Byl tento obsah pro vás užitečný?
(Zbývající počet znaků: 1500)
Děkujeme za váš názor.

Obsah vytvořený komunitou

Přidat
Zobrazit:
© 2014 Microsoft