Grundlagen SAP Identity Authentication Service

Grundlagen SAP Identity Authentication Service

Die Rolle des SAP Identity Authentication Service

Der SAP Identity Authentication Service (SAP IAS) ist ein zentraler Sicherheitsbestandteil in Cloud- und hybriden Architekturen. Er ist eine SAML Identity Provider, der für den Einsatz in SAP-Systemlandschaften optimiert ist. In diesem Artikel bringen wir Ihnen die Funktionsweise des IAS näher. Es kann für eine Vielzahl an Szenarien verwendet werden. Wenn Sie ein Single-Sign-On (SSO) in hybriden SAP-Systemlandschaften realisieren möchten, führt (meist) kein Weg am SAP IAS vorbei.

Inhalt

  • Single-Sign-On
  • SAML
    • Analogie aus dem täglichen Leben
  • SAP IAS im Kontext der SAP BTP
    • Platform Identity Provider (Platform IdP)
    • Application Identity Provider (Application IdP)
  • SAML Service Provider vs. Identity Provider
  • Vertrauensbeziehung SAP IAS / SAP BTP Subaccount 
  • SAP IAS als Proxy (3rd Party IdP, LDAP, Social IdP)
  • CloudDNA Expert Talk Video SAP IAS

Aufgabenstellung: Single-Sign-On (SSO)

Sie haben SAP Software-as-a-Service (SaaS) Produkte im Einsatz. Ausserdem Services und Subskriptionen der SAP BTP  in Verwendung um beispielsweise die Integration der SaaS-Produkte mit OnPremise Lösungen herzustellen. Jetzt stelle ich Ihnen die einige Fragen. An welcher und wievielen Stelle Sie Benutzer pflegen, Rollen zuordnen und die Authentifizierung konfigurieren müssen? Die Antwort lautet hoffentlich „in jedem beteiligtem System“. Wenn Sie eine Systemlandschaft mit unterschiedlichen Systemen verwenden, kann der Aufwand dafür enorm sein. Von Single-Sign-On (SSO) sprechen wir an dieser Stelle noch gar nicht. Natürlich möchten Sie Ihren Benutzern, Kollegen, Mitarbeitern und Geschäftspartnern ermöglichen, sich nach einer einmaligen Anmeldung frei in der Systemlandschaft zu bewegen ohne sich auf jedem System erneut anzumelden. In diesem Fall sprechen wir von Single-Sign-On.

SAML – Der Retter in der Not

Wir haben Ihnen SAML bereits in unserem Blog zum Single-Sign-On in der SAP BTP vorgestellt. Darin haben wir die grundlegenden Konzepte erklärt. SAML kennt die Rollen des Identity Providers und jene des Service Providers. Der SAP IAS nimmt im SAML-Kontext die Rolle des Identity Provider ein. Er kennt alle Benutzeridentitäten und authentifiziert die Benutzer. Jedes SAP SaaS-Produkt kann die Rolle des Service Provider einnehmen, genau wie auch Subaccounts innerhalb der SAP BTP oder Services und Subskriptionen die in diesen Subaccounts bereitgestellt werden. Zwischen den Service Providern und dem Identity Provider wird eine Vertrauensbeziehung aufgebaut. Der Identity Provider kennt alle Service Provider. Die einzelnen Service Provider müssen sich untereinander jedoch nicht kennen. Beim Aufbau der Vertrauensbeziehung werden Metadaten ausgetauscht.

Analogie aus dem täglichen Leben

Sie können SAML auf Basis einer Analogie aus dem täglichen Leben einfach verstehen. Wenn Sie einen neuen Mobilfunkvertrag abschließen oder ein Auto anmieten möchten, müssen Sie sich beim jeweiligen Serviceanbieter ausweisen. Als Ausweis könnte ich beispielsweise einen Schüler- oder Studentenausweis verwenden. Jedoch ist dieser nicht besonders vertrauenswürdig und kann leicht gefälscht oder manipuliert werden. Mit einem Reisepass, einem Personalausweis oder einem Führerschein sieht es schon anders aus. Dabei handelt es sich um Dokumente die vom jeweiligen Land über Ministerien, Behörden oder beliehene Unternehmen nach vorhergehender Prüfung der Identität der betroffenen Person ausgestellt werden. Diese Dokumente weisen besondere Sicherheitsmerkmale auf und können nur mit hohem Aufwand gefälscht werden. Im SAML-Kontext entspricht die ausstellende Stelle des Identitätsdokuments dem Identity Provider und alle Serviceanbieter die diesen Dokumenten vertrauen dem Service Provider. Sie geben uns bestimmt recht, dass die Analogie perfekt passt.

