(0) exportieren Drucken
Alle erweitern

Konfigurieren von Shibboleth für die Verwendung mit dem einmaligen Anmelden

Veröffentlicht: Juni 2012

Letzte Aktualisierung: Februar 2013

Betrifft: Office 365, Windows Azure Active Directory, Windows Intune

noteHinweis
Dieses Thema enthält Onlinehilfe für mehrere Microsoft-Clouddienste, einschließlich Windows Intune und Office 365.

Dieses Thema enthält ausführliche Anweisungen zum Konfigurieren von Shibboleth Identity Provider für den Verband mit Windows Azure AD, um das einmalige Anmelden für den Zugriff auf Microsoft-Clouddienste (wie Windows Intune und/oder Office 365) unter Verwendung des Protokolls SAML 2.0 zu aktivieren. Die in diesem Szenario verwendete vertrauende Seite von SAML 2.0 für einen Microsoft-Clouddienst ist Windows Azure AD.

ImportantWichtig
In diesem Szenario des einmaligen Anmeldens wird nur ein begrenzter Satz von Clients unterstützt. Hierzu gehören:

  • Web-basierte Clients wie Exchange Web Access und SharePoint Online

  • Clients mit vielen E-Mails, von denen Standardauthentifizierung und eine unterstützte Exchange-Zugriffsmethode wie IMAP, POP, Active Sync, MAPI usw. verwendet werden (der Endpunkt des Enhanced-Cientprotokolls muss bereitgestellt werden); hierzu gehören:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 und 9

    • Das iPhone (verschiedene iOS-Versionen)

    • Windows Phone 7

Alle anderen Clients werden in diesem Szenario des einmaligen Anmeldens mit Shibboleth Identity Provider nicht unterstützt. So wird z. B. die Anmeldung des Lync 2010-Desktopclients mit Shibboleth Identity Provider nicht unterstützt, wenn Shibboleth Identity Provider für das einmalige Anmelden konfiguriert ist.

ImportantWichtig
Sie müssen zunächst die Anweisungen unter Vorbereiten des einmaligen Anmeldens lesen und befolgen, bevor Sie die Schritte in diesem Thema zum Konfigurieren von Shibboleth Identity Provider für das einmalige Anmelden abschließen können.

Allgemeine Informationen zum einmaligen Anmelden finden Sie unter Einmaliges Anmelden: Roadmap.

Führen Sie die folgenden Schritte aus, um Shibboleth Identity Provider für das einmalige Anmelden zu konfigurieren:

  1. Hinzufügen von Windows Azure AD-Metadaten

  2. Hinzufügen von Windows Azure AD als eine vertrauende Seite

  3. Konfigurieren von Shibboleth Attribute Resolver

  4. Konfigurieren von Shibboleth Attribute Filter

  5. Optional: Installieren der Erweiterung „Shibboleth ECP“

  6. Neustarten von Shibboleth und Überprüfen der Funktionalität

ImportantWichtig
In den Beispielen in diesem Thema bezeichnet IDP_HOME durchgängig das Basisverzeichnis, in dem Shibboleth Identity Provider installiert wurde, z. B. c:\shibboleth2idp. Stellen Sie sicher, dass Sie IDP_HOME durch den von Ihnen verwendeten Pfad ersetzen, während Sie Shibboleth anhand der Anweisungen in diesem Thema konfigurieren.

Hinzufügen von Windows Azure AD-Metadaten

Für Shibboleth Identity Provider werden Informationen über die vertrauende Seite von Windows Azure AD benötigt. Metadaten werden von Windows Azure AD unter https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml veröffentlicht. Suchen Sie stets nach den aktuellsten Windows Azure AD-Metadaten. Der aktuelle Wert der Metadaten lautet:


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

Sie können die Methode The Filesystem Metadata Provider (der Metadatenanbieter des Dateisystems) verwenden, um Shibboleth Identity Provider die Windows Azure AD-Metadaten hinzuzufügen. Sie können die Windows Azure AD-Metadaten manuell herunterladen und in einer Datei im Ordner IDP_HOME/metadata speichern.

