SAP IAS im Proxy-Mode und dessen Koexistenz mit Azure Active Directory

Mit unserem Einführungsblog zum SAP Cloud Platform Identity Authentication Service (IAS) konnten Sie sich einen Gesamtüberblick verschaffen und die unterschiedlichen Möglichkeiten zur Integration des SAP IAS, dessen Benutzerverwaltung und verschiedenen Authentifizierungsmöglichkeiten kennenlernen.

In dieser Blogserie möchten wir Ihnen näherbringen, warum der IAS ein unglaublich mächtiger und flexibler Service ist, der eine große Zahl interessanter Features sowie Integrationsmöglichkeiten bietet. Dank offener Schnittstellen, moderner Standards und regelmäßigen Funktionsupdates kann man behaupten, dass er den meisten vorhandenen und heute oft schon veralteten Identity Providern am Markt weit überlegen ist.

Und wer dennoch seine bestehenden Authentifizierungsprozesse und Identity Provider (IdP) weiterverwenden möchte, der kann den SAP IAS als Identity Provider Proxy betreiben.

Mit diesem Blog möchten wir anhand von typischen Kundenszenarien aufzeigen, wie sich der SAP IAS hierbei optimal integrieren lässt. Dazu werden wir uns auf Microsoft Azure Active Directory als Identity Provider sowie der Cloudlösung SAP Ariba als Service Provider fokussieren.

Authentifizierung ist ein Thema, das Unternehmensweit betrachtet werden muss

Sichere Authentifizierung und Single Sign-On sind Themen, die über alle Anwendungen eines Unternehmens durchgängig berücksichtigt werden sollten. Die meisten Sicherheitsexperten, die sich in diesem Umfeld bewegen wissen, dass sich der moderne Authentifizierungsprozess über das Netzwerkperimeter eines Unternehmens hinaus erstreckt und die Benutzer- und Geräteidentität einbeziehen sollte.

Unternehmen können „Identitätssignale“ als Teil ihrer Zugriffssteuerungsentscheidungen verwenden. Unternehmen sollten heute klare Vorgaben in Bezug auf die Authentifizierungsprozesse schaffen, insbesondere wenn die Grenzen zwischen Intranet und Cloud immer weiter verschwimmen.

Diese Vorgaben sollten auch die SAP-Landschaft und SAP-Anwendungen in der Cloud miteinbeziehen.

Conditional Access

Der bedingte Zugriff (auch Conditional Access genannt) ist das Tool, das von Azure Active Directory verwendet wird, um solche Signale zusammenzuführen, Entscheidungen zu treffen und Organisationsrichtlinien durchzusetzen. Richtlinien für den bedingten Zugriff werden nach Abschluss der sogenannten Erstfaktorauthentifizierung erzwungen, dass ist meistens eine erfolgreiche Anmeldung mit den Zugangsdaten. Der bedingte Zugriff ist somit das Herzstück der identitätsgesteuerten Steuerebene.

Solche Richtlinien stellen dabei um Grunde einfache „Wenn-Dann-Anweisungen“ dar. Wenn ein Benutzer auf eine Ressource zugreifen möchte, muss er bestimmte Bedingungen erfüllen, die sich auf das Gerät, die IP Geolokation, den Benutzer bzw. dessen Gruppenmitgliedschaften sowie die aufgerufene Zielanwendung und andere Faktoren beziehen können. Auf Basis dieser Prüfung erfolgt dann die eigentliche Zugriffsentscheidung oder die Notwendigkeit einer zusätzlichen Authentifizierung (MFA).

Unternehmen, die solche Verfahren einsetzen sehen sich nun damit konfrontiert, auch den Zugriff auf SAP-Anwendungen (On-Premise oder Cloud) in dieses Verfahren zu integrieren. Eines ist klar, dass ist ein fachbereichsübergreifendes Projekt und alleine aus der SAP Basis getrieben, führt dies nicht zum Erfolg. Wir sehen es in unseren Projekten ganz oft, dass Silo-Lösungen aufgebaut wurden, weil die Cloud-Security-Strategie eines Unternehmens die SAP-Landschaft nicht berücksichtigt und die IT-Sicherheit nichts von der SAP-Sicherheit weiß, umgekehrt ist das natürlich genauso.

