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.

1. Nach dem Authentifizierungsprozess hat der Benutzer eine gültige Shibboleth-Session gegen den IDP und eine gültige OAuth2-Session gegen das Entra-ID.
2. 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.
3. Die Attribute die dem SP übergeben werden, können sowohl aus der lokaeln DB (LDAP) bezogen werden als auch aus dem Entra-ID.

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.

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.

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

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

conf/attribute-resolver.conf

<!-- <AttributeDefinition id="uid" xsi:type="PrincipalName" /> -->

   <AttributeDefinition id="uid" xsi:type="Simple">
        <InputDataConnector ref="myLDAP" attributeNames="uid"/>
    </AttributeDefinition>

In der conf/saml-nameid.properties muss dann der Wert gesetzt sein:

idp.persistentId.sourceAttribute = uid 

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.

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

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:

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

Unter Single-Sign-On → mittig bei “SAML Certificates” die “Federation Metadata XML” herunterladen. Die Konfiguration auf dem Azure ist damit abgeschlossen.

Aus dem Zertifikat und der Tenant-ID und der 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 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.

xmllint idp01-test.xml --format > idp01-test-format.xml 

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:

<MetadataProvider id="AzureAD-idp-metadata" 
        xsi:type="FilesystemMetadataProvider" 
        metadataFile="%{idp.home}/metadata/azure.xml" /> 

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.

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

Den Wert im Attribut von: idp.authn.flows = Password 

In: idp.authn.flows = SAML 

ändern. Dann weiter unten in der Kategorie SAML: (TENANT-ID nicht vergessen zu ändern)

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 
 

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

Wir editieren die Datei conf/c14n/subject-c14n.properties”

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 

Conf/c14/subject-c14.xml

Folgende Zeile einkommentieren:

<bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" />     

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

<AttributeDefinition xsi:type="SubjectDerivedAttribute" 
    forCanonicalization="true" 
    id="canonicalNameToUseForJoin" 
    principalAttributeName="azureName" /> 

nano conf/c14n/attribute-sourced-subject-c14n-config.xml

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

ENDE Konfig v4.x –>

Im ersten Schritt die Attribute des Azure definieren, dazu wird unter conf/attributes eine neue Datei angelegt: azureClaims.xml

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

Conf/attributes/default-attributes.xml

<import resource="azureClaims.xml" /> 

Einen neuen Connector im attribute-resolver.xml definieren.

<DataConnector id="passthroughAttributes" xsi:type="Subject" 
   exportAttributes="azureName azureEmailaddress azureDisplayname azureGivenname azureSurname azureTenantid azureObjectidentifier azureIdentityprovider azureAuthnmethodsreferences" /> 

Dann im attribute-filter.xml die Werte für die interne Verarbeitung freigeben. ACHTUNG, die TENANT-ID wieder ersetzen!

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

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”

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

ENDE Konfig v4.x —>

Nun noch die Attribute zum SP freigeben, Beispiel:

nano conf/attribute-filter.xml

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

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