ImportantWichtig
In den Beispielen in diesem Thema bezeichnet IDP_HOME durchgängig das Basisverzeichnis, in dem Shibboleth Identity Provider installiert wurde, z. B. c:\shibboleth2idp. Stellen Sie sicher, dass Sie IDP_HOME durch den von Ihnen verwendeten Pfad ersetzen, während Sie Shibboleth anhand der Anweisungen in diesem Thema konfigurieren.

Hinzufügen von Windows Azure AD als eine vertrauende Seite

Sie müssen die Kommunikation zwischen Shibboleth Identity Provider und Windows Azure AD aktivieren, indem Sie ein neues Element vom Typ RelyingParty in der Datei IDP_Home/conf/relying-party.xml definieren. Für Windows Azure AD sind Änderungen an den Standardeinstellungen für saml:SAML2Profile im Element DefaultRelyingParty erforderlich.

Fügen Sie den folgenden Text nach dem Element DefaultRelyingParty ein, und stellen Sie sicher, dass der Wert für RelyingParty id dem Wert für entityID entspricht, den Sie unter Hinzufügen von Windows Azure AD-Metadaten angegeben haben. Beispiel: "urn:federation:MicrosoftOnline". Stellen Sie auch sicher, dass der Wert für provider dem Wert für EntityID Ihrer Instanz von Shibboleth Identity Provider entspricht, der im Element DefaultRelyingParty wie im folgenden Beispiel gezeigt angegeben wurde:

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

Sie müssen auch für Shibboleth Identity Provider angeben, wo die Datei, die die Windows Azure AD-Metadaten enthält, gespeichert ist. Beispiel: IDP_HOME/metadata/wlid-metadata.xml. Fügen Sie hierzu wie im folgenden Beispiel gezeigt der Datei IDP_Home/conf/relying-party.xml im Knoten MetadataProvider einen Eintrag hinzu:

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

Konfigurieren von Shibboleth Attribute Resolver

Für Windows Azure AD werden zwei Informationen von Shibboleth Identity Provider benötigt, um das Schattenkonto in der Authentifizierungsplattform zu finden. Fügen Sie der Datei IDP_HOME/conf/attribute-resolver.xml die folgenden Einträge hinzu, um Shibboleth über diese Anforderungen zu informieren:

  • Windows Azure AD ImmutableID

    Für Windows Azure AD ist es erforderlich, dass Sie für jeden Benutzer in Ihrem Benutzerverzeichnis einen eindeutigen Bezeichner auswählen. Sie müssen zudem Shibboleth so konfigurieren, dass dieses Attribut bei jeder Verbundanmeldung bei Windows Azure AD in der SAML 2.0-Assertion NameID gesendet wird. Dieser Bezeichner darf während der Lebensdauer des Benutzers in Ihrem System für diesen Benutzer nicht geändert werden. Im Windows Azure AD-Dienst wird dieses Attribut als ImmutableID bezeichnet. Der Wert dieses eindeutigen Bezeichners darf keine Domäneninformationen enthalten. Groß-/Kleinschreibung wird für diesen Wert beachtet.

    Verwenden Sie z. B. nicht user@contoso.com. In dem folgenden empfohlenen Code wird die Base64-codierte Active Directory-Eigenschaft objectGUID als Wert verwendet. Beim Erstellen von Konten müssen Sie sicherstellen, dass das Attribut ImmutableID auf die gleiche Weise verarbeitet wird. Andernfalls kann sich der Benutzer nicht beim Microsoft-Clouddienst anmelden. Von der Microsoft Online Services-Verzeichnissynchronisierung wird die Active Directory-Eigenschaft objectGUID automatisch als Wert für ImmutableID verwendet, und das Attribut ImmutableID wird auf die gleiche Weise wie im folgenden empfohlenen Beispiel verarbeitet:

    <!-- 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> 
    
    
    ImportantWichtig
    Aktualisieren Sie den LDAP Data Connector in der Datei attribute-resolver.xml so, dass die Eigenschaft objectGUID in Binärform angegeben wird.

    Sie müssen zudem Ihrem Eintrag für LDAP Data Connector die folgende Zeile hinzufügen, um sicherzustellen, dass die Eigenschaft objectGUID richtig gehandhabt wird und Base64-codiert ist.

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

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

    Für Windows Azure AD ist es erforderlich, dass die Windows Azure AD-Benutzer-ID (z. B. joe@contoso.com) mithilfe eines benutzerdefinierten Eintrags – wie im folgenden Beispiel beschrieben – gesendet wird. In diesem Beispiel wird der Wert im LDAP-Attribut userPrincipalName gespeichert.

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

