• Status: Entwurf

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