Dies ist eine alte Version des Dokuments!
IDP als Saml-Proxy zum Entra-ID
- Status: Entwurf
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 lokaeln 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 eine 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
#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.
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.