
Single Sign-On (SSO) in der SAP BTP einfach erklärt
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
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
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.
Recent Comments