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

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