de:shibidp:config-advanced:config-azure [Dokumentation DFN-AAI, DFN-PKI und eduroam]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== IDP als Saml-Proxy zum Entra-ID ======

{{ :de:shibidp:config-advanced:idp-azure2.png?800 |}}

====== Vorwort ======
Die Idee ist es den IDP nicht gegen eine lokale DB zu authentifizieren, sondern die Authentifizierungsanfrage über den IDP-SAML-Proxy gegen das  Entra-ID. Dies hat für die, die auch MS365-Dienste benutzen, gewisse Vorteile. 

  - Nach dem Authentifizierungsprozess hat der Benutzer eine gültige Shibboleth-Session gegen den IDP und eine gültige OAuth2-Session gegen das Entra-ID. 
  - Man benötigt zur Implementierung einer MFA-Umgebung jetzt nur noch die Token-Konfiguration im Azure. Man spart sich also den PrivacyIdea-Server plus eine zweimalige Einrichtung der Token. 
  - Die Attribute die dem SP übergeben werden, können sowohl aus der lokalen DB (LDAP) bezogen werden, als auch aus dem Entra-ID. 

===== Wie muss ich mir das vorstellen?  =====

Der Benutzer möchte sich an einem Webdienst anmelden, wird zum IDP weitergeleitet. Nun kommt statt der Usernamen und Passwortabfrage der Windows-Anmeldedialog. Dort meldet man sich an, der IDP erhält dem Ouath2-CLAIM vom Entra-ID, es werden im User-Consent die Attribute wieder angezeigt die im Filter freigeben sind. Die Auswahl wird bestätigt und fertig. 

===== Voraussetzung =====
An den MS365 Diensten meldet man sich mit seiner E-Mail-Adresse an, aus diesem Grunde ist es wichtig, für die Abfrage an die LDAP-DB die E-Mail zur verwenden, um dann für alles Weitere (persitente-ID Generieung, usw.) die UID zu verwenden.  

Die Konfiguration wurde unter

  * Debian11, Tomcat9, Shib 4.1.3 konvertiert von 3.x  
  * Debian12, Tomcat10, Shib 5.0 neuinstall 

getestet. 

Weiter bildet die Basis zur Umkonfiguration ein funktionierendes System. 

===== Konfiguration =====
==== Umkonfiguration Anmeldekennung ====
Im ersten Schritt sollte die Anmeldung so konfiguriert werden, dass die Benutzer sich mit der E-mail aus dem LDAP anmelden können. Dabei muss sichergestellt werden, dass zur ID (persistenten, subject) Generierung weiterhin das korrekte Attribut verwendet wird (bei uns die UID).

conf/ldap.properties
<code>
#idp.authn.LDAP.userFilter                       = (uid={user})
idp.authn.LDAP.userFilter                       = (mail={user})

#idp.attribute.resolver.LDAP.searchFilter        = (uid=$resolutionContext.principal)
idp.attribute.resolver.LDAP.searchFilter        = (mail=$resolutionContext.principal)
</code>
conf/attribute-resolver.conf
<code>
<!-- <AttributeDefinition id="uid" xsi:type="PrincipalName" /> -->

   <AttributeDefinition id="uid" xsi:type="Simple">
        <InputDataConnector ref="myLDAP" attributeNames="uid"/>
    </AttributeDefinition>
</code>
In der conf/saml-nameid.properties muss dann der Wert gesetzt sein:
<code>
idp.persistentId.sourceAttribute = uid 
</code>
Jetzt den Tomcat neustarten und Anmeldung probieren, im zweiten Schritt prüfen, ob die in der DB gespeicherten persistenten IDs korrekt zum SP geliefert werden. 
==== Konfiguration Azure ====


=== Eine Enterprise-Applikation erstellen ===
 

Enterpriese applications | All Applications -> New Application -> Create your own application -> Namen eingeben und den Punkt "Integrate any other application you don't find in the gallery (Non-gallery)” -> Create 

===  SAML konfigurieren: ===

In der Konfiguration der neuen Applikation auf Overview -> “2. Setup Single sign on” -> SAML 

  * Dann unter Entity-ID: https://DNS-DES-IDPS/idp/shibboleth 
  * und unter Reply-Url: https://DNS-DES-IDPS/idp/profile/Authn/SAML2/POST/SSO 

eintragen: 

=== Benutzer konfigurieren: ===
 
Unter “Users and Groups” einen ersten Benutzer hinzufügen. 

=== Zertifikat und Tenant-ID ===

Unter Single-Sign-On -> mittig bei “SAML Certificates” die “Federation Metadata XML” herunterladen. Die Konfiguration auf dem Azure ist damit abgeschlossen. 
==== IDP ====
=== Metadaten ===
Aus dem Zertifikat und der Tenant-ID und der {{ :de:shibidp:config-advanced:azure_metadata_template.xml |Vorlage}} muss nun eine gültige Metadaten-Datei gebaut werden. Diese dient dann als Vertrauensstellung zwischen dem IDP und dem Entra-ID. 