SAP hat IAS als vorkonfigurierten Standard-IdP in viele SAP-Cloud-Lösungen integriert, was den Aufwand und die Komplexität reduziert, die für die Einrichtung jeder einzelnen Anwendung für die SAML-Authentifizierung erforderlich sind. Weitere Gründe für diese Integration finden Sie in unserem Übersichtsblog. In der Konsequenz bedeutet dies, dass Kunden nicht mehr in der Lage sind, ein direktes Vertrauen zu ihrem bestehenden IdP wie Azure Active Directory herzustellen.

Die Einführung eines weiteren IdP mit dem Onboarding neuer SAP-Cloud-Anwendungen könnte einige IT-Sicherheitsexperten verwirren. Im nächsten Abschnitt werden wir die Integration von SAP IAS als Identity Provider-Proxy behandeln. Dies ermöglicht sehr leistungsfähige und flexible Integrationsszenarien, und es ist notwendig zu verstehen, welche Synergien sich aus dem Parallelbetrieb beider Lösungen ergeben.

Integration von SAP IAS als IdP-Proxy in Microsoft Azure

Microsoft Azure Active Directory soll nun also als vorhandener Corporate Identity Provider zur Authentifizierung aller Benutzer verwendet werden, um auch für SAP (Cloud)-Anwendungen alle bekannten Sicherheitsfunktionen wie Conditional Access und MFA weiterhin nutzen zu können.

Wichtig dabei ist zu verstehen, dass der SAP IAS aus Sicht des Microsoft Azure Active Directory nur ein weiterer Service Provider ist. Somit werden in typischen Kundenszenarien weiterhin eine ganze Menge Service Provider (sog. Enterprise Applications) direkt in Azure angebunden, während der IAS als zentraler Hub und Proxy-System für die angebundenen SAP-Anwendungen eingesetzt wird.

Ein Parallelbetrieb sieht dann in etwa wie folgt aus:

Die Integration des SAP Identity Authentication Service bedeutet Vereinfachung und Zentralisierung. Die Administration der unterschiedlichen SAP-Anwendungen kann dadurch von der IT-Security entkoppelt werden während die bestehenden Authentifizierungsrichtlinien- und Methoden beibehalten werden.

Die Betreiber des Corporate IdP (hier Azure) müssen nicht jede SAP-Anwendung einzeln integrieren. Sie müssen nicht andauernd Metadaten mit den Security-Admins austauschen, wenn Sie eine neue Anwendung einführen oder über die richtigen SAML-Claims diskutieren.

Schauen wir uns also an, wie SAP IAS im Proxybetrieb genau funktioniert und was das überhaupt bedeutet.

An einer solchen Proxy-Beziehung sind (mindestens) folgende Teilnehmer involviert:

Und dieses Szenario sieht dann in etwa so aus:

In diesem Aufbau wird somit der Corporate IdP (hier Azure) zur Authentifizierung eingesetzt während der SAP Identity Authentication Service als Proxy fungiert, um die Authentifizierung an den externen Corporate IdP zu delegieren.

SAP IAS ist also SAML IdP zur Anwendung (im Beispiel hier SAP Ariba) und gleichzeitig Service Provider zum Corporate IdP.

Wenn ein Benutzer, beispielsweise ein Mitarbeiter, der im Azure vorhanden ist, versucht, auf SAP Ariba zuzugreifen, wird er durch den SAP IAS an Azure umgeleitet. Der Benutzer muss sich nun authentifizieren, was wiederum die bekannten Verfahren inkl. Conditional Access, MFA und Co. einbezieht.

Der Clientbrowser wird in diesem sogenannten Service Provider initiierten Authentifizierungsvorgang mehrfach von A nach B geschickt und hat die Aufgabe die unterschiedlichen Authentifizierungsanfragen- und Antworten an die richtige Stelle weiterzuleiten.

Da die SAML 2.0 Spezifikation einen solchen Betrieb erlaubt, ist diese Kaskadierung an sich nichts ungewöhnliches und man könnte das Spiel sogar noch um weitere Systeme ergänzen.

Der SAML-Authentifizierungsablauf (gem. Abbildung 3) in 14 Schritten erklärt:

