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 und zusätzlich 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 Frage 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.

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, auch SSO genannt 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, der es Ihnen ermöglicht, 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 ohne sich jedes Mal erneut anmelden zu müssen. 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

Federated Identities

Das Ziel nach dem wir streben ist eine einfache Integration all diese Anforderungen und gleichzeitig die Sicherheit auf einem hohen Level zu halten. Die Lösung dafür trägt den Namen „Federated Identities“.
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.

Wichtige Begriffe für Single Sign-On

An dieser Stelle ist es wichtig, dass Sie zentral Begriff 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. Beide Konzepte sind für Sicherheit und Zugriffsmanagement von fundamentaler Bedeutung.

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. Sie 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. Sie wurden durch den Portier (=österreichischer Begriff für Pförtner) anhand Ihres Personalausweises authentifiziert. Er stellt Ihnen einen unternehmensinternen Ausweis aus, 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önne. 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.
Zwischen dem Service Provider und dem Identity Provider muss eine Vertrauensbeziehung hergestellt werden. 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
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

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. Bei der Verwendung von OAuth fordert der Client den Zugriff auf Ressourcen an, die vom Ressourceneigentümer kontrolliert und vom Ressourcenserver gehostet werden, und erhält einen anderen Satz von Anmeldeinformationen als die des Ressourceneigentümers.

Rollen

OAuth 2.0 definiert vier Rollen:

  • Resource Owner
  • Resource Server
  • Client
  • Authorization 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.

Resource Server

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

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.

OAuth Authorization Grants

Ein Authorization Grant ist ein Berechtigungsnachweis, der die Berechtigung des Ressourceneigentümers darstellt und 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, leitet der Client den Resource Owner an einen Authorization Server weiter, der wiederum den Resource Owner mit dem Authorization Code zurück an den Client leitet.

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