Konfigurieren von Shibboleth Attribute Filter

Shibboleth Identity Provider muss so konfiguriert werden, dass die erforderlichen Attribute an Windows Azure AD freigegeben werden. Fügen Sie der Datei IDP_HOME/conf/attribute-filter.xml den folgenden Text hinzu, um die Attribute an Windows Azure AD freizugeben.

Mit den hier gezeigten Einstellungen werden die erforderlichen Attribute nur an Windows Azure AD und Windows Live-Dienste freigegeben. Für diese Einstellungen werden bestimmte AttributeFilterPolicy-IDs verwendet, um die für Windows Azure AD erforderlichen Attribute zu kennzeichnen.

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

Optional: Installieren der Erweiterung „Shibboleth ECP“

Dieser Schritt ist zwar optional, wird jedoch empfohlen. Wenn Sie Shibboleth als Ihren Sicherheitstokendienst verwenden, müssen Sie die Erweiterung Shibboleth Identity Provider ECP installieren, damit das einmalige Anmelden von einem Smartphone, Microsoft Outlook oder anderen Clients aus möglich ist.

Die erweiterte Client/Proxy-Erweiterung (ECP) gehört zum Lieferumfang von Shibboleth 2.3.3 und höher. Für frühere Versionen von Shibboleth 2.x können Sie die Erweiterung ECP herunterladen und installieren. Weitere Informationen finden Sie unter: https://wiki.shibboleth.net/confluence/display/SHIB2/IdP+ECP+Extension.

Mithilfe der Erweiterung Shibboleth Identity Provider ECP können Sie die Integration von E-Mail-Desktopanwendungen in Windows Azure AD aktivieren. Von dieser Erweiterung wird die SAML 2.0 ECP-Spezifikation implementiert. Wenn Sie das einmalige Anmelden mit Windows Azure AD konfigurieren, können Sie die URL für die Erweiterung ECP angeben. Beispiel: https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Die Authentifizierung der Erweiterung Shibboleth ECP ist derzeit auf die Standardauthentifizierung beschränkt.

Neustarten von Shibboleth und Überprüfen der Funktionalität

Beenden und starten Sie Apache Tomcat, um Shibboleth Identity Provider neu zu starten, und stellen Sie sicher, dass alle XML-Dateien, für die ein Update ausgeführt wurde, geladen sind. Shibboleth kann möglicherweise nicht gestartet werden, wenn ein Problem mit den Konfigurationsdateien besteht. Überprüfen Sie nach dem Neustart die Shibboleth-Protokolldateien, um sicherzustellen, dass keine Fehler gemeldet wurden. Wir empfehlen Ihnen auch, sich bei einem zuvor konfigurierten Shibboleth-Dienstanbieter in Ihrem Netzwerk anzumelden und auf diesen Dienstanbieter zuzugreifen.

noteHinweis
Überprüfen Sie, ob die Uhr auf Ihrem Shibboleth-Server mit einer akkuraten Zeitquelle synchronisiert ist. Fehler bei der Anmeldung können durch eine falsche Uhrzeit verursacht werden.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft