Single Sign-On (SSO) in der SAP BTP einfach erklärt

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
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

SAP Single Sign-on in der SAP BTP erklärt Euch die CloudDNA, wir besprechen SAML OAUTH und Open ID CONNECT

Ü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.

Grundlagen des SAP Cloud Connector (SAP CC)

Grundlagen des SAP Cloud Connector (SAP CC)

SAP Cloud Connector (SAP CC)

Inhalt des CloudDNA Expert Talk

Lernen Sie in diesem Expert Talk die Grundlagen des SAP Cloud Connector (SAP CC) kennen und Sie werden sehen, dass er keine Weltraumwissenschaft ist.

Architektur des SAP Cloud Connector

Der SAP Cloud Connector ist ein zentraler Bestandteil hybrider SAP-Systemlandschaften. Er ermöglicht Ihnen eine sichere Integration der Services und Subskriptionen in der SAP Business Technology Platform (SAP BTP) in Ihre On-Premise-Landschaft. Daher ist ein gutes Verständnis der Grundlagen des SAP Cloud Connectors unerlässlich, damit Sie schnell und effizient starten können.

Was bedeutet On-Premise ?

Mit dieser Frage werden wir häufig konfrontiert und sie lässt sich sehr einfach beantworten. Unter On-Premise versteht man die bei Ihnen im Unternehmen bereitgestellten Systeme. Diese laufen entweder in Ihrem eigenen Rechenzentrum, bei Ihrem Hosting-Anbieter oder in der SAP HANA Enterprise Cloud (SAP HEC).  

Wie funktioniert der SAP Cloud Connector ?

Der SAP Cloud Connector ist eine Softwarekomponente, die in Ihrer On-Premise-Landschaft installiert wird und einen TLS (Transport Level Security) Tunnel in die SAP BTP (ehemals SAP Cloud Platform) herstellt. Um konkret zu sein: die Verbindung zum Subaccount hergestellt.

Der SAP Cloud Connector verwendet den Reverse Invoke Proxy Ansatz. D.h. er stellt Ihnen auf Ebene des Subaccount Endpunkte bereit, die von den Services (z.B. SAP Cloud Integration, SAP WebIDE, SAP Mobile Services oder SAP Cloud Portal) aufgerufen werden. Er nimmt Ihre Aufrufe aus der SAP BTP / SAP Cloud Platform entgegen und leitet Sie an die On-Premise-Systeme weiter.

Welche Voraussetzung bestehen für den Cloud Connector ?

Für den Betrieb des SAP CC benötigen Sie lediglich eine JVM in der Java Version 1.8. Eine wesentliche Voraussetzung, die Sie beachten müssen, ist die Netzwerkkonnektivität.

Der SAP CC muss einerseits unter Verwendung des HTTPS-Protokolls die Hosts der SAP Business Technology Platform ansprechen können und andererseits die gewünschten Backendsysteme technisch erreichen. Mit der Version 2.13 sind einige spannende Neuerung gekommen, vor allem mit Blick auf Principal Propagation in der Cloud Foundry Umgebung.

Verbindung mit der SAP Business Technology Platform

Der SAP Cloud Connector verbindet sich mit der Business Technology Platform auf Ebene des Subaccounts. Der SAP CC authentifiziert sich mit einem Benutzer der vom Platform Identity Provider (Platform IdP) verwaltet wird. Sie können entweder den SAP ID Service oder den SAP Identity Authentication Service (SAP IAS) als Platform IdP verwenden. Bei der erstmaligen Anmeldung wird für den Benutzer ein Client Zertifikat erstellt, das in weiterer Folge für die Authentifizierung benötigt wird. Dieses Zertifikat wird am im Cloud Connector gespeichert.

Anbindung der Backend-Systeme

Der SAP Cloud Connector stellt Ihre Backend-Systeme im Subaccount der SAP BTP / SAP Cloud Platform unter einem virtuellen Hostnamen und zugehörigem Port bereit. Diesen virtuellen Hostnamen müssen Sie in den Cloud Services auf Ebene des Subaccounts zwingend verwenden. Für die Verbindung kommt der sogenannte Connectivity Service zur Verwendung. Er stellt über den On-Premise-Proxy technisch die Verbindung zum Cloud Connector her.

Der Cloud Connector bildet den virtuellen Hostnamen auf den physischen Hostnamen ab. D.h. er führt ein Mapping durch. Zusätzlich muss im Cloud Connector definiert werden, welche Ressourcen im Backend angesprochen werden können. Dies entspricht im Falle eines SAP-ABAP-Systems den ICF-Knoten. Der Cloud Connector unterstützt folgende Protokolle:

  • HTTP / HTTPS
  • RFC / RFC (SNC)
  • TCP / TCPS
  • Mail (SMTP, POP3, IMAP)
  • LDAP / LDAPS
  • SFTP / FTP / FTPS

Wie schauen die Sicherheitsaspekte im Cloud Connector aus?

Es gibt eine Reihe an sicherheitsrelevanten Aspekten, die im Cloud Connector zu beachten sind. Dieser bringen wir Ihnen in einem anderen Artikel näher. Doch eines vorab, die Authentifizierung der Administratoren und anderen Benutzer gegen einen LDAP-Server ist essentiell. Sie sollten auch das selbstsignierte SSL-Zertifikat, mit dem der CC im Standard ausgeliefert wird, so schnell wie möglich ersetzen.

SAP HANA Cloud Connector

Sie werden in vielen Blogs und auf Webseiten noch vom HANA Cloud Connector lesen. Dieser wurde im Jahr 2017 auf den Namen SAP Cloud Connector umgetauft. Sollten Sie noch vom SAP HANA Cloud Connector oder der HANA Cloud Platform lesen, raten wir Ihnen sich aktuellere, zeitgemäße Blogs zu suchen. Die Zeitspanne von mehr als drei Jahren seit der Umbenennung sind im Cloud Zeitalter so, wie wenn Sie noch immer in der Bronzezeit leben und denken würden. 😉

Das Video zum Expert Talk

Im Video zeigen wir Ihnen Schritt für Schritt, wie der SAP Cloud Connector funktioniert. Wir hoffen Ihnen damit weiterhelfen zu können. Für Fragen und auch Unterstützung in Projekten stehen wir Ihnen gerne zur Verfügung.

Folgen Sie unserem Youtube Channel um keine Neuigkeiten zu verpassen. Wir veröffentlich in regelmäßigen Intervallen Videos zur SAP Cloud Platform / SAP Business Technology Platform.

CloudDNA Expert Talks zum SAP Cloud Connector

Sehen Sie sich auch unsere anderen Expert Talks zum SAP Cloud Connector an:

SAP Cloud Connector Location Identifier verstehen und richtig verwenden

Mit Fragen zum Cloud Connector, zu SAP Fiori, zur SAP BTP, SAP Cloud Identity Services, zur SAP Integration Suite und anderen innovativen Themen sind Sie bei uns genau an der richtigen Adresse! Haben Sie Fragen zu unseren Leistungen, Paketen oder Produkten? Kontaktieren Sie uns!

Ihre Nachricht an die CloudDNA: