Exportieren (0) Drucken
Alle erweitern

Konfigurieren von Shibboleth für die Verwendung mit einmaligem Anmelden

Veröffentlicht: Juni 2012

Letzte Aktualisierung: Februar 2015

Betrifft: Azure, Office 365, Windows Intune

Dieses Thema enthält ausführliche Anleitungen zum Konfigurieren des Shibboleth-Identitätsanbieters für einen Verbund mit Azure AD, um einmaliges Anmelden bei mindestens einem Microsoft Cloud-Dienst (z. B. Windows Intune und/oder Office 365) mithilfe des SAML 2.0-Protokolls zu ermöglichen. Die vertrauende SAML 2.0-Seite für einen Microsoft Cloud-Dienst, die in diesem Szenario verwendet wird, ist Azure AD.

ImportantWichtig
In diesem Szenario für einmaliges Anmelden werden nur einige Clients unterstützt:

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

  • Rich-E-Mail-Clients, die Standardauthentifizierung und eine unterstützte Exchange-Zugriffsmethode wie etwa IMAP, POP, Active Sync, MAPI usw. verwenden (der Clientprotokollendpunkt Erweitert muss bereitgestellt werden), z. B.:

    • Microsoft Outlook 2007

    • Microsoft Outlook 2010

    • Thunderbird 8 und 9

    • iPhone (verschiedene iOS-Versionen)

    • Windows Phone 7

Alle anderen Clients werden in diesem Szenario für einmaliges Anmelden mit dem Shibboleth-Identitätsanbieter nicht unterstützt. Die Anmeldung des Lync 2010-Desktopclients beim Dienst mit dem Shibboleth-Identitätsanbieter, der für einmaliges Anmelden konfiguriert ist, wird z. B. nicht unterstützt.

ImportantWichtig
Bevor Sie die einzelnen Schritte in diesem Thema zum Konfigurieren des Shibboleth-Identitätsanbieters für einmaliges Anmelden ausführen können, müssen Sie die unter Vorbereiten des einmaligen Anmeldens beschriebenen Anleitungen lesen und befolgen.

Allgemeine Informationen zum einmaligen Anmelden finden Sie unter Fahrplan für einmaliges Anmelden.

Führen Sie die folgenden Schritte aus, um den Shibboleth-Identitätsanbieter für einmaliges Anmelden zu konfigurieren:

  1. Hinzufügen von Azure AD-Metadaten

  2. Hinzufügen von Azure AD als vertrauende Seite

  3. Konfigurieren des Shibboleth-Attributkonfliktlösers

  4. Konfigurieren des Shibboleth-Attributfilters

  5. Optional: Installieren der Shibboleth ECP-Erweiterung

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

ImportantWichtig
In den Beispielen in diesem Thema ist IDP_HOME das Basisverzeichnis, in dem Sie den Shibboleth-Identitätsanbieter installiert haben. Beispiel: c:\shibboleth2idp. Wenn Sie die Anleitungen zum Konfigurieren von Shibboleth in diesem Thema befolgen, stellen Sie sicher, dass Sie IDP_HOME durch Ihren eigenen Pfad ersetzen.

Der Shibboleth-Identitätsanbieter benötigt Informationen zur vertrauenden Azure AD-Seite. Azure AD veröffentlicht Metadaten unter https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Es wird empfohlen, immer zu überprüfen, ob aktuellere Azure AD-Metadaten vorhanden sind. Die Metadaten weisen den folgenden aktuellen Wert auf:


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

Zum Hinzufügen der Azure AD-Metadaten zum Shibboleth-Identitätsanbieter können Sie die Methode Dateisystem-Metadatenanbieter verwenden – Sie können Azure AD-Metadaten manuell herunterladen und in einer Datei im Ordner IDP_HOME/metadata speichern.

ImportantWichtig
In den Beispielen in diesem Thema ist IDP_HOME das Basisverzeichnis, in dem Sie den Shibboleth-Identitätsanbieter installiert haben. Beispiel: c:\shibboleth2idp. Wenn Sie die Anleitungen zum Konfigurieren von Shibboleth in diesem Thema befolgen, stellen Sie sicher, dass Sie IDP_HOME durch Ihren eigenen Pfad ersetzen.

Sie müssen die Kommunikation zwischen dem Shibboleth-Identitätsanbieter und Azure AD aktivieren, indem Sie ein neues Element RelyingParty in der Datei IDP_Home/conf/relying-party.xml definieren. Azure AD erfordert Änderungen an den Standardeinstellungen saml:SAML2Profile im Element DefaultRelyingParty.

Fügen Sie den folgenden Text hinter dem Element DefaultRelyingParty ein, und stellen Sie sicher, dass der Wert RelyingParty id mit dem Wert entityID übereinstimmt, den Sie unter Hinzufügen von Azure AD-Metadaten angegeben haben. Beispiel: "urn:federation:MicrosoftOnline". Stellen Sie außerdem sicher, dass Ihr Wert provider mit der EntityID des Shibboleth-Identitätsanbieters übereinstimmt, der im Element DefaultRelyingParty angegeben wird. Das folgende Beispiel zeigt dies:

<!-- 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 den Shibboleth-Identitätsanbieter auch informieren, wo sich die Datei befindet, die die Azure AD-Metadaten enthält. Beispiel: IDP_HOME/metadata/windows-azure-ad-metadata.xml. Sie können der Datei IDP_Home/conf/relying-party.xml zu diesem Zweck einen Eintrag im Knoten MetadataProvider wie im folgenden Beispiel gezeigt hinzufügen:

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

Azure AD erfordert zwei Datenelemente aus dem Shibboleth-Identitätsanbieter, um das Schattenkonto auf der Authentifizierungsplattform zu ermitteln. Fügen Sie der Datei IDP_HOME/conf/attribute-resolver.xml die folgenden Einträge hinzu, um Shibboleth über diese Anforderungen zu informieren:

  • Azure AD ImmutableID

    Azure AD erfordert, dass Sie einen eindeutigen Bezeichner für jeden Benutzer in Ihrem Benutzerverzeichnis auswählen. Außerdem müssen Sie Shibboleth für das Senden dieses Attributs für jede Verbundanmeldung bei Azure AD in der SAML 2.0-NameID-Assertion konfigurieren. Dieser Bezeichner darf sich für diesen Benutzer innerhalb der gesamten Lebensdauer des Benutzers in Ihrem System nicht ändern. Der Azure AD-Dienst bezeichnet dieses Attribut als ImmutableID. Der Wert für den eindeutigen Bezeichner darf keine Domäneninformationen enthalten, und für ihn wird zwischen Groß- und Kleinschreibung unterschieden.

    Verwenden Sie z. B. nicht benutzer@contoso.com. Im unten aufgeführten empfohlenen Code ist der verwendete Wert die Active Directory-Eigenschaft objectGUID, die Base64-codiert ist. Beim erstellen von Konten müssen Sie sicherstellen, dass die ImmutableID auf die gleiche Weise verarbeitet wird. Andernfalls kann sich der Benutzer nicht beim Microsoft Cloud-Dienst anmelden. Das Microsoft Azure Active Directory-Synchronisierungstool verwendet automatisch die objectGUID von Active Directory für den Wert ImmutableID und verarbeitet die ImmutableID auf die gleiche Weise wie im folgenden empfohlenen Beispiel gezeigt:

    <!-- 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-Datenconnector in der Datei attribute-resolver.xml, um objectGUID als binär anzugeben.

    Stellen Sie sicher, dass Sie dem Eintrag für Ihren LDAP-Datenconnector die folgende Zeile hinzufügen. Sie gewährleistet, dass die objectGUID ordnungsgemäß verarbeitet 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>
    
    
  • Azure AD-Benutzer-ID

    Azure AD erfordert, dass die Azure AD-Benutzer-ID (z. B. joe@contoso.com) mithilfe des benutzerdefinierten Eintrags wie im Beispiel unten beschrieben gesendet wird. In diesem Beispiel wird der Wert im LDAP-Attribut userPrincipalName gespeichert.

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

Der Shibboleth-Identitätsanbieter muss so konfiguriert werden, dass er die erforderlichen Attribute für Azure AD freigibt. Fügen Sie der Datei IDP_HOME/conf/attribute-filter.xml den folgenden Text hinzu, um die Attribute für Azure AD freizugeben.

Die hier gezeigten Einstellungen geben die erforderlichen Attribute nur für Azure AD- und Windows Live-Dienste frei. Die Einstellungen verwenden bestimmte AttributeFilterPolicy-IDs zum Angeben, dass die Attribute für Azure AD erforderlich sind.


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

Dieser Schritt ist optional, wird jedoch empfohlen. Wenn Sie Shibboleth als Ihren STS verwenden, müssen Sie die ECP-Erweiterung des Shibboleth-Identitätsanbieters installieren, damit das einmalige Anmelden mit einem Smartphone, Microsoft Outlook oder anderen Clients funktioniert.

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

Die ECP-Erweiterung des Shibboleth-Identitätsanbieters ermöglicht die Aktivierung der Integration von E-Mail-Desktopanwendungen in Azure AD. Diese Erweiterung implementiert die SAML 2.0 ECP-Spezifikation. Wenn Sie einmaliges Anmelden mit Azure AD konfigurieren, können Sie die URL für die ECP-Erweiterung angeben, z. B. https://idp.contoso.com/idp/profile/SAML2/SOAP/ECP. Die Shibboleth ECP-Erweiterungsauthentifizierung ist zurzeit auf Standardauthentifizierung eingeschränkt.

Führen Sie die folgenden Schritte aus, wenn Sie die Shibboleth ECP-Erweiterung installieren:

  1. Fügen Sie Ihrer lokalen Azure AD-Metadatendatei im Verzeichnis IDP_HOME/metadata den folgenden Code hinzu:

    <AssertionConsumerService index="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://login.microsoftonline.com/login.srf"/>
    
  2. Fügen Sie dem Azure AD-Konfigurationsknoten RelyingParty in der Datei relying-party.xml im Verzeichnis IDP_HOME/config den Eintrag "saml:SAML2ECPProfile" hinzu:

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

Beenden Sie Apache Tomcat, und starten Sie die Anwendung dann neu, um den Shibboleth-Identitätsanbieter neu zu starten und sicherzustellen, dass die aktualisierten XML-Dateien geladen werden. Shibboleth wird ggf. nicht gestartet, wenn ein Problem mit mindestens einer der Konfigurationsdateien vorliegt. Überprüfen Sie die Shibboleth-Protokolldateien nach dem Neustart, um sicherzustellen, dass keine Fehler gemeldet werden. Außerdem wird empfohlen, dass Sie versuchen, sich anzumelden und auf einen zuvor konfigurierten Shibboleth-Dienstanbieter in Ihrem Netzwerk zuzugreifen.

noteHinweis
Vergewissern Sie sich, dass die Uhr auf dem Shibboleth-Server mit einer genauen Zeitquelle synchronisiert wird. Eine ungenaue Zeitangabe kann zu Fehlern bei Verbundanmeldungen führen.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2015 Microsoft