Der SAP IAS im Kontext der SAP BTP

Der SAP IAS kann als Identity Provider für die Subaccounts der SAP BTP fungieren. Dabei ist zwischen Administratoren und Entwicklern des Subaccounts sowie klassischen Endbenutzern der Services zu unterscheiden. Die Administratoren und Entwickler, sogenannten Subaccount-Member werden im Standard gegen den SAP ID Service authentifiziert. D.h. Sie können für jeden Benutzer im SAP Service Marktplatz einen S-User anlegen und diesen im Subaccount als Member hinzufügen. Der Aufwand ist vor allem bei größeren Benutzergruppen enorm und der SAP ID Service bietet Ihnen keine Anpassungsmöglichkeiten. Daher können Sie den SAP IAS als Platform Identity Provider verwenden.

Platform Identity Provider (Neo only)

In der SAP BTP Neo-Umgebung haben Sie die Möglichkeit einen Plattform IdP und einen Application IdP zu konfigurieren. Der Platform IdP ist für die Authentifizierung der Benutzer auf Ebene des Subaccounts verantwortlich. Dabei handelt es sich um Entwickler, Administratoren, Supportmitarbeiter und Auditoren. Im Standard verwendet die SAP BTP den SAP ID Service als Platform IdP. Daher können Sie sich mit Ihrem S-User wie gewohnt anmelden. Der SAP ID Service ist mit einigen Einschränkungen verbunden. Sie haben daher auch die Möglichkeit den SAP Identity Authentication Service (SAP IAS) als Platform IdP zu verwenden. Damit haben Sie die Verwaltung und Pflege der Benutzer selbst in der Hand. Der SAP IAS ist in vielen SAP Cloud Lizenzen enthalten und kann daher lizenzkostenfrei verwendet werden. Als Platform Identity Provider ist der SAP IAS aktuell nur in der Neo-Umgebung unterstützt. In der Cloud-Foundry-Umgebung gibt es aktuell keine Unterstütztung. 

Sie haben für den Platform IdP folgende Optionen:

  • SAP ID Service (S-User)
  • SAP Identity Authentication Services (SAP IAS)

Application Identity Provider (Neo und Cloud Foundry)

Der Application Identity Provider hat die Aufgaben die Benutzer (Fachbenutzer / Enduser) Ihrer bereitgestellten Anwendungen zu authentifizieren. Er kann sowohl in der Neo– als auch in der Cloud-Foundry-Umgebung verwendet werden. Falls Sie beispielsweise die Mobile Services verwenden, werden die Benutzer der Apps gegen den Application IdP authentifiziert. Sie haben für den Application IdP folgende Optionen:

  • SAP ID Service (S-User)
  • SAP Identity Authentication Services (SAP IAS)
  • 3rd Party SAML Identity Provider (z.B. Azure AD)

SAML Service Provider vs. Identity Provider

Der SAP BTP Subaccount fungiert sowohl im Falle des Platform IdP als auch in der Rolle des Application IdP als SAML Service Provider (SAML SP) und der SAP IAS als SAML Identity Provider. Der IAS bietet Ihnen einen Vielzahl an Möglichkeiten. In der nachfolgenden Abbildung sehen Sie, wo der IAS als Platform Identity Provider aktivert werden kann.

Platform IDP aktivieren

Vertrauensbeziehung SAP IAS / SAP BTP Subaccount 