Die 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, sendet der Autorisierungsserver in der Callback-Antwort einen Autorisierungscode an den Client
    (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.

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

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

Sicherheitsaspekte

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

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

SAP Cloud Connector Location Identifier richtig nutzen!

SAP Cloud Connector Location Identifier richtig nutzen!

Sie können den SAP Cloud Connector (CC) für unterschiedlichste Szenarien verwenden. Unter anderem auch um sich aus einer geografisch verteilten Systemlandschaft mit dem Subaccounts der SAP Business Technology Platform (SAP BTP). Damit können Sie unter Verwendung der SAP Cloud Platform Integration (CPI) bzw. der SAP Integration Suite Schnittstellen in die On-Premise-Landschaft umsetzen. Wir zeigen Ihnen wie der SAP Cloud Connector Location Identifier richtig verwendet wird. Der Artikel wurden von den Experten der CloudDNA GmbH aus Österreich auf deutsch veröffentlicht. Er soll als Begleittext zum unserem YouTube-Video dienen.

Inhalt des CloudDNA Expert Talks

In diesem CloudDNA Expert Talk geht es darum, wie Sie den SAP Cloud Connector (SAP CC) mit Location Identifier (Location ID) verwenden können. Wir zeigen Ihnen wie sich unterschiedliche SAP Cloud Connector Instanzen mit demselben Subaccount verbinden lassen kann.

SAP Cloud Integration Kommunikation über den SAP Cloud Connector

Gehen wir von folgender Annahme aus. Sie haben eine SAP CPI (Cloud Platform Integration) oder die SAP Integration Suite mit aktiver Cloud Integration Capability. Sie möchten aus der Cloud Integration heraus über den SAP Cloud Connector (CC) eine Verbindung zu einem System in der On-Premise-Landschaft herstellen. Der SAP Cloud Connector öffnet dazu einen TLS Tunnel (=Transport Level Security) zum Subaccount. Über diesen Tunnel läuft der gesamte Traffic aus der Cloud in die On-Premise-Systemlandschaft. Dies funktioniert sowohl bei SAP- als auch bei Non-SAP-Systemen.

Die SAP Cloud Connector LocationID

Wir gehen in unserer Annahme ein Schritt weiter. Sie müssen Gesellschaften in unterschiedlichen Ländern oder in unterschiedlichen geografischen Regionen über die SAP CPI integrieren. Sie können für dieses Szenario in jeder Region in der Sie ein Backendsystem integrieren möchten einen Cloud Connector installieren. Der Subaccount in der SAP BTP bzw. der SAP Cloud Platform könnte nun nicht mehr unterscheiden über welchen Cloud Connector die Nachrichten in die On-Premise-Landschaft gesendet werden. Auch dafür bietet der SAP CC eine Lösung. Es ist lediglich erforderlich, dass jede Cloud Connector Instanz beim Aufbau der Verbindung mit dem Subaccount eine Location-ID (LOC) verwendet.

Funktioniert in der Neo- und Cloud-Foundry-Umgebung

Die SAP Cloud Connector LocationID wird sowohl für die Neo- als auch für die Cloud-Foundry-Umgebung unterstützt. Die Kommunikation aus den Services und Subskriptionen auf Ebene des Subaccount erfolgt immer über den Connectivity Service. Dieser bedient sich der über den Destination Service angelegten Destinationen. Diese beinhalten die technische Konfiguration. In der Destination muss die Location-ID ebenfalls gepflegt werden. Sie haben jedoch auch die Möglichkeit, einen Cloud Connector als Default zu verwenden. Dazu dürfen Sie keine Location-ID anführen.

Unsere Empfehlung

Wir verwenden in unseren Projekten SAP Cloud Connector Location Identifier die an die IATA 3-Letter-Codes in der Luftfahrt angelehnt sind. Die Begründung dafür ist recht einfach. Ich bin ausgebildeter Linienpilot und Fluglotse. Ich habe erkannt hat dass die Standardisierung und Normierung in der Luftfahrt absolut gewinnbringen in der IT verwendet werden kann. Folgende Beispiele für Location-IDs können wir Ihnen als Inspiration geben:

  • Wien (VIE)
  • Berlin (BER) – mittlerweile ja fertiggestellt…
  • Frankfurt (FRA)
  • New York (NYC)
  • Sydney (SYD)
  • Dubai (DUB)

Das Video zum Expert Talk

Im Video bauen wir diese Szenario Schritt für Schritt auf. 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ässigen Intervallen Videos zur SAP Cloud Platform.

CloudDNA Expert Talks zum SAP Cloud Connector

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

Grundlagen des SAP Cloud Connector

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

SAP Cloud Platform Java Entwicklung – Teil 2

Zugriff auf SAP HANA in der NEO Umgebung

Im ersten Teil der Blogserie habe ich Sie in die Java Entwicklung auf Basis des Spring Frameworks eingeführt. Anhand eines einfachen RestControllers wurden die Grundlagen gezeigt.

Was wäre eine Applikation ohne Zugriff auf eine Datenbank. Im SAP Cloud Kontext ist es natürlich naheliegend dass SAP HANA als Datenbank verwendet wird. In diesem Teil der Blogserie zeige ich Ihnen wie auf die Datenbank in der NEO Umgebung zugegriffen werden kann.

JNDI – Die gelben Seiten

Der Zugriff auf die HANA Datenbank erfolgt über JNDI, aus meiner Sicht eine der spannendsten Technologien im Java Umfeld. Mit einem JNDI Lookup können von der Laufzeitumgebung verwaltete Resourcen geladen werden. Die Idee dahinter ist sehr einfach – die Laufzeitumgebung kümmert sich um das Instanzieren der benötigten Klassen und stellt diese der Applikation bereit.

Damit die hier vorgestellte Applikation JNDI unterstützt müssen einige Tätigkeiten durchgeführt werden. Im ersten Schritt ist es erforderlich dass im Verzeichnis src > main eine Unterverzeichnis namens webapp und darin in Unterverzeichnis namens WEB-INF angelegt wird. Im Verzeichnis src > main > webapp > WEB-INF ist es nur erforderlich eine Datei namens web.xml anzulegen.

Verzeichnisstruktur

Verzeichnisstruktur für web.xml

Jene Resourcen die mittels JNDI verwaltet werden, müssen in der Datei web.xml als Resource Reference (resource-ref) angeführt werden. Darin muss der Name (res-ref-name) definiert werden unter dem die Resource angesprochen wird sowie die dahinterliegende Java Klasse (res-type) auf die typisiert wird.

 

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<resource-ref>
<res-ref-name>jdbc/DefaultDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
</resource-ref>
</web-app>

Spring Data Dependency deklarieren

Damit ist der erste Schritt bereits erledigt. Nachdem wir den Zugriff auf die Datenbank nicht mittels SQL Kommandos selbst implementieren, sondern auf Spring Data zurückgreifen, muss im pom.xml noch eine entsprechende Dependency definiert werden.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Nachdem Spring Data eine Vielzahl an Datenbanken unterstützt ist es erforderlich, der Laufzeitumgebung mitzuteilen welche Datenbank zu verwenden ist. Das passiert über die Datei application.properties. Falls diese noch nicht existiert muss sie im Verzechnis src > main > resources angelegt werden. Der vollqualifizierte Klassenname des HANA Treibers lautet com.sap.db.jdbc.Driver

spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.HANAColumnStoreDialect
spring.jpa.properties.hibernate.connection.pool_size = 10
spring.datasource.driverClassName=com.sap.db.jdbc.Driver

@Configuration

Spring @Configuration-Annotation ist Teil des Spring Core Frameworks. Die Spring-Annotation weist darauf hin, dass die Klasse über eine @Bean-Definitionsmethoden verfügt. Der Spring-Container kann dadurch die Klasse verarbeiten und Spring Beans zur Laufzeit generieren, die in der Anwendung verwendet werden können.

Für die Verwendung im Neo Stack muss die Datasource mittels JNDI geladen werden. Dazu muss eine entsprechende Klasse erstellt werden. Ich nachfolgenden Code-Snippet wird die vollständige Klasse dargestellt.

Neo Datasource Configuration
package at.clouddna.demo;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.jdbc.datasource.lookup.JndiDataSourceLookup;

import javax.sql.DataSource;
import java.sql.SQLException;

@Configuration
@Profile({"neo"})
public class NeoConfig 
{	
	@Bean(destroyMethod="")
	public DataSource jndiDataSource() throws IllegalArgumentException, SQLException
	{
		JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
		DataSource ds = dataSourceLookup.getDataSource("java:comp/env/jdbc/DefaultDB");
		return ds;
	}
}

Der JNDI-Lookup zielt auf den Namen java:comp/env/jdbc/DefaultDB ab. Der Prefix java:comp/env/ ist in der SAP Cloud Platform immer derselbe. Der dahinter definierte Name jdbc/DefaultDB entspricht dem res-ref-name in der web.xml

Entwicklung einer Entity-Klasse

Die Verwendung von Spring-Data ermöglicht eine sehr effiziente Entwicklung der Persistenzschicht. Spring-Data basiert auf dem Hibernate Framework. Sobald wir eine Klasse anlegen und diese mit der Annotation @Entity versehen, wird auf der darunterliegenden Datenbank eine zugehörige Tabelle angelegt. Im nachfolgende Code-Snippet zeige ich Ihnen eine einfach User Klasse.

User.java
package at.clouddna.demo.model;

import javax.persistence.*;

@Entity
public class User {

    @Column(nullable = false)
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    protected Long id;

    private String firstname;
    private String lastname;

    public Long getId() {
        return this.id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public void setFirstname(String firstname) {
        this.firstname = firstname;
    }

    public String getFirstname() {
        return this.firstname;
    }

    public void setLastname(String lastname) {
        this.lastname = lastname;
    }

    public String getLastname() {
        return this.lastname;
    }
}

CRUD Methoden

Das geniale an Spring-Data ist die Out-of-the-box Verfügbarkeit von CRUD Methoden. Dazu muss lediglich ein Interface erstellt werden das vom JpaRespository erbt. Dies wird für die User Entity im nachfolgenden Code-Snippet dargestellt.

package at.clouddna.demo.repository;

import at.clouddna.demo.model.User;

public interface IUserRepository extends JpaRepository<User, Long> {

}

Das Respository kann nun direkt im Controller verwendet werden indem über Autowiring darauf zugegriffen wird. Mein Unternehmen sieht davon jedoch ab. Wir erstellen für jede Entity-Klasse immer ein zugehöriges DTO (Data Transfer Object) und erstellen zusätzlich eine Serivce-Klasse, die mit der @Service Annotation versehen wird, welche die Verwendung des Repository kapselt. Die Service-Klasse kann im Controller über die @Autowired Annotation injiziert werden.

Selbstverständlich zeige ich Ihnen wie das funktioniert.

ServiceBase Klasse und Model Mapper

Das Mapping der Entity-Klasse auf das DTO und umgekehrt führen wir nicht manuell sondern mittels ModelMapper durch. Der Modelmapper muss ins pom.xml als Dependency aufgenommen werden.

<dependency>
<groupId>org.modelmapper</groupId>
<artifactId>modelmapper</artifactId>
<version>2.3.5</version>
</dependency>
ServiceBase.java
package at.clouddna.codegenerator.service.da;

import org.modelmapper.ModelMapper;
import org.modelmapper.convention.MatchingStrategies;

import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Collection;
import java.util.List;
import java.util.stream.Collectors;

public abstract class ServiceBase {

    private ModelMapper modelMapper;

    public ServiceBase(){
        this.modelMapper = new ModelMapper();
        this.modelMapper.getConfiguration().setMatchingStrategy(MatchingStrategies.STANDARD);
    }

    public <D, T> D map(T entity, Class<D> outClass) {
        return modelMapper.map(entity, outClass);
    }

    public <D, T> List<D> mapAll(Collection<T> entityList, Class<D> outCLass) {
        return entityList.stream()
                .map(entity -> map(entity, outCLass))
                .collect(Collectors.toList());
    }

    protected void writeToFile(String fileName, String content) throws IOException {
        FileOutputStream outputStream = new FileOutputStream(fileName);
        byte[] strToBytes = content.getBytes();
        outputStream.write(strToBytes);
        outputStream.close();
    }

    protected void writeToFile(String fileName, byte[] content) throws IOException {
        FileOutputStream outputStream = new FileOutputStream(fileName);
        outputStream.write(content);
        outputStream.close();
    }
}

Service Klasse

Die Service Klasse erbt von der ServiceBase Klasse und kapselt den Zugriff auf die Datenbank. Nachfolgendes Code-Snippet zeigt die UserService Klasse. Wichtig ist dabei dass die Klasse mit der Annotation @Service versehen wird. Dadurch kann sie im Controller mittels Autowiring verwendet werden.

UserService.java
package at.clouddna.demo.service;

import at.clouddna.demo.dto.UserDto;
import at.clouddna.demo.model.User;
import at.clouddna.demo.respository.IUserRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;
import java.util.Optional;

@Service
public class UserService extends ServiceBase {

    @Autowired
    private IUserRepository repository;

    public UserDto create(UserDto userDto) {
        return map(repository.save(map(userDto, User.class)), UserDto.class);
    }

    public UserDto update(UserDto userDto) {
        return map(repository.save(map(userDto, User.class)), UserDto.class);
    }

    public boolean delete(Long id) {
        repository.deleteById(id);
        return true;
    }

    public UserDto findById(Long id) {
        Optional<User> userOptional = repository.findById(id);
        if(!userOptional.isPresent()) {
            return null;
        }
        return map(userOptional.get(), UserDto.class);
    }

    public List<UserDto> findAll() {
        return mapAll(repository.findAll(), UserDto.class);
    }
}

RestController

Abschließend zeige ich Ihnen wie der zuvor entwickelte Service im RestController vollumfänglich für alle CRUD-Methoden verwendet werden kann. Sie werden überrascht sein wie einfach das möglich ist!

UserController.java
package at.clouddna.demo.controller;

import at.clouddna.demo.dto.UserDto;
import at.clouddna.demo.model.User;
import at.clouddna.demo.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping
    public ResponseEntity getAll() {
        return ResponseEntity.ok(userService.findAll());
    }

    @GetMapping("/{id}")
    public ResponseEntity getById(@PathVariable("id") Long id) {
        return ResponseEntity.ok(userService.findById(id));
    }

    @PostMapping
    public ResponseEntity create(@RequestBody UserDto body) {
        return ResponseEntity.ok(userService.create(body));
    }

    @PutMapping("/{id}")
    public ResponseEntity update(@PathVariable("id") Long id,
                                 @RequestBody UserDto body) {
        body.setId(id);
        return ResponseEntity.ok(userService.update(body));
    }

    @DeleteMapping("/{id}")
    public ResponseEntity delete(@PathVariable("id") Long id) {
        return ResponseEntity.ok(userService.delete(id));
    }
}

Fazit

Ich hoffe dass ich Ihnen in diesem Teil die Java Entwicklung in der SAP Cloud Platform schmackhaft gemacht habe. Wie Sie hoffentlich erkannt haben handelt es sich um kein Hexenwerk und keine Weltraumwissenschaft. Einen Tipp möchte ich Ihnen noch mitgeben – achten Sie bereits in der Planung des Projekts darauf dass alles sauber strukturiert ist und Sie jeweils ein eigenes Paket für Entity, DTO, Repository, Service und Controller definieren.