Sdílet prostřednictvím

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

  • Článek

Aktualizováno: 25. června 2015

Platí pro: Azure, Office 365, Power BI, Windows Intune

Toto téma obsahuje podrobné pokyny ke konfiguraci zprostředkovatele identity Shibboleth pro federování pomocí Azure AD pro povolení jednotného přihlašování k jedné nebo více cloudovým službám Microsoftu (například Microsoft Intune nebo Office 365) pomocí protokolu SAML 2.0. Předávající strana SAML 2.0 pro cloudovou službu Microsoftu používaná v tomto scénáři je Azure AD.

Důležité

V tomto scénáři jednotného přihlašování se podporuje pouze omezená sada klientů:

  • Webové klienty, jako jsou Exchange Web Access a SharePoint Online

  • Klienti s bohatými e-maily, kteří používají základní ověřování a podporovanou metodu přístupu Exchange, jako je IMAP, POP, Active Sync, MAPI atd. (koncový bod rozšířeného klientského protokolu se vyžaduje k nasazení), včetně:

    • Microsoft Outlook 2007

    • Microsoft® Outlook® 2010

    • Thunderbird 8 a 9

    • IPhone (různé verze iOS)

    • Windows Phone 7

Všichni ostatní klienti nejsou v tomto scénáři jednotného přihlašování podporováni pomocí zprostředkovatele identity Shibboleth.  Desktopový klient Lyncu 2010 se například nepodporuje pro přihlášení ke službě pomocí zprostředkovatele identity Shibboleth nakonfigurovaného pro jednotné přihlašování.

Důležité

Před dokončením některého z kroků v tomto tématu pro konfiguraci zprostředkovatele identity Shibboleth pro jednotné přihlašování musíte zkontrolovat a postupovat podle pokynů uvedených v tématu Příprava jednotného přihlašování.

Obecné informace o jednotném přihlašování najdete v plánu jednotného přihlašování.

Pokud chcete nakonfigurovat zprostředkovatele identity Shibboleth pro použití s jednotným přihlašováním, proveďte následující kroky:

  1. Přidání metadat Azure AD

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

  3. Konfigurace překladače atributů Shibboleth

  4. Konfigurace filtru atributů Shibboleth

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

  6. Restartujte Shibboleth a ověřte funkčnost.

Důležité

V příkladech v tomto tématu je IDP_HOME základním adresářem, ve kterém jste nainstalovali zprostředkovatele identity Shibboleth, například c:\shibboleth2idp. Při konfiguraci Shibboleth postupujte podle pokynů v tomto tématu, nezapomeňte nahradit IDP_HOME konkrétní cestou.

Přidání metadat Azure AD

Zprostředkovatel identity Shibboleth potřebuje informace o Azure AD předávající straně. Azure AD publikuje metadata na adrese https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Doporučujeme vždy vyhledat nejnovější metadata Azure AD. Tady 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>

Pokud chcete přidat metadata Azure AD do zprostředkovatele identity Shibboleth, můžete použít metodu zprostředkovatele metadat systému souborů – můžete ručně stáhnout a uložit Azure AD metadata do souboru ve složce IDP_HOME/metadata.

Důležité

V příkladech v tomto tématu je IDP_HOME základním adresářem, ve kterém jste nainstalovali zprostředkovatele identity Shibboleth, například c:\shibboleth2idp. Při konfiguraci Shibboleth postupujte podle pokynů v tomto tématu, nezapomeňte nahradit IDP_HOME konkrétní cestou.

Přidání Azure AD jako předávající strany

Musíte povolit komunikaci mezi zprostředkovatelem identity Shibboleth a Azure AD definováním nového elementu RelyingParty v souboru IDP_Home/conf/relying-party.xml. 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 ujistěte se, že hodnota ID RelyingParty odpovídá hodnotě ENTITYID, kterou jste zadali v metadatech přidat Azure AD, například "urn:federation:MicrosoftOnline". Ujistěte se také, že hodnota poskytovatele odpovídá EntityID vašeho zprostředkovatele identity Shibboleth zadaného v elementu DefaultRelyingParty , jak je znázorněno v následujícím příkladu:

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

Musíte také zadat Zprostředkovatele identity Shibboleth, kde najít soubor, který obsahuje metadata Azure AD, například IDP_HOME/metadata/windows-azure-ad-metadata.xml. Můžete to provést přidáním položky do souboru IDP_Home/conf/relying-party.xml v uzlu MetadataProvider , jak je znázorněno v následujícím příkladu:

<!—- 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 překladače atributů Shibboleth