Die Vertrauensbeziehung zwischen SAP IAS und SAP BTP Subaccount wird automatisch hergestellt. Ein manueller Austausch der SAML-Metadaten ist nicht erforderlich. Der Subaccount wird im IAS als Application registriert. Dort haben Sie die Möglichkeit eine erweiterte Konfiguration durchzuführen. So können Sie beispielsweise das Aussehen der Anmeldemaske anpassen, Privacy Policies hinterlegen oder die SAML Konfiguration anzupassen. Im IAS werden Benutzer nicht pro Applikation angelegt sondern zentral und damit für alle Applikationen sichtbar. Damit der Benutzer im Subaccount verwendet werden kann, müssen Sie ihn noch als Member im Subaccount hinzufügen und im Subaccount mit entsprechenden Berechtigungen versehen. Die Anmeldung der Benutzer erfolgt ab diesem Zeitpunkt gegen der SAP IAS. In einem anderen Artikel gehen wir auf den SAP Identity Provisioning Service ein. Damit können Sie die Verteilung der Benutzer in die einzelnen Service Provider automatisieren.

SAP IAS als Proxy

Der SAP IAS kann auch die Rolle eines Proxy einnehmen und die Authentifizierung zu einem anderen Identity Provider delegieren. Dabei kann u.a. ein 3rd Party SAML Identity Provider verwendet werden. Er kann aber auch als Proxy zu einem Corporate LDAP dienen. Das geschieht im Zusammenspiel mit dem SAP Cloud Connector. Damit können Sie Ihren bestehenden LDAP Server wiederverwenden. Der SAP IAS ermöglich Ihnen auch die Verwendung und Integration von Social Identity Providern. Damit könenn Sie auf die Authentifizierung beliebter Sozialer Netzwerke zurückgreifen. Aktuell sind folgende Social IdPs unterstützt:

  • Facebook
  • Twitter
  • Google
  • LinkedIn

CloudDNA Expert Talk Video zum IAS

Sehen Sie sich unseren Expert Talk an und überzeugen Sie sich selbts – der IAS spielt eine zentrale Rolle. Im Video sehen Sie auf unserem legendären Lightboard wie alle Komponenten zusammenspielen.

Literaturhinweis - Vom CloudDNA Autorenteam

Im Juni 2021 ist unter dem Rheinwerk Verlag (SAP Press) ein Buch zum Thema SAP BTP Sicherheit und Berechtigungen mit Martin Koch als Autor erscheinen. Sie können das Buch bereits bestellen. Wir garantieren Ihnen - Sie werden nicht enttäuscht sein!

Link zum Buch

SAP Business Technology Platform – Sicherheit und Berechtigungen

FAQ und FAKTEN

Wie funktioniert Vertrauensbeziehung zwischen SAP IAS / SAP BTP Subaccount? 

Die Vertrauensbeziehung zwischen SAP IAS und SAP BTP Subaccount wird automatisch hergestellt. Ein manueller Austausch der SAML-Metadaten ist nicht erforderlich.

Kann der SAP IAS als Proxy fungieren?

Der SAP IAS kann auch die Rolle eines Proxy einnehmen und die Authentifizierung zu einem anderen Identity Provider delegieren

 

Verlieren Sie keine Zeit - kontaktieren Sie uns jetzt

Zögern Sie nicht uns zu kontaktieren. Mit Fragen zum SAP Cloud Connector, zur SAP BTP, zur SAP Cloud Platform, zur SAP CPI, zur SAP Integration Suite und anderen innovativen Themen sind Sie bei uns genau an der richtigen Adresse!

Ihre Nachricht an uns

Über den Autor

Martin Koch

Martin Koch

SAP Cloud Veteran / SAP Alumni

Ich bin SAP Cloud Berater, Architekt und Entwickler der ersten Stunde - um es auf neudeutsch zu sagen ein "SAP Cloud Veteran". Neben der SAP Cloud Platform / SAP Business Technology Platform entwickle ich seit dem allerersten Release SAPUI5 und SAP Fiori Apps. Für SAP bin ich weltweit erfolgreich als Trainer im Bereich neue Technologien (Cloud, Integration, SAPUI5, Fiori, Mobile, SAP HANA, Security) im Einsatz. Besonders stolz bin ich darauf, zu den weltweit am besten bewertete Trainern zu gehören. Seit 2021 bin ich SAP Press Autor im Bereich der SAP Business Technology Platform. Hier gibt es voerst zwei Publikationen zum Themas Sicherheit und Berechtigungen sowie zu den SAP Mobile Services.

Single Sign-On in der SAP BTP (SAP Cloud Platform)