1. Der Browser-Client fordert eine Webressource an, die durch den SAML SP (SP_A) geschützt ist. SP_A ist in diesem Fall z. B. SAP Ariba. Wenn für SP_A bereits eine Session vorhanden ist, weiter mit Schritt 14.

2. Der Client wird zur IdP-Komponente des SAP IAS umgeleitet, die als IdP-Proxy (IdP_A) fungiert und durch die SP-Komponente von IdP-Proxy (SP_B) geschützt ist.

3. Der Client sendet einen SAML-AuthnRequest an den SSO-Dienst des IdP_A. Wenn am IdP_A bereits eine Session vorhanden ist, weiter mit Schritt 10. Dieses Verhalten kann jedoch konfiguriert werden, um eine erneute Anmeldung zu erzwingen.

4. Die AuthnRequest wird zwischengespeichert und der Client wird an den authentifizierenden IdP (IdP_B) umgeleitet, dies ist der Corporate IdP (z. B. Azure).

5. Der Client sendet einen SAML-AuthnRequest an den SSO-Dienst des IdP_B. Wenn keine Session vorhanden ist, identifiziert IdP_B den Benutzer (Abstrakt).

6. IdP_B aktualisiert seinen Sicherheitskontext für den Benutzer (Principal) und gibt die SAML Assertion (SAML AuthnResponse) an den Client zurück.

7. Der Client sendet die Antwort an den Assertion Consumer Service des SAP IAS (SP_B) welcher die Assertion in der Antwort verifiziert.

8. SP_B aktualisiert seinen Sicherheitskontext für diesen Principal und leitet den Client an den IdP_A

9. Der Client fordert erneut einen SAML-AuthnRequest vom IdP_A, analog zum AuthnRequest, der in Schritt 3 erstellt wurde.

10. IdP_A aktualisiert seinen Sicherheitskontext für diesen Principal und gibt die SAML Assertion (SAML AuthnResponse) an den Client zurück. Die Antwort kann nun entweder nur die Claims enthalten, die vom Corporate IdP (IdP_B) in Schritt 6 ausgestellt wurden oder erweiterte Claims, die vom SAP IAS zusätzlich oder stellvertretend ausgegeben werden.

11. Der Client sendet die Antwort an den Assertion Consumer Service des SP_A. Der Assertion Consumer Service validiert die Assertion in der Antwort.

12. SP_A aktualisiert seinen Sicherheitskontext für diesen Principal und leitet den Client an die Ressource weiter.

13. Der Client fordert die Ressource an und nutzt dazu jene Anforderung, die in Schritt 1 ausgegeben wurde.
14. Die Ressource trifft eine Access-Control-Entscheidung basierend auf dem Sicherheitskontext für diesen Principal und seinen in der SAML AuthnResponse bereitgestellten Claims und gibt die Ressource an den Client zurück.

Wichtig ist es zu verstehen, dass die (Azure)-Benutzer kein Profil (Account) im IAS-Benutzerspeicher benötigen, wenn dieser im Proxy-Mode betrieben wird. Dies ist jedoch in vielen Fällen empfohlen, insbesondere wenn verschiedene Anforderungen in Richtung der SAML Claims bestehen.

Anpassung der SAML Claims (modifizieren, anreichern oder ersetzen)

Jede Cloudanwendung (Service Provider) hat seine Besonderheiten hinsichtlich Benutzermanagement sowie der angeforderten SAML Name Identifier (NameID) Formate und Attribute. Dies betrifft direkt das sogenannte User Mapping. Letztlich wird ein Attribut aus der SAML Assertion, die der IdP ausstellt, zur Authentifizierung verwendet.

In dem abgebildeten Proxy-Szenario wurde der SAP Identity Authentication Service innerhalb des Azure Active Directory als Enterprise Application hinzugefügt. Nach einem Austausch der Metadaten auf beiden Seiten wurde zum Beispiel festgelegt, dass Azure die E-Mail-Adresse als SAML NameID im Format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress übergibt und ein paar weitere gewünschte Claims evtl. Gruppenmitgliedschaften bzw. UIDs.

In der Konfiguration des SAP IAS wird der Corporate IdP für die jeweilige Anwendung aktiviert und somit die Authentifizierung an die Azure Services delegiert.