Die Metadaten aus dem Azure habe ich nicht ans Laufen bekommen. Aus diesem Grunde muss manuell eine Metadatei erstellt werden. 

Hierzu steht ein {{ :de:shibidp:config-advanced:azure_metadata_template.xml |Template}} bereit, in dieses Template muss das Zertifikat und die Tenant-ID aus den “Federation Metadata XML” eingefügt werden. 

Die Metadaten aus dem Azure erst mal formatieren, unter Linux über xmllint. 
<code>
xmllint idp01-test.xml --format > idp01-test-format.xml 
</code>
Nun das Template öffnen und dort die Tenant-ID und das Zertifikat mit dem Daten aus der gerade formatierten Datei ersetzen. 

Das Zertifikat muss zwischen die “<ds:X509Certificate> </ds:X509Certificate>” die "Tenant-ID" entsprechnd ersetzen. 

Die Metadaten-Datein dann unter metadata/azure.xml abspeichern und unter conf/metadata-providers.xml entsprechend laden: 
<code>
<MetadataProvider id="AzureAD-idp-metadata" 
        xsi:type="FilesystemMetadataProvider" 
        metadataFile="%{idp.home}/metadata/azure.xml" /> 
</code>
 

Nun sollte der IDP neugestartet werden, zeigt das Log keine Fehler, so war dies vermutlich erfolgreich. Ggf. das Log unter conf/logback.xml erweitern und das Logging auf “DEBUG” stellen. 
=== SAML-Auth konfigurieren ===
Die Konfiguration einiger Attribute ist aus der Datei “conf/authn/saml-authn-config.xml” in die Datei “conf/authn/authn.properties” gewandert. 

Wir edititieren die Datei “conf/authn/authn.properties”: 
<code>
Den Wert im Attribut von: idp.authn.flows = Password 

In: idp.authn.flows = SAML 
</code>
ändern. Dann weiter unten in der Kategorie SAML: (TENANT-ID nicht vergessen zu ändern)
<code>
idp.authn.SAML.nonBrowserSupported = false 
idp.authn.SAML.proxyEntityID = https://sts.windows.net/TENANT-ID/ 
idp.authn.SAML.supportedPrincipals = \ 
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, \ 
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:Password, \ 
    saml1/urn:oasis:names:tc:SAML:1.0:am:password 
 </code>

Nun einmal den Tomcat neustarten und es sollte der Azure-Anmeldedialog kommen. 

=== c14n Flow  ===
Wir editieren die Datei conf/c14n/subject-c14n.properties” 
<code>
idp.c14n.attribute.attributeSourceIds = azureName 
# Allows direct use of attributes via SAML proxy authn, bypasses resolver 
idp.c14n.attribute.resolveFromSubject = true 
idp.c14n.attribute.resolutionCondition = shibboleth.Conditions.FALSE 
</code>
 

Conf/c14/subject-c14.xml 

Folgende Zeile einkommentieren: 
<code>
<bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" />     
</code>
 
In der v5 scheint das Subject zur ID Bestimmung anders zu funktionieren.

**Nur für v4.1.x und früher, v5 braucht diese Einstellungen NICHT** 

 

nano conf/attribute-resolver.xml 
<code>
<AttributeDefinition xsi:type="SubjectDerivedAttribute" 
    forCanonicalization="true" 
    id="canonicalNameToUseForJoin" 
    principalAttributeName="azureName" /> 
</code>
nano conf/c14n/attribute-sourced-subject-c14n-config.xml 

<code> 
    <util:list id="shibboleth.c14n.attribute.AttributesToResolve"> 
        <value>canonicalNameToUseForJoin</value> 
    </util:list> 
    <!-- 
    A list of attributes to search for a value to produce as the normalized subject name. 
    This will normally be something you resolve above. 
    --> 
    <util:list id="shibboleth.c14n.attribute.AttributeSourceIds"> 
        <value>canonicalNameToUseForJoin</value> 
    </util:list> 
</code>
**ENDE Konfig v4.x -->**
=== Daten ===
Im ersten Schritt die Attribute des Azure definieren, dazu wird unter conf/attributes eine neue Datei angelegt: {{ :de:shibidp:config-advanced:azureclaims.xml |azureClaims.xml}}

Dann müssen die Werte geladen werden, dazu einen neuen <import> definieren: 