Azure AD vyžaduje dva části dat zprostředkovatele identity Shibboleth k vyhledání stínového účtu v ověřovací platformě. Chcete-li informovat Shibboleth o těchto požadavcích, přidejte do souboru IDP_HOME/conf/attribute-resolver.xml následující položky:

  • Azure AD ImmutableID

    Azure AD vyžaduje, abyste pro každého uživatele v adresáři uživatelů vybrali jedinečný identifikátor. Musíte také nakonfigurovat Shibboleth tak, aby tento atribut odeslal na každé federované přihlášení do Azure AD v kontrolním výrazu SAML 2.0 NameID. Tento identifikátor nesmí být pro tohoto uživatele v průběhu životnosti uživatele ve vašem systému změněn. Služba Azure AD volá tento atribut ImmutableID. Hodnota jedinečného identifikátoru nesmí obsahovat informace o doméně a rozlišují se malá a velká písmena.

    Například nepoužívejte user@contoso.com. V následujícím doporučeném kódu bude použitá hodnota vlastnost Active Directory objectGUID, která je kódována base64. Při vytváření účtů je nutné zajistit, aby se immutableID zpracovával stejným způsobem, nebo se uživatel nebude moct přihlásit ke cloudové službě Microsoftu. Nástroj Microsoft Azure Active Directory Sync automaticky používá ID objektu služby Active Directory 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 datový konektor LDAP v attribute-resolver.xml tak, aby zadal objectGUID jako binární soubor.

    Nezapomeňte přidat tento řádek do položky datového konektoru LDAP, tím zajistíte, že objektGUID je zpracován správně a je kódován base64.

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

    Pří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>

  • ID uživatele Azure AD

    Azure AD vyžaduje, aby se id joe@contoso.comuživatele Azure AD například odeslalo 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 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

Zprostředkovatel identity Shibboleth musí být nakonfigurovaný tak, aby uvolnil požadované atributy pro Azure AD. Do souboru IDP_HOME/conf/attribute-filter.xml přidejte následující text, který uvolní atributy Azure AD.

Nastavení, která jsou zde zobrazena, uvolní požadované atributy pouze pro služby Azure AD a Windows Live. Nastavení používají konkrétní ID AtributFilterPolicy k označení atributů jsou vyžadovány Azure AD.

<!-- Attribute Filter Policy for Azure AD -->
<afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline" />

<!-- Release userPrincipalName as Azure AD User ID -->
      <afp:AttributeRule attributeID="UserId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Release Immutable ID to Azure AD -->
      <afp:AttributeRule attributeID="ImmutableID">
          <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>

<!-- Note: it is not recommended to send transientId to Azure AD -->
<afp:AttributeRule attributeID="transientId">
   <afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>

</afp:AttributeFilterPolicy>

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

I když je to volitelný, jedná se o doporučený krok. Pokud jako stS používáte Shibboleth, nezapomeňte nainstalovat rozšíření ECP zprostředkovatele identity Shibboleth, aby jednotné přihlašování fungovalo s inteligentním telefonem, Microsoft Outlook nebo jinými klienty.

Rozšířené rozšíření klienta a proxy serveru (ECP) je součástí Shibboleth 2.3.3 a novější. Pro starší verzi Shibboleth 2.x si můžete stáhnout a nainstalovat rozšíření ECP. Další informace najdete v tématu: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Rozšíření ECP zprostředkovatele identity Shibboleth umožňuje povolit integraci desktopových e-mailových aplikací s Azure AD. Toto rozšíření implementuje specifikaci SAML 2.0 ECP. Při konfiguraci jednotného přihlašování pomocí Azure AD můžete zadat adresu URL rozšíření ECP, například https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Ověřování rozšíření Shibboleth ECP je v současné době omezené na základní ověřování.

Pokud jste se rozhodli nainstalovat rozšíření Shibboleth ECP, proveďte následující kroky:

  1. Do místního souboru metadat Azure AD umístěného v IDP_HOME/metadata přidejte následující kód:

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>

  2. Přidejte položku saml:SAML2ECPProfile do konfiguračního uzlu Azure AD RelyingParty v relying-party.xml umístěném v IDP_HOME/config:

    <rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="https://idp.contoso.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">  
                <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
                                signAssertions="conditional" 
                                encryptAssertions="never"                          
                                encryptNameIds="never" />                                                      
                <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile"                                                           
                                signAssertions="always"                  
                                encryptAssertions="never"                  
                                encryptNameIds="never"/>                                                             
</rp:RelyingParty>

Restartujte Shibboleth a ověřte funkčnost.

Zastavte a spusťte Apache Tomcat a restartujte zprostředkovatele identity Shibboleth a ujistěte se, že se načtou aktualizované soubory XML. Shibboleth se nemusí spustit, pokud dojde k problému s jedním nebo více konfiguračními soubory. Zkontrolujte soubory protokolu Shibboleth po restartování a ujistěte se, že se neoznamují žádné chyby. Doporučujeme také zkusit se přihlásit a získat přístup k dříve nakonfigurovanému poskytovateli služeb Shibboleth ve vaší síti.

Poznámka

Ověřte, že se hodiny na vašem serveru Shibboleth synchronizují s přesným časovým zdrojem. Nepřesná doba hodin může způsobit selhání federovaných přihlášení.

Viz také

Koncepty

Použití zprostředkovatele identity Shibboleth k implementaci jednotného přihlašování