{"id":12334,"date":"2020-10-08T10:15:00","date_gmt":"2020-10-08T08:15:00","guid":{"rendered":"https:\/\/www.xiting.de\/sap-ias-im-proxy-mode-und-dessen-koexistenz-mit-azure-active-directory\/"},"modified":"2025-10-01T13:18:18","modified_gmt":"2025-10-01T11:18:18","slug":"sap-ias-im-proxy-mode-und-dessen-koexistenz-mit-azure-active-directory","status":"publish","type":"post","link":"https:\/\/xiting.com\/de\/sap-ias-im-proxy-mode-und-dessen-koexistenz-mit-azure-active-directory\/","title":{"rendered":"SAP IAS im Proxy-Mode und dessen Koexistenz mit Azure Active Directory"},"content":{"rendered":"\n

Mit unserem Einf\u00fchrungsblog zum SAP Cloud Platform Identity Authentication Service (IAS)<\/a> konnten Sie sich einen Gesamt\u00fcberblick verschaffen und die unterschiedlichen M\u00f6glichkeiten zur Integration des SAP IAS, dessen Benutzerverwaltung und verschiedenen Authentifizierungsm\u00f6glichkeiten kennenlernen.<\/p>\n\n\n\n

In dieser Blogserie m\u00f6chten wir Ihnen n\u00e4herbringen, warum der IAS ein unglaublich m\u00e4chtiger und flexibler Service ist, der eine gro\u00dfe Zahl interessanter Features sowie Integrationsm\u00f6glichkeiten bietet. Dank offener Schnittstellen, moderner Standards und regelm\u00e4\u00dfigen Funktionsupdates kann man behaupten, dass er den meisten vorhandenen und heute oft schon veralteten Identity Providern am Markt weit \u00fcberlegen ist. <\/p>\n\n\n\n

Und wer dennoch seine bestehenden Authentifizierungsprozesse und Identity Provider (IdP) weiterverwenden m\u00f6chte, der kann den SAP IAS als Identity Provider Proxy betreiben. <\/p>\n\n\n\n

Mit diesem Blog m\u00f6chten wir anhand von typischen Kundenszenarien aufzeigen, wie sich der SAP IAS hierbei optimal integrieren l\u00e4sst. Dazu werden wir uns auf Microsoft Azure Active Directory als Identity Provider sowie der Cloudl\u00f6sung SAP Ariba als Service Provider fokussieren.<\/p>\n\n\n\n

Authentifizierung ist ein Thema, das Unternehmensweit betrachtet werden muss<\/h2>\n\n\n\n

Sichere Authentifizierung und Single Sign-On sind Themen, die \u00fcber alle Anwendungen eines Unternehmens durchg\u00e4ngig ber\u00fccksichtigt werden sollten. Die meisten Sicherheitsexperten, die sich in diesem Umfeld bewegen wissen, dass sich der moderne Authentifizierungsprozess \u00fcber das Netzwerkperimeter eines Unternehmens hinaus erstreckt und die Benutzer- und Ger\u00e4teidentit\u00e4t einbeziehen sollte. <\/p>\n\n\n\n

Unternehmen k\u00f6nnen \u201eIdentit\u00e4tssignale\u201c 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. <\/p>\n\n\n\n

Diese Vorgaben sollten auch die SAP-Landschaft und SAP-Anwendungen in der Cloud miteinbeziehen.<\/p>\n\n\n\n

\"Conceptual
Abbildung 1 | (Quelle: Microsoft)<\/figcaption><\/figure>\n\n\n\n

Conditional Access <\/h2>\n\n\n\n

Der bedingte Zugriff (auch Conditional Access genannt) ist das Tool, das von Azure Active Directory verwendet wird, um solche Signale zusammenzuf\u00fchren, Entscheidungen zu treffen und Organisationsrichtlinien durchzusetzen. Richtlinien f\u00fcr 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\u00fcck der identit\u00e4tsgesteuerten Steuerebene. <\/p>\n\n\n\n

Solche Richtlinien stellen dabei um Grunde einfache \u201eWenn-Dann-Anweisungen\u201c dar. Wenn ein Benutzer auf eine Ressource zugreifen m\u00f6chte, muss er bestimmte Bedingungen erf\u00fcllen, die sich auf das Ger\u00e4t, die IP Geolokation, den Benutzer bzw. dessen Gruppenmitgliedschaften sowie die aufgerufene Zielanwendung und andere Faktoren beziehen k\u00f6nnen. Auf Basis dieser Pr\u00fcfung erfolgt dann die eigentliche Zugriffsentscheidung oder die Notwendigkeit einer zus\u00e4tzlichen Authentifizierung (MFA).<\/p>\n\n\n\n

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\u00fcbergreifendes Projekt und alleine aus der SAP Basis getrieben, f\u00fchrt dies nicht zum Erfolg. Wir sehen es in unseren Projekten ganz oft, dass Silo-L\u00f6sungen aufgebaut wurden, weil die Cloud-Security-Strategie eines Unternehmens die SAP-Landschaft nicht ber\u00fccksichtigt und die IT-Sicherheit nichts von der SAP-Sicherheit wei\u00df, umgekehrt ist das nat\u00fcrlich genauso.<\/p>\n\n\n\n

SAP hat IAS als vorkonfigurierten Standard-IdP in viele SAP-Cloud-L\u00f6sungen integriert, was den Aufwand und die Komplexit\u00e4t reduziert, die f\u00fcr die Einrichtung jeder einzelnen Anwendung f\u00fcr die SAML-Authentifizierung erforderlich sind. Weitere Gr\u00fcnde f\u00fcr diese Integration finden Sie in unserem \u00dcbersichtsblog<\/a>. 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. <\/p>\n\n\n\n

Die Einf\u00fchrung eines weiteren IdP mit dem Onboarding neuer SAP-Cloud-Anwendungen k\u00f6nnte einige IT-Sicherheitsexperten verwirren. Im n\u00e4chsten Abschnitt werden wir die Integration von SAP IAS als Identity Provider-Proxy behandeln. Dies erm\u00f6glicht sehr leistungsf\u00e4hige und flexible Integrationsszenarien, und es ist notwendig zu verstehen, welche Synergien sich aus dem Parallelbetrieb beider L\u00f6sungen ergeben.<\/p>\n\n\n\n

Integration von SAP IAS als IdP-Proxy in Microsoft Azure<\/h2>\n\n\n\n

Microsoft Azure Active Directory soll nun also als vorhandener Corporate Identity Provider zur Authentifizierung aller Benutzer verwendet werden, um auch f\u00fcr SAP (Cloud)-Anwendungen alle bekannten Sicherheitsfunktionen wie Conditional Access und MFA weiterhin nutzen zu k\u00f6nnen. \n<\/p>\n\n\n\n

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\u00e4hrend der IAS als zentraler Hub und Proxy-System f\u00fcr die angebundenen SAP-Anwendungen eingesetzt wird. <\/p>\n\n\n\n

Ein Parallelbetrieb sieht dann in etwa wie folgt aus:<\/p>\n\n\n\n

\"\"\/
Abbildung 2 | (Quelle: Xiting)<\/figcaption><\/figure>\n\n\n\n

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\u00e4hrend die bestehenden Authentifizierungsrichtlinien- und Methoden beibehalten werden. <\/p>\n\n\n\n

Die Betreiber des Corporate IdP (hier Azure) m\u00fcssen nicht jede SAP-Anwendung einzeln integrieren. Sie m\u00fcssen nicht andauernd Metadaten mit den Security-Admins austauschen, wenn Sie eine neue Anwendung einf\u00fchren oder \u00fcber die richtigen SAML-Claims diskutieren. <\/p>\n\n\n\n

Schauen wir uns also an, wie SAP IAS im Proxybetrieb genau funktioniert und was das \u00fcberhaupt bedeutet. <\/p>\n\n\n\n

An einer solchen Proxy-Beziehung sind (mindestens) folgende Teilnehmer involviert:<\/p>\n\n\n\n

Corporate IdP<\/strong><\/p><\/td>

IdPB<\/sub><\/p><\/td>

Microsoft Azure Active Directory<\/strong>
<\/strong>(m\u00f6glich ist jeder andere SAML-IdP)<\/p><\/td><\/tr>

Proxy IdP<\/strong><\/p><\/td>

IdPA<\/sub>SPB<\/sub><\/p><\/td>

SAP Cloud Platform Identity Authentication<\/strong><\/p><\/td><\/tr>

Service Provider<\/strong><\/p><\/td>

SPA<\/sub><\/p><\/td>

SAP Ariba or SAP IBP<\/strong>
(m\u00f6glich ist auch jede andere SAML-f\u00e4hige Anwendung) <\/p><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Und dieses Szenario sieht dann in etwa so aus:<\/p>\n\n\n\n

\"\"\/
Abbildung 3 | (Quelle: Xiting)<\/figcaption><\/figure>\n\n\n\n

In diesem Aufbau wird somit der Corporate IdP (hier Azure) zur Authentifizierung eingesetzt w\u00e4hrend der SAP Identity Authentication Service als Proxy fungiert, um die Authentifizierung an den externen Corporate IdP zu delegieren. <\/p>\n\n\n\n

SAP IAS ist also SAML IdP zur Anwendung (im Beispiel hier SAP Ariba) und gleichzeitig Service Provider zum Corporate IdP. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Da die SAML 2.0 Spezifikation einen solchen Betrieb erlaubt, ist diese Kaskadierung an sich nichts ungew\u00f6hnliches und man k\u00f6nnte das Spiel sogar noch um weitere Systeme erg\u00e4nzen.<\/p>\n\n\n\n

Der SAML-Authentifizierungsablauf (gem. Abbildung 3) in 14 Schritten erkl\u00e4rt:<\/strong><\/p>\n\n\n\n

  1. Der Browser-Client fordert eine Webressource an, die durch den SAML SP (SPA<\/sub>) gesch\u00fctzt ist. SPA<\/sub> ist in diesem Fall z. B. SAP Ariba. Wenn f\u00fcr SPA<\/sub> bereits eine Session vorhanden ist, weiter mit Schritt 14.<\/p><\/li>

  2. Der Client wird zur IdP-Komponente des SAP IAS umgeleitet, die als IdP-Proxy (IdPA<\/sub>) fungiert und durch die SP-Komponente von IdP-Proxy (SPB<\/sub>) gesch\u00fctzt ist.<\/p><\/li>

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

  4. Die AuthnRequest wird zwischengespeichert und der Client wird an den authentifizierenden IdP (IdPB<\/sub>) umgeleitet, dies ist der Corporate IdP (z. B. Azure).<\/p><\/li>

  5. Der Client sendet einen SAML-AuthnRequest an den SSO-Dienst des IdPB<\/sub>. Wenn keine Session vorhanden ist, identifiziert IdPB<\/sub> den Benutzer (Abstrakt).<\/p><\/li>

  6. IdPB<\/sub> aktualisiert seinen Sicherheitskontext f\u00fcr den Benutzer (Principal) und gibt die SAML Assertion (SAML AuthnResponse) an den Client zur\u00fcck.<\/p><\/li>

  7. Der Client sendet die Antwort an den Assertion Consumer Service des SAP IAS (SPB<\/sub>) welcher die Assertion in der Antwort verifiziert.<\/p><\/li>

  8. SPB<\/sub> aktualisiert seinen Sicherheitskontext f\u00fcr diesen Principal und leitet den Client an den IdPA<\/sub><\/p><\/li>

  9. Der Client fordert erneut einen SAML-AuthnRequest vom IdPA<\/sub>, analog zum AuthnRequest, der in Schritt 3 erstellt wurde.<\/p><\/li>

  10. IdPA<\/sub> aktualisiert seinen Sicherheitskontext f\u00fcr diesen Principal und gibt die SAML Assertion (SAML AuthnResponse) an den Client zur\u00fcck. Die Antwort kann nun entweder nur die Claims enthalten, die vom Corporate IdP (IdPB<\/sub>) in Schritt 6 ausgestellt wurden oder erweiterte Claims, die vom SAP IAS zus\u00e4tzlich oder stellvertretend ausgegeben werden.<\/p><\/li>

  11. Der Client sendet die Antwort an den Assertion Consumer Service des SPA<\/sub>. Der Assertion Consumer Service validiert die Assertion in der Antwort.<\/p><\/li>

  12. SPA<\/sub> aktualisiert seinen Sicherheitskontext f\u00fcr diesen Principal und leitet den Client an die Ressource weiter.<\/p><\/li>

  13. Der Client fordert die Ressource an und nutzt dazu jene Anforderung, die in Schritt 1 ausgegeben wurde.<\/li>
  14. Die Ressource trifft eine Access-Control-Entscheidung basierend auf dem Sicherheitskontext f\u00fcr diesen Principal und seinen in der SAML AuthnResponse bereitgestellten Claims und gibt die Ressource an den Client zur\u00fcck.<\/li><\/ol>\n\n\n\n

    Wichtig ist es zu verstehen, dass die (Azure)-Benutzer kein Profil (Account) im IAS-Benutzerspeicher ben\u00f6tigen, wenn dieser im Proxy-Mode betrieben wird. Dies ist jedoch in vielen F\u00e4llen empfohlen, insbesondere wenn verschiedene Anforderungen in Richtung der SAML Claims bestehen. <\/p>\n\n\n\n

    Anpassung der SAML Claims (modifizieren, anreichern oder ersetzen)<\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    In dem abgebildeten Proxy-Szenario wurde der SAP Identity Authentication Service innerhalb des Azure Active Directory als Enterprise Application hinzugef\u00fcgt. 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<\/strong> \u00fcbergibt und ein paar weitere gew\u00fcnschte Claims evtl. Gruppenmitgliedschaften bzw. UIDs.<\/p>\n\n\n\n

    In der Konfiguration des SAP IAS wird der Corporate IdP f\u00fcr die jeweilige Anwendung aktiviert und somit die Authentifizierung an die Azure Services delegiert.<\/p>\n\n\n\n

    SAP IAS ist in diesem Szenario also immer der Aussteller der SAML Assertion f\u00fcr die jeweilige Zielanwendung, kann jedoch in Abh\u00e4ngigkeit der Konfiguration entweder die vom Corporate IdP definierten Claims oder andere bzw. zus\u00e4tzliche aus dem IAS-Benutzerspeicher mitgeben. <\/p>\n\n\n\n

    Diese Claims k\u00f6nnen somit entweder direkt an das Zielsystem z. B. SAP Ariba weitergeleitet oder auch \u201eangereichert\u201c werden, zum Beispiel um weitere Attribute wie SAP User ID oder Gruppenmitgliedschaften, die evtl. gar nicht vom Corporate IdP geliefert werden k\u00f6nnen. In einigen Anwendungen wie der SAP Cloud Platform erfolgt die Steuerung der Autorisierung mittels Gruppen-Rollen Zuordnung aus der SAML Assertion. Dies erm\u00f6glicht dem IAS-Administrator die Umsetzung eines unabh\u00e4ngigen Gruppenkonzepts innerhalb des SAP IAS.<\/p>\n\n\n\n

    Ein IAS-Administrator kann die vom Corporate-Identity-Provider erhaltenen Assertion-Attribute \u00e4ndern 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\u00dfer 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.<\/p>\n\n\n\n

    Bleiben wir SAP Ariba als erstes Beispiel. Dort werden die User IDs zur Authentifizierung immer \u201ecase-sensitive\u201c behandelt, was auch dem SAP Hinweis 2461598<\/a> zu entnehmen ist. Dieser Umstand f\u00fchrt h\u00e4ufig 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\u00f6glich ist.<\/p>\n\n\n\n

    Beispiel: <\/strong>Der Administrator des IAS-Tenant kann eine Funktion anwenden, um die vom Corporate IdP erhaltene NameID je nach Bedarf der Anwendung, in Gro\u00df- oder Kleinbuchstaben zu konvertieren, was z. B. das Ariba-Problem l\u00f6sen k\u00f6nnte.<\/p>\n\n\n\n

    Identit\u00e4tsf\u00f6deration<\/h2>\n\n\n\n

    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\u00fcber k\u00f6nnen Zugriffe basierend auf dem Benutzerprofil eingeschr\u00e4nkt oder zus\u00e4tzlich Risiko-basierte Authentifizierungsrichtlinien angewendet werden, welche auf Ebene des IAS forciert werden k\u00f6nnen.<\/p>\n\n\n\n

    Wird die Funktion Identity Federation im SAP IAS aktiviert, pr\u00fcft der SAP IAS, ob die vom Corporate IdP authentifizierten Benutzer im IAS bekannt (provisioniert) sind. F\u00fcr diese Benutzer werden dann anstelle der vom Corporate IdP \u00fcbermittelten Informationen, jene aus dem IAS-Benutzerspeicher entnommen und passende Claims basierend auf der Anwendungskonfiguration gesendet. Benutzer ohne Profil k\u00f6nnen weiterhin mit der neu ausgestellten SAML Assertion des Corporate IdP authentifiziert werden, sofern dies noch gestattet ist. <\/p>\n\n\n\n

    Um Identity Federation nutzen zu k\u00f6nnen, m\u00fcssen also zus\u00e4tzliche Konfigurationen auf Mandantenebene vorgenommen werden, damit die ge\u00e4nderten Attribute ber\u00fccksichtigt werden. Weiterhin m\u00fcssen Unternehmen eine Methode zur Benutzerprovisionierung z. B. SCIM REST APIs implementiert haben, damit die Profile unter Umst\u00e4nden automatisiert im SAP IAS erzeugt werden k\u00f6nnen. Dazu kann der Einsatz von weiteren SAP L\u00f6sungen wie dem SAP IDM 8.0 in Verbindung mit dem SAP Cloud Platform Identity Provisioning Service hilfreich sein.<\/p>\n\n\n\n

    Beispiel:<\/strong> Die vom Corporate IdP empfangenen Assertion-Attribute sollen ver\u00e4ndert werden, bevor sie an die Anwendung (Service Provider) gesendet werden. Es k\u00f6nnen Pr\u00e4fixe oder Suffixe angeh\u00e4ngt werden oder auch spezielle Attribute (Application Custom Attributes) verwendet werden. Dies funktioniert sowohl f\u00fcr SAML 2.0 als auch f\u00fcr 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<\/strong> an die SAP Cloudanwendung \u00fcbermittelt, alternativ noch zus\u00e4tzliche Gruppenmitgliedschaften, sofern die Anwendung dies ben\u00f6tigt.<\/p>\n\n\n\n

    Das gezeigte Proxy Szenario k\u00f6nnte dank dieser Funktionen nun zus\u00e4tzlich erweitert werden:<\/p>\n\n\n\n

    1. um Mitarbeiter, die auch im IAS provisioniert wurden, mit unterschiedlichen oder zielgerichtet \u201eangereicherten\u201c bzw. ver\u00e4nderten NameID Formaten und SAML-Claims an die Anwendung weiterzuleiten.<\/li><\/ol>\n\n\n\n
      1. um externe Benutzer wie Partner und Kunden direkt am IAS authentisieren zu k\u00f6nnen, ohne dass diese in Azure bekannt sind (IDP-initiierte Authentifizierung \u00fcber eine spezielle URL – \u00fcber diesen Weg kann die Azure-Anmeldung trotz aktiviertem Corporate IdP f\u00fcr bestimmte Benutzer umgangen werden).<\/li><\/ol>\n\n\n\n
        \"Ein
        Abbildung 4 | (Quelle: SAP SE)<\/figcaption><\/figure>\n\n\n\n

        Fazit<\/h2>\n\n\n\n

        Die Authentifizierung an SAP Anwendungen f\u00fcr die Mitarbeiter eines Unternehmens, kann trotz Einsatz des SAP Cloud Platform Identity Authentication Service<\/strong> weiterhin \u00fcber bestehende SAML Identity Provider und unter Ber\u00fccksichtigung bestehender Sicherheitsvorgaben erfolgen.<\/p>\n\n\n\n

        In Szenarien, in denen es keinen vorhandenen Corporate IdP gibt, kann der SAP IAS dessen Rolle vollst\u00e4ndig \u00fcbernehmen und sowohl f\u00fcr Cloud als auch f\u00fcr On-Premise und Non-SAP-Anwendungn als zentraler Identity Provider betrieben werden.<\/p>\n\n\n\n

        Die Vorteile des Identity Authentication Service im Proxy-Modus…<\/p>\n\n\n\n

        Zentraler SSO-Endpunkt f\u00fcr alle SAP-Cloud-Anwendungen:<\/strong><\/p>\n\n\n\n