======Entra-ID mit Authentifizierung am Shibboleth IDP verwenden====== AzureAD unterstützt grundsätzlich SAML 2 kompatible Identity Provider. Durch einige Eigenheiten in der Umsetzung des SAML Standards ist die Anbindung des Shibboleth Identity Provider in der Version >3.4 zwar möglich, aber nicht gerade intuitiv. Die größte Problematik ist dabei die Interpretation der persistenten NameID. AzureAD erwartet dass ein Account gerneriert wird. Die ID des generierten Accounts muss nachher als persistente NameID übermittelt werden. Der Shibboleth IDP generiert diese ID allerdings erst, wenn der Service Provider das erste Mal von einem Benutzer verwendet wird. Shibboleth-seitig ist es allerdings möglich eine andere ID als persistente NameID zu übertragen. Dazu definieren wir in der global.xml eine Condition, die nur bei dem MicrosoftOnline Service Provider triggert: Diese Condition in der global.xml benötigt einen Neustart des Shibboleth Dienstes. Alle weiteren Änderungen können zur Laufzeit neugelanden werden. Als nächstes müssen wir in der saml-nameid.xml Änderungen vornehmen, damit die persistente ID nach Standard nicht für den MicrosoftOnline SP generiert wird. Dazu kommentieren wir die Zeile aus, die den PersistentNameID Generator referenziert und ersetzen ihn durch einen eigenen: urn:federation:MicrosoftOnline ... Um die passende ID für MicrosoftOnline zu generieren, benötigen wir einen AttributeSource Generator: ... urn:federation:MicrosoftOnline Wie man sehen kann, benötigen wir für diesen Generator ein passendes Attribut 'ImmutableID' aus dem Attribute Resolver. Dazu kann man im attribute-resolver.xml z.B. folgenden Eintrag vornehmen: Dabei kommen diese beiden Attribute bei uns aus dem InputDataConnector "idmConn". Diese Stellen müssen entsprechend angepasst werden, je nach Setup. Da sich bei uns der eduPersonPrincipalName niemals ändert und eindeutig ist, können wir ihn als gemeinsame ID mit dem AzureAD verwenden. Das zweite Attribut "IDPEmail" wird von AzureAD erwartet und sollte die primäre E-Mail Adresse des Benutzers enthalten. Auf alle Fälle, muss sie dem entsprechen, was bei der Erstellung der Benutzer im AzureAD verwendet wird. Das Mapping scheint nicht zu funktionieren, wenn einer der beiden Werte nicht stimmt. Weitere Konfigurationen sind in der relying-party.xml notwendig, da AzuerAD eine signierte Assertion voraussetzt und nicht mit einer signierten SAML Response zufrieden ist. An dieser Stelle sollte man nochmal sicherheitshalber das preferierte NameID Format festlegen. In den Metadaten des MicrosoftOnline SP stehen zwar mehrere zur Auswahl, tatsächlich scheint aber nur die persistente NameID untersützt zu werden. ... Laut Anleitung ist das ECP Profil nur in bestimmten Fällen notwendig. Es wäre also vermutlich möglich, das Profil wegzulassen. Jetzt fehlen noch die Metadaten des MicrosoftOnline SPs. Diese können durch folgende Konfiguration in der metadata-providers.xml geladen werden: md:SPSSODescriptor Damit der MicrosoftOnline SP das IDPEmail Attribut erhält, wird noch eine Freigabe in der attribute-filter.xml benötigt: Mit diesen Änderungen an der Konfiguration konnten wir z.B. office.com mit AzureAD und Authentifizierung gegen einen Shibboleth Identity Provider verwenden.