SAP IAS ist in diesem Szenario also immer der Aussteller der SAML Assertion für die jeweilige Zielanwendung, kann jedoch in Abhängigkeit der Konfiguration entweder die vom Corporate IdP definierten Claims oder andere bzw. zusätzliche aus dem IAS-Benutzerspeicher mitgeben.

Diese Claims können somit entweder direkt an das Zielsystem z. B. SAP Ariba weitergeleitet oder auch „angereichert“ werden, zum Beispiel um weitere Attribute wie SAP User ID oder Gruppenmitgliedschaften, die evtl. gar nicht vom Corporate IdP geliefert werden können. In einigen Anwendungen wie der SAP Cloud Platform erfolgt die Steuerung der Autorisierung mittels Gruppen-Rollen Zuordnung aus der SAML Assertion. Dies ermöglicht dem IAS-Administrator die Umsetzung eines unabhängigen Gruppenkonzepts innerhalb des SAP IAS.

Ein IAS-Administrator kann die vom Corporate-Identity-Provider erhaltenen Assertion-Attribute ändern oder anreichern, bevor sie an die Anwendung (Dienstanbieter) gesendet werden, die das Corporate IdP zur Authentifizierung verwendet. SAP IAS kann auch die Assertion-Attribute vom Corporate-Identity-Provider außer Kraft setzen und stattdessen Attributwerte wie Gruppenzuordnungen bereitstellen, die in der IAS-Konsole gepflegt oder von einem IDM-System unter Verwendung von SCIM bereitgestellt werden.

Bleiben wir SAP Ariba als erstes Beispiel. Dort werden die User IDs zur Authentifizierung immer „case-sensitive“ behandelt, was auch dem SAP Hinweis 2461598 zu entnehmen ist. Dieser Umstand führt häufig zu Authentifizierungsproblemen, meist dann, wenn der Benutzer im Active Directory (Azure) mit einer anderen Schreibweise angelegt wurde. Daher wird meist empfohlen, die E-Mail-Adresse zu verwenden, was jedoch nicht immer möglich ist.

Beispiel: Der Administrator des IAS-Tenant kann eine Funktion anwenden, um die vom Corporate IdP erhaltene NameID je nach Bedarf der Anwendung, in Groß- oder Kleinbuchstaben zu konvertieren, was z. B. das Ariba-Problem lösen könnte.

Identitätsföderation

Der Administrator des IAS-Tenant kann festlegen, ob die Attribute aus der SAML Assertion des Corporate IdP oder aus dem IAS-Benutzerspeicher verwendet werden sollen. Darüber können Zugriffe basierend auf dem Benutzerprofil eingeschränkt oder zusätzlich Risiko-basierte Authentifizierungsrichtlinien angewendet werden, welche auf Ebene des IAS forciert werden können.

Wird die Funktion Identity Federation im SAP IAS aktiviert, prüft der SAP IAS, ob die vom Corporate IdP authentifizierten Benutzer im IAS bekannt (provisioniert) sind. Für diese Benutzer werden dann anstelle der vom Corporate IdP übermittelten Informationen, jene aus dem IAS-Benutzerspeicher entnommen und passende Claims basierend auf der Anwendungskonfiguration gesendet. Benutzer ohne Profil können weiterhin mit der neu ausgestellten SAML Assertion des Corporate IdP authentifiziert werden, sofern dies noch gestattet ist.

Um Identity Federation nutzen zu können, müssen also zusätzliche Konfigurationen auf Mandantenebene vorgenommen werden, damit die geänderten Attribute berücksichtigt werden. Weiterhin müssen Unternehmen eine Methode zur Benutzerprovisionierung z. B. SCIM REST APIs implementiert haben, damit die Profile unter Umständen automatisiert im SAP IAS erzeugt werden können. Dazu kann der Einsatz von weiteren SAP Lösungen wie dem SAP IDM 8.0 in Verbindung mit dem SAP Cloud Platform Identity Provisioning Service hilfreich sein.

Beispiel: Die vom Corporate IdP empfangenen Assertion-Attribute sollen verändert werden, bevor sie an die Anwendung (Service Provider) gesendet werden. Es können Präfixe oder Suffixe angehängt werden oder auch spezielle Attribute (Application Custom Attributes) verwendet werden. Dies funktioniert sowohl für SAML 2.0 als auch für OpenID Connect (id_token) Anwendungen. Somit wird statt der E-Mail-Adresse des Azure Benutzers z. B. die SAP User ID als NameID im Format unspecified an die SAP Cloudanwendung übermittelt, alternativ noch zusätzliche Gruppenmitgliedschaften, sofern die Anwendung dies benötigt.