Single Sign-On in der SAP BTP (SAP Cloud Platform)

Grundlagen Single Sign-On in der SAP BTP

-SSo in der SAP BTP-

Diesmal  beschäftigen wir uns mit dem Thema Single Sign-On, auch SSO genannt und beleuchten für sie viel interessanten Themen. Es erfüllt eine einfache Anforderung mit der Sie typischerweise im Unternehmensumfeld konfrontiert sind.
Bei Single Sign-On steht Ihnen ein zentralisierter Service für Benutzerauthentifizierung bereit. Dieser ermöglicht es Ihnen, sich mit einem Satz von Anmeldedaten an verschiedensten Systemen anzumelden. Die Idee ist einfach aber auch genial. Sie werden an einer zentralen Stelle authentifiziert und können danach transparent auf Systeme zugreifen. Nun müssen Sie sich nicht jedes Mal erneut anmelden. Vor eine weitere Herausforderung stellt Sie der personalisierte Zugriff auf Programmierschnittstellen, sogenannten APIs. Sie kennen bestimmt auch die Anmeldung mit Credentials aus Sozialen Medien und Services wie Facebook, Twitter, LinkedIn oder Google. Damit werden Sie vor weitere Herausforderungen gestellt.

Inhaltsverzeichnis Single Sign-On

  • Federated Identities
  • Wichtige Begriffe
    • Authentifizierung
    • Autorisierung
  • Protokolle
    • SAML 2.0
    • OAuth 2.0
    • OpenID Connect
Zum Schluss gibt es noch ein besonderes Schmankler, wir erklären Ihnen alles im über SSO im CloudDNA der Expert-Talk,

Warum Federated Identities?

Das Ziel nach dem wir streben ist eine einfache Integration all dieser Anforderungen. Gleichzeitig möchten wir dass die Sicherheit auf einem hohen Level gehalten wird. Die Lösung dafür, kann nur den Namen den „Federated Identities“ tragen.
Aktuell gibt es drei Protokolle für Federated Identities, die wir in weiterer Folge betrachten:

  • SAML 2.0
  • OAuth
  • OpenID

Diese Protokolle sind auch im SAP Kontext von entscheidender Bedeutung. Egal ob in der SAP Business Technology Platform, einem S/4 HANA System, eine SAP Business Suite oder SAP SaaS Lösungen wie SAP SuccessFactors.

Welche wichtigen Begriffe für Single Sign-On gibt es?

An dieser Stelle ist es wichtig, dass Sie zentrale Begriffe verstehen und richtig einordnen können. Die zwei wichtigsten sind Authentifizierung und Autorisierung. Sie werden mir bestimmt bestätigen dass diese häufig falsch verwendet werden. Da beide Konzepte sind für Sicherheit und Zugriffsmanagement von fundamentaler Bedeutung sind, erkläre ich ihnen im folgenden Blog alles darüber.

Authentifizierung

Die Authentifizierung sorgt dafür, dass wir in der Rolle des Benutzers identifiziert werden. Dafür verwenden wir gerne eine Analogie aus dem täglichen Leben. Sie haben bestimmt einen Reisepass oder einen Personalausweise. Diese weisen bestimmte Sicherheitsmerkmale auf und beinhalten u.a. ein mehr oder weniger aktuelles Foto von Ihnen. Der Ausweis wird von einer zentralen und vertrauenswürdigen Stelle ausgestellt. Mit diesem Ausweis können Sie von dritten identifiziert werden. Genau das ist die Aufgabe der Authentifizierung.

Autorisierung

Die Autorisierung stellt ihr Berechtigung zur Nutzung bestimmter Funktionen oder Services dar. Auch hier bringen wir Ihnen dieses Konzept anhand eines gängigen Beispiels nahe. Wenn Sie  durch den Portier (=österreichischer Begriff für Pförtner) anhand Ihres Personalausweises authentifiziert werden. Wird er Ihnen einen unternehmensinternen Ausweis ausstellen, der Sie für den Zutritt in bestimmte Gebäudeteile berechtigt. Wenn Sie Mitarbeiter des Unternehmens sind, werden Sie umfangreicheren Zugang haben als Besucher. Die Autorisierung findet immer nach der Authentifizierung statt.

Protokolle für SSO