Conf/attributes/default-attributes.xml 
<code>
<import resource="azureClaims.xml" /> 
</code>
Einen neuen Connector im attribute-resolver.xml definieren. 
<code>
<DataConnector id="passthroughAttributes" xsi:type="Subject" 
   exportAttributes="azureName azureEmailaddress azureDisplayname azureGivenname azureSurname azureTenantid azureObjectidentifier azureIdentityprovider azureAuthnmethodsreferences" /> 
</code>
Dann im attribute-filter.xml die Werte für die interne Verarbeitung freigeben. ACHTUNG, die TENANT-ID wieder ersetzen! 
<code>
<AttributeFilterPolicy id="FilterPolicyObject-Proxy-FromAzure-byIssuer-Type"> 
    <PolicyRequirementRule xsi:type="Issuer" value="https://sts.windows.net/TENANT-ID/" /> 
    <AttributeRule attributeID="azureDisplayname" permitAny="true" /> 
    <AttributeRule attributeID="azureGivenname" permitAny="true" /> 
    <AttributeRule attributeID="azureSurname" permitAny="true" /> 
    <AttributeRule attributeID="azureAuthnmethodsreferences" permitAny="true" /> 
    <AttributeRule attributeID="azureIdentityprovider" permitAny="true" /> 
    <AttributeRule attributeID="azureTenantid" permitAny="true" /> 
    <AttributeRule attributeID="azureEmailaddress" permitAny="true" /> 
    <AttributeRule attributeID="azureObjectidentifier" permitAny="true" /> 
    <AttributeRule attributeID="azureName" permitAny="true" /> 
</AttributeFilterPolicy> 
</code>
 
**Achtung V4.1.x und früher** 

Die “Conf/attributes/default-attributes.xml” wurde bei meiner Konfiguration nicht geladen. Um dies nachzuholen, muss der folgende Eintrag gesetzt werden: 

**Es wird nur der AzureClaims.xml geladen damit, sollten die Attribute noch im Resolver definiert sein, nichts kaputt geht.**

Nano “conf/services.xml” 
<code>
    <!-- 
    This is suitable for new installs but will usually produce duplicate Attribute 
    output if a legacy resolver file is used that contains AttributeEncoders. 
    --> 
    <util:list id ="shibboleth.AttributeRegistryResources"> 
<!--        <value>%{idp.home}/conf/attribute-registry.xml</value> 
        <value>%{idp.home}/conf/attributes/default-rules.xml</value> 
        <value>%{idp.home}/conf/attribute-resolver.xml</value> --> 
        <value>%{idp.home}/conf/attributes/azureClaims.xml</value> 
    </util:list> 
</code>

**ENDE Konfig v4.x --->**

Nun noch die Attribute zum SP freigeben, Beispiel:

nano conf/attribute-filter.xml
<code>
   <AttributeFilterPolicy id="Carsten">
        <PolicyRequirementRule xsi:type="OR">
            <Rule xsi:type="Requester" value="https://DNS/simplesaml" />
            <Rule xsi:type="Requester" value="https://DNS/simplesaml/module.php/saml/sp/metadata.php/IDP-Q" />
        </PolicyRequirementRule>
        <AttributeRule attributeID="uid"                    permitAny="true"/>
        <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true"/>
        <AttributeRule attributeID="mail"                   permitAny="true"/>
        <AttributeRule attributeID="surname"                permitAny="true"/>
        <AttributeRule attributeID="givenName"              permitAny="true"/>
        <AttributeRule attributeID="sn"              permitAny="true"/>
        <AttributeRule attributeID="gecos"              permitAny="true"/>
        <AttributeRule attributeID="eppn"              permitAny="true"/>
        <AttributeRule attributeID="eduPersonScopedAffiliation" permitAny="true"/>
        <AttributeRule attributeID="idmEduGlobalID" permitAny="true"/>
        <AttributeRule attributeID="idmEduPersonScopedAffiliation" permitAny="true"/>
        <AttributeRule attributeID="persistentId" permitAny="true"/>
        <AttributeRule attributeID="subject-id" permitAny="true"/>
        <AttributeRule attributeID="idmEduPreferredGivenName" permitAny="true"/>
        <AttributeRule attributeID="idmEduPreferredSurname" permitAny="true"/>
        <AttributeRule attributeID="eduPersonTargetedID" permitAny="true"/>
         <AttributeRule attributeID="samlSubjectID" permitAny="true"/>
         <AttributeRule attributeID="samlPairwiseID" permitAny="true"/>
            <AttributeRule attributeID="azureTenantid" permitAny="true" />
    <AttributeRule attributeID="azureEmailaddress" permitAny="true" />
    <AttributeRule attributeID="azureObjectidentifier" permitAny="true" />
    <AttributeRule attributeID="azureName" permitAny="true" />

</AttributeFilterPolicy>
</code>

Nun den Tomcat neustarten und es sollte die Anmeldung gelingen und die Daten an den SP übergeben werden. ENDE :)