Das gezeigte Proxy Szenario könnte dank dieser Funktionen nun zusätzlich erweitert werden:

1. um Mitarbeiter, die auch im IAS provisioniert wurden, mit unterschiedlichen oder zielgerichtet „angereicherten“ bzw. veränderten NameID Formaten und SAML-Claims an die Anwendung weiterzuleiten.

2. um externe Benutzer wie Partner und Kunden direkt am IAS authentisieren zu können, ohne dass diese in Azure bekannt sind (IDP-initiierte Authentifizierung über eine spezielle URL – über diesen Weg kann die Azure-Anmeldung trotz aktiviertem Corporate IdP für bestimmte Benutzer umgangen werden).

Fazit

Die Authentifizierung an SAP Anwendungen für die Mitarbeiter eines Unternehmens, kann trotz Einsatz des SAP Cloud Platform Identity Authentication Service weiterhin über bestehende SAML Identity Provider und unter Berücksichtigung bestehender Sicherheitsvorgaben erfolgen.

In Szenarien, in denen es keinen vorhandenen Corporate IdP gibt, kann der SAP IAS dessen Rolle vollständig übernehmen und sowohl für Cloud als auch für On-Premise und Non-SAP-Anwendungn als zentraler Identity Provider betrieben werden.

Die Vorteile des Identity Authentication Service im Proxy-Modus…

Zentraler SSO-Endpunkt für alle SAP-Cloud-Anwendungen:

• Einheitliche Vertrauenskonfiguration für den Corporate Identity Provider des Kunden
• Für Kunden leicht einzurichten
• Vorkonfigurierte oder halbautomatische Vertrauenskonfiguration für SAP-Cloud-Anwendungen
• Wahl zwischen SAML und OpenID Connect, einschließlich Protokollkonvertierung in Richtung SAP-Anwendungen
• Eine SSO-Sitzung für alle SAP-Cloud-Anwendungen mit der Möglichkeit, separate Zugriffskontrollrichtlinien durchzusetzen
• Einzelnes Audit-Protokoll zur Authentifizierung
• SSO für alle SAP-Cloud-Anwendungen

Erweiterte Konfigurations- und Sicherheitseinstellungen:

• Service-Provider-spezifische Attributzuordnung/Umschreibung und Anreicherung der Assertion, ohne dass der Corporate Identity Provider angepasst werden muss
• Einfacher Trennungsmechanismus für mehrere Benutzerspeicher (intern, extern und Mitarbeiter)
• Flexibilität bei der Konfiguration, wo Benutzeranmeldeinformationen validiert werden.
• Risikobasierte Authentifizierung mit der Möglichkeit, stärkere Authentifizierungsmittel durchzusetzen

Xiting unterstützt Unternehmen dabei, eine unternehmensweite Strategie zur sicheren Authentifizierung in die SAP-Umgebung zu integrieren und fungiert als Vermittler zwischen den beiden Welten IT-Security und SAP Security.

In unsere Arbeit fließen laufend aktuelle Erfahrungen aus den Projekten mit unseren Kunden ein. Aus diesem Grund möchten wir auf eine Limitierung in dem hier geschilderten Proxy-Szenario in Verbindung mit dem SAP IAS und Azure Conditional Access hinweisen. Aus Sicht des Azure Active Directory (Corporate IdP) ist SAP Identity Authentication eine „Black-Box“ und alle Anwendungen dahinter sind praktisch maskiert. Dies ist in vielen Fällen kein Problem. Für einen speziellen Anwendungsfall gibt es aktuell weder seitens Microsoft Azure AD noch Seitens SAP einen Lösungsansatz.

Derzeit (Oktober 2020) ist es technisch offenbar nicht möglich, einzelne IAS-Applikationen mit unterschiedlichen Azure CA-Richtlinien zu konfigurieren um beispielsweise den Zugriff auf einzelne Anwendungen nur von bekannten (managed) Geräten zuzulassen, während andere Anwendungen weiterhin auch unternehmensfremde Geräten zulassen.

Weitere Informationen finden Sie hier.