Wir gehen nun detailliert auf die zuvor erwähnten Protokolle für „Federated Identities“ ein.

SAML 2.0

Die Security Assertion Markup Language, auch SAML genannt, ist ein offener Standard den Sie für Single Sign-on verwenden können. Er basiert auf XML. Der SAML 2.0 Standard wurde im März 2005 veröffentlicht. und wird von OASIS verwaltet. Details finden Sie unter Link.
Sie können SAML für die Authentifizierung und Autorisierung verwenden. Im SAML Standard finden Sie zwei Rolle, den Identity Provider und den Service Provider.

Identity Provider

Der Identity Provider stellt die zentrale Stelle dar, der alle beteiligten Systeme vertrauen. Er authentifiziert Sie als Benutzer. Dabei können Sie je nach Ausprägung unterschiedliche Verfahren wie beispielsweise Benutzername / Passwort oder Client Zertifikate verwenden. Im Kontext der SAP Cloud Platform steht Ihnen ein Identity Provider zur Verfügung. Dabei handelt es sich um den Identity Authentication Service, der Ihnen von SAP mit der Bereitstellung der SAP BTP zur Verfügung gestellt wird. Damit können Sie Ihre Benutzerbasis entweder direkt verwalten oder ihn als Proxy zu anderen Identity Providern, wie AzureAD, oder zu Corporate Identity Providern, wie einem Active Directory, verwenden.

Service Provider

Der Service Provider stellt das System dar, auf das Sie zugreifen möchten. Er authentifiziert Ihren Benutzer nicht selbst, sondern delegiert die Authentifizierung an den Identity Provider.
Sie müssen zwischen dem Service Provider und dem Identity Provider eine Vertrauensbeziehung herstellen. Der Identity Provider kennt dabei alle Service Provider, die Service Provider müssen sich untereinander jedoch nicht kennen.

Beispiel

Identity Provider (IdP): SAP Identity Authentication Service. Hier gehts zum BLOG IAS
Service Provider (SP): SAP Successfactors
Sie versuchen, sich von einem Browser aus an Ihrer SAP Successfactors-Instanz anzumelden.
SAP Successfactors antwortet mit der Generierung einer SAML-Anfrage. Der Browser leitet Sie zu einer SSO-URL, dem SAP IAS um. Er analysiert die SAML-Anfrage, authentifiziert Sie und erzeugt eine SAML-Antwort. Der SAP IAS sendet die verschlüsselte SAML-Antwort erneut an den Browser. Dieser leitet Sie mit der SAML-Antwort im Gepäck an SAP Successfactors weiter. Wenn SAP Successfactors Ihrem SAML-Antwort erfolgreich verifiziert hat, wird Ihr Benutzer an der Anwendung angemeldet und erhält Zugriff auf alle verschiedenen Ressourcen.

OAuth 2.0

Die Version OAuth 2.0 wurde von der IETF im RFC 6749 veröffentlicht. OAuth führt eine Autorisierungsschicht ein, die die Rolle des Clients von der des Ressourcenbesitzers trennt. Wenn Sie OAuth verwenden fordert der Client den Zugriff auf Ressourcen an. Diese werden vom Ressourceneigentümer kontrolliert und vom Ressourcenserver gehostet , und erhält einen anderen Satz von Anmeldeinformationen als die des Ressourceneigentümers.

Welche Rollen können im OAuth festgelegt werden?

OAuth 2.0 definiert vier Rollen:

  • Resource Owner
  • Client
  • Authorization Server
  • Resource Server
Resource Owner

Er ist eine Entität, die in der Lage ist, Ihnen Zugriff auf eine geschützte Ressource zu gewähren. Wenn der Eigentümer der Ressource eine Person ist, wird sie als Endbenutzer bezeichnet.

Client

Es ist eine Anwendung! Die im Namen des Eigentümers der Ressource und mit dessen Autorisierung Anforderungen an geschützte Ressourcen stellt.

Authorization Server

Der Authorization Server gibt Zugriffstoken an den Client aus, nachdem er den Eigentümer der Ressource erfolgreich authentifiziert und die Autorisierung erhalten hat.

Resource Server

Der Resource Server stellt den Server dar, der die geschützten Ressourcen auf die Sie zugreifen möchten hostet.  Ausserdem ist er in der Lage, Anfragen nach geschützten Ressourcen unter Verwendung von Zugriffstokens anzunehmen und zu beantworten.

OAuth Authorization Grants

Ein Authorization Grant ist ein Berechtigungsnachweis. Er stellt die Berechtigung des Ressourceneigentümers dar, der vom Client verwendet wird, um ein Zugriffstoken zu erhalten. Die Spezifikation definiert vier Grant Types:

  • Authorization Code
  • Implicit
  • Resource Owner Password Credentials
  • Client Credentials
Authorization Code

Er wird durch die Verwendung eines Authorization Server als Vermittler zwischen dem Client und dem Resource Owner ausgestellt. Anstatt die Autorisierung direkt vom Resource Owner anzufordern, gibt der Client den Resource Owner an einen Authorization Server weiter. Er leitet wiederum den Resource Owner mit dem Authorization Code zurück an den Client.

Implicit

Dem Client wird statt eines Authorization Code direkt ein Zugriffstoken ausgestellt. Dieser Grant-Typ ist implizit, da keine intermediate Credentials ausgegeben werden.

Resource Owner Password Credentials

Alle Anmeldeinformationen des Ressourceneigentümers (d. h. Benutzername und Passwort) können direkt als Authorization Grant verwendet werden, um ein Zugriffstoken zu erhalten. Sie sollten Ihn nur verwenden, wenn ein hohes Maß an Vertrauen zwischen dem Ressourceneigentümer und dem Client besteht und wenn andere Authorization Grants nicht verfügbar sind.

Client Credentials

Die Anmeldedaten des Clients können als Authorization Grant verwendet werden, wenn der Autorisierungsumfang (Authorization Scope) auf die geschützten Ressourcen unter der Kontrolle des Clients oder auf geschützte Ressourcen, die zuvor mit dem Authorization Server vereinbart wurden, beschränkt ist.

Beispiel

  • Netflix möchte von Ihrem Facebook-Konto auf Ihre Freundesliste
    zugreifen.
  • Sie werden von Neetflix an den Autorisierungsserver (in diesem Fall
    Facebook) weitergeleitet.
  • Wenn Sie den Zugriff autorisieren, wird der Autorisierungsserver in der Callback-Antwort einen Autorisierungscode an den Client senden
    (Netflix).
  • Dieser Code wird dann zwischen Facebook und Netflix  gegen ein
    Access-Token ausgetauscht.
  • Nun kann Netflix mit diesem Zugriffstoken den Ressourcen-Server
    (Facebook) abfragen und Ihre Freundesliste abrufen.

OpenID Connect

OpenID Connect ist eine einfache Identitätsschicht die auf dem OAuth 2.0-Protokoll aufsetzt. Sie erweitert OAuth 2.0 um eine „Federated Authentication“ zu ermöglichen. Der Flow von OpenID Connect sieht genauso aus wie bei OAuth. Die einzigen Unterschiede sind, dass in der initialen Anfrage ein bestimmter Scope von openid verwendet wird und dass der Client beim finalen Austausch sowohl ein Access Token als auch ein ID Token erhält.

SAP SSO der Expert-Talk

Wie versprochen wird Ihnen Martin Koch alles zum Thema SSO am dem legendären Lightboard erklären

Über den Autor

Martin Koch

Martin Koch

SAP Cloud Veteran / SAP Alumni

Ich bin SAP Cloud Berater, Architekt und Entwickler der ersten Stunde - um es auf neudeutsch zu sagen ein "SAP Cloud Veteran". Neben der SAP Cloud Platform / SAP Business Technology Platform entwickle ich seit dem allerersten Release SAPUI5 und SAP Fiori Apps. Für SAP bin ich weltweit erfolgreich als Trainer im Bereich neue Technologien (Cloud, Integration, SAPUI5, Fiori, Mobile, SAP HANA, Security) im Einsatz. Besonders stolz bin ich darauf, zu den weltweit am besten bewertete Trainern zu gehören. Seit 2021 bin ich SAP Press Autor im Bereich der SAP Business Technology Platform. Hier gibt es voerst zwei Publikationen zum Themas Sicherheit und Berechtigungen sowie zu den SAP Mobile Services.