Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:config-advanced:config-azure [2024/03/14 14:09] – czerner@leuphana.de
+++ de:shibidp:config-advanced:config-azure [2024/12/10 12:32] (aktuell) – czerner@leuphana.de
@@ Zeile 1: / Zeile 1: @@
 ====== IDP als Saml-Proxy zum Entra-ID ======
+{{ :de:shibidp:config-advanced:idp-azure2.png?800 |}}
-  * Status: Entwurf
 ====== Vorwort ======
@@ Zeile 9: / Zeile 8: @@
   - 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.
+  - 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?  =====
@@ Zeile 25: / Zeile 24: @@
 getestet.
-Weiter bildet die Basis zur Umkonfiguration eine funktionierendes System.
+Weiter bildet die Basis zur Umkonfiguration ein funktionierendes System.
 ===== Konfiguration =====
@@ Zeile 51: / Zeile 50: @@
 idp.persistentId.sourceAttribute = uid
 </code>
-Jetzt Tomcat neustarten und Anmeldung probieren, im zweitenschritt prüfen ob die in der DB gespeicherten persistenten IDs korrekt zum SP geliefert werden.
+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 :)