Konfigurieren von Shibboleth für die Verwendung mit einmaligem Anmelden

Aktualisiert: 25. Juni 2015

Gilt für: Azure, Office 365, Power BI, Windows Intune

Dieses Thema enthält detaillierte Anweisungen zum Konfigurieren des Shibboleth-Identitätsanbieters zum Verbund mit Azure AD, um den Einmaligen Anmelden-Zugriff auf einen oder mehrere Microsoft-Clouddienste (z. B. Microsoft Intune und/oder Office 365) mithilfe des SAML 2.0-Protokolls zu ermöglichen. Die vertrauende SAML 2.0-Seite für einen Microsoft-Clouddienst, die in diesem Szenario verwendet wird, ist Azure AD.

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

Hinzufügen von Azure AD-Metadaten

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.

Hinzufügen von Azure AD als vertrauende Seite

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 nach dem DefaultRelyingParty-Element ein, und vergewissern Sie sich, dass der Id-Wert der vertrauenden Party dem Entitäts-ID-Wert entspricht, den Sie in Den Azure AD-Metadaten angegeben haben, z. B. "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"/>

Konfigurieren des Shibboleth-Attributkonfliktlösers

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 user@contoso.comSie z. B. nicht . Im folgenden empfohlenen Code ist der verwendete Wert die Active Directory-ObjektGUID-Eigenschaft, 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 tool Microsoft Azure Active Directory Synchronisierung verwendet automatisch die Active Directory objectGUID für den ImmutableID-Wert und verarbeitet die ImmutableID auf die gleiche Weise wie im folgenden empfohlenen Beispiel:

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

  Wichtig

  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.commithilfe des benutzerdefinierten Eintrags gesendet wird, wie im folgenden Beispiel beschrieben. 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> 
  

Konfigurieren des Shibboleth-Attributfilters

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>

Optional: Installieren der Shibboleth ECP-Erweiterung

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>
   

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

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.

Weitere Informationen

Konzepte

Verwenden des Shibboleth-Identitätsanbieters zum Implementieren von einmaligem Anmelden