Udostępnij za pośrednictwem

Konfigurowanie rozwiązania Shibboleth do użycia z logowaniem jednokrotnym

  • Artykuł

Zaktualizowano: 25 czerwca 2015 r.

Dotyczy: Azure, Office 365, Power BI, Windows Intune

Ten temat zawiera szczegółowe instrukcje dotyczące konfigurowania dostawcy tożsamości Shibboleth w celu federacji z Azure AD w celu włączenia dostępu jednokrotnego do co najmniej jednej usługi w chmurze firmy Microsoft (na przykład Microsoft Intune i/lub Office 365) przy użyciu protokołu SAML 2.0. Jednostka uzależniona SAML 2.0 dla usługi w chmurze firmy Microsoft używanej w tym scenariuszu jest Azure AD.

Ważne

W tym scenariuszu logowania jednokrotnego obsługiwany jest tylko ograniczony zestaw klientów:

  • Klienci sieci Web, tacy jak Exchange Web Access i SharePoint Online

  • Klienci z obsługą poczty e-mail korzystający z uwierzytelniania podstawowego i obsługiwaną Exchange metodę dostępu, taką jak IMAP, POP, Active Sync, MAPI itp. (do wdrożenia jest wymagany rozszerzony punkt końcowy protokołu klienta), w tym:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 i 9

    • IPhone (różne wersje iOS)

    • Windows Phone 7

Wszyscy inni klienci nie są obsługiwani w tym scenariuszu logowania jednokrotnego w programie Shibboleth Identity Provider.  Na przykład klient pulpitu programu Lync 2010 nie jest obsługiwany do logowania się do usługi za pomocą dostawcy tożsamości Shibboleth skonfigurowanego do logowania jednokrotnego.

Ważne

Przed wykonaniem dowolnego z kroków opisanych w tym temacie w celu skonfigurowania programu Shibboleth Identity Provider na potrzeby logowania jednokrotnego należy zapoznać się z instrukcjami podanymi w sekcji Przygotowanie do logowania jednokrotnego.

Aby uzyskać ogólne informacje na temat logowania jednokrotnego, zobacz Plan logowania jednokrotnego.

Aby skonfigurować dostawcę tożsamości Shibboleth do użycia z logowaniem jednokrotnym, wykonaj następujące kroki:

  1. Dodawanie metadanych Azure AD

  2. Dodawanie Azure AD jako jednostki uzależnionej

  3. Konfigurowanie narzędzia rozpoznawania atrybutów Shibboleth

  4. Konfigurowanie filtru atrybutu Shibboleth

  5. Opcjonalnie: instalowanie rozszerzenia ECP Shibboleth

  6. Uruchom ponownie shibboleth i zweryfikuj funkcjonalność

Ważne

W przykładach w tym temacie IDP_HOME to katalog podstawowy, w którym zainstalowano dostawcę tożsamości Shibboleth, na przykład c:\shibboleth2idp. Zgodnie z instrukcjami w tym temacie, aby skonfigurować shibboleth, pamiętaj, aby zastąpić IDP_HOME konkretną ścieżką.

Dodawanie metadanych Azure AD

Shibboleth Identity Provider potrzebuje informacji o Azure AD jednostki uzależnionej. Azure AD publikuje metadane pod adresem https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Zaleca się, aby zawsze sprawdzać najnowsze metadane Azure AD. Oto bieżąca wartość metadanych:

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

Aby dodać metadane Azure AD do dostawcy tożsamości Shibboleth, możesz użyć metody Dostawca metadanych systemu plików — możesz ręcznie pobrać i zapisać metadane Azure AD w pliku w folderze IDP_HOME/metadata.

Ważne

W przykładach w tym temacie IDP_HOME to katalog podstawowy, w którym zainstalowano dostawcę tożsamości Shibboleth, na przykład c:\shibboleth2idp. Zgodnie z instrukcjami w tym temacie, aby skonfigurować shibboleth, pamiętaj, aby zastąpić IDP_HOME konkretną ścieżką.

Dodawanie Azure AD jako jednostki uzależnionej

Należy włączyć komunikację między dostawcą tożsamości Shibboleth a Azure AD przez zdefiniowanie nowego elementu RelyingParty w pliku IDP_Home/conf/relying-party.xml. Azure AD wymaga zmian domyślnych ustawień saml:SAML2Profile w elemecie DefaultRelyingParty.

Wstaw następujący tekst po elemecie DefaultRelyingParty i upewnij się, że wartość identyfikatora RelyingParty jest zgodna z wartością entityID określoną w sekcji Dodaj metadane Azure AD, na przykład "urn:federation:MicrosoftOnline". Upewnij się również, że wartość dostawcy jest zgodna z identyfikatorem EntityID dostawcy tożsamości Shibboleth określonym w elemecie DefaultRelyingParty , jak pokazano w poniższym przykładzie:

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

Należy również określić opcję Shibboleth Identity Provider, gdzie należy znaleźć plik zawierający metadane Azure AD, na przykład IDP_HOME/metadata/windows-azure-ad-metadata.xml. Możesz to zrobić, dodając wpis do pliku IDP_Home/conf/relying-party.xml w węźle MetadataProvider , jak pokazano w poniższym przykładzie:

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

Konfigurowanie narzędzia rozpoznawania atrybutów Shibboleth

Azure AD wymaga dwóch fragmentów danych od shibboleth Identity Provider w celu zlokalizowania konta w tle na platformie uwierzytelniania. Aby poinformować Shibboleth o tych wymaganiach, dodaj następujące wpisy do pliku IDP_HOME/conf/attribute-resolver.xml:

  • Azure AD niezmienny IDENTYFIKATOR

    Azure AD wymaga wybrania unikatowego identyfikatora dla każdego użytkownika w katalogu użytkownika. Należy również skonfigurować shibboleth, aby wysłać ten atrybut dla każdego identyfikatora logowania federacyjnego do Azure AD w asercji SAML 2.0 NameID. Ten identyfikator nie może ulec zmianie dla tego użytkownika w okresie istnienia użytkownika w systemie. Usługa Azure AD wywołuje ten atrybut "ImmutableID". Wartość unikatowego identyfikatora nie może zawierać informacji o domenie i uwzględnia wielkość liter.

    Na przykład nie należy używać polecenia user@contoso.com. W poniższym zalecanym kodzie użyta wartość będzie właściwością objectGUID usługi Active Directory zakodowaną w formacie Base64. Podczas tworzenia kont musisz upewnić się, że identyfikator ImmutableID jest przetwarzany w taki sam sposób lub użytkownik nie będzie mógł zalogować się do usługi w chmurze firmy Microsoft. Narzędzie Microsoft Azure Active Directory Sync automatycznie używa identyfikatora OBJECTGUID usługi Active Directory dla wartości ImmutableID i przetwarza identyfikator ImmutableID w taki sam sposób, jak w poniższym zalecanym przykładzie:

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

    Ważne

    Zaktualizuj łącznik danych LDAP w attribute-resolver.xml, aby określić identyfikator objectGUID jako binarny.

    Pamiętaj, aby dodać ten wiersz do wpisu łącznika danych LDAP, dzięki temu upewni się, że identyfikator objectGUID jest poprawnie obsługiwany i jest zakodowany w formacie Base64.

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

    Przykład:

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

  • Azure AD identyfikator użytkownika

    Azure AD wymaga, aby Azure AD identyfikator użytkownika, na przykład , joe@contoso.comzostał wysłany przy użyciu wpisu niestandardowego, jak opisano w poniższym przykładzie. W tym przykładzie wartość jest przechowywana w atrybucie 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>

Konfigurowanie filtru atrybutu Shibboleth

Aby zwolnić wymagane atrybuty do Azure AD, należy skonfigurować dostawcę tożsamości Shibboleth. Dodaj następujący tekst do pliku IDP_HOME/conf/attribute-filter.xml, aby zwolnić atrybuty do Azure AD.

Wyświetlane tutaj ustawienia zwalniają wymagane atrybuty tylko do Azure AD i Windows usług na żywo. Ustawienia używają określonych identyfikatorów AttributeFilterPolicy, aby wskazać, że atrybuty są wymagane przez 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>

Opcjonalnie: instalowanie rozszerzenia ECP Shibboleth

Chociaż jest to opcjonalne, jest to zalecany krok. Jeśli używasz narzędzia Shibboleth jako usługi STS, pamiętaj, aby zainstalować rozszerzenie ECP dostawcy tożsamości Shibboleth, aby logowanie jednokrotne działało z telefonem inteligentnym, firmą Microsoft Outlook lub innymi klientami.

Rozszerzone rozszerzenie klienta/serwera proxy (ECP) jest zawarte w shibboleth 2.3.3 i nowszych wersjach. W przypadku starszej wersji środowiska Shibboleth 2.x można pobrać i zainstalować rozszerzenie ECP. Aby uzyskać więcej informacji, zobacz https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Rozszerzenie ECP dostawcy tożsamości Shibboleth umożliwia integrację aplikacji klasycznych poczty e-mail z Azure AD. To rozszerzenie implementuje specyfikację ECP SAML 2.0. Podczas konfigurowania logowania jednokrotnego przy użyciu Azure AD można określić adres URL rozszerzenia ECP, na przykład https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Uwierzytelnianie rozszerzenia ECP Shibboleth jest obecnie ograniczone do uwierzytelniania podstawowego.

Wykonaj następujące kroki, jeśli zdecydujesz się zainstalować rozszerzenie ECP Shibboleth:

  1. Dodaj następujący kod do lokalnego pliku metadanych Azure AD znajdującego się w IDP_HOME/metadanych:

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

  2. Dodaj wpis "saml:SAML2ECPProfile" do węzła konfiguracji RelyingParty Azure AD w relying-party.xml znajdującym się w IDP_HOME/konfiguracji:

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

Uruchom ponownie shibboleth i zweryfikuj funkcjonalność

Zatrzymaj i uruchom serwer Apache Tomcat, aby ponownie uruchomić dostawcę tożsamości Shibboleth i upewnić się, że zaktualizowane pliki XML zostały załadowane. Nie można uruchomić narzędzia Shibboleth, jeśli występuje problem z co najmniej jednym plikiem konfiguracji. Sprawdź pliki dziennika Shibboleth po ponownym uruchomieniu, aby upewnić się, że nie są zgłaszane żadne błędy. Zalecamy również próbę zalogowania się i uzyskania dostępu do wcześniej skonfigurowanego dostawcy usług Shibboleth w sieci.

Uwaga

Sprawdź, czy zegar na serwerze Shibboleth jest zsynchronizowany z dokładnym źródłem czasu. Niedokładny czas zegara może spowodować niepowodzenie logowania federacyjnego.

Zobacz też

Pojęcia

Implementowanie logowania jednokrotnego przy użyciu narzędzia Shibboleth Identity Provider