Möglichkeiten für ein SSO am SAP Fiori Client auf mobilen Geräten

Einleitung

Mit der mobilen App SAP Fiori Client bietet SAP eine erweiterte mobile Laufzeitumgebung, für die heute über 1.000 SAP-Fiori-Anwendungen zur Verfügung stehen. Sehr oft findet beim Einsatz des SAP Fiori Client die Authentifizierung manuell mit Eingabe von SAP Benutzer und Kennwort statt, da hier eine vollautomatische Authentifizierung (Single Sign-On) nicht so einfach umsetzbar ist, wie beispielsweise beim Zugriff über den mobilen Browser. Mehr dazu aber später.

Im Gegensatz zu Cloud-Apps basieren Unternehmensanwendungen wie SAP Fiori auf Benutzern, die das Unternehmen meist selbst verwaltet. Hier zum Beispiel die SAP-Konten der Anwender auf den SAP Fiori Front-End- sowie Backend-Servern. Natürlich können die Zugangsdaten statisch durch den Benutzer in der App hinterlegt und sogar mit Biometrie geschützt werden. Fallen hier jedoch Passwortwechsel an, so kann das Arbeiten auf dem mobilen Gerät recht schnell mühselig werden. Oft wird auf dem Desktop bereits Single Sign-On genutzt (SAP Logon & Browser). Somit kennen Anwender häufig Ihr Kennwort gar nicht mehr.
 

Sicherer Betrieb der mobilen Infrastruktur

In den meisten Unternehmen gehört der Einsatz verschiedenster mobiler Geräte wie Smartphones und Tablets zum normalen Arbeitsalltag. Genauso normal sollte dabei der sichere Betrieb, die zentrale Verwaltung der Geräte- und Sicherheitsrichtlinien sowie App-Deployments und der damit verbundene Einsatz zusätzlicher Infrastrukturkomponenten sein. Spätestens ab einer bestimmten Unternehmensgröße bzw. einem entsprechend hohen Nutzungsgrad mobiler Anwendungen wird dies unverzichtbar.

Mobile Device Management (MDM)-Infrastrukturen stellen oft auch Möglichkeiten für ein Single Sign-On bereit, sei es direkt vom Gerät oder delegiert über ein zentrales SSO-Gateway. Darüber kann zum Beispiel eine gesicherte Sandbox-Umgebung auf die mobilen Geräte gebracht werden. Diese ermöglicht den Zugriffsschutz mittels einer durch den Benutzer vergebenen PIN und gleichzeitig eine Anmeldung an einem SAML Identity Provider. Ein Unternehmen kann damit seine geschäftlichen Anwendungen innerhalb dieser Sandbox isoliert vom restlichen Gerät betreiben und Anwendungszugriffe mittels Micro-VPNs gezielt steuern. Schnittstellen an eine Corporate-PKI ermöglichen die Bereitstellung von personalisierten Client-Authentication-Zertifikaten auf den Geräten.

iOS gilt dabei als das sicherste mobile Betriebssystem der Welt. Im Umfeld SAP-Security habe ich die Erfahrung gemacht, dass iOS den besten Support genießt. Das iOS-Gerät ist als Einzelbenutzergerät konzipiert. Bei anderen mobilen Betriebssystemen – wie Android – wird Multi-User-Support und Benutzerwechsel schon lange unterstützt. Generell werden mobile Geräte meist nah am Anwender getragen bzw. verwendet und sperren sich bei korrekter Sicherheitskonfiguration zügig. Aufgrund der unterschiedlichen Architekturen und auf Basis eventuell bereits vorhandener Lösungen sowie eingesetzter Apps, sollte sehr differenziert unterschieden werden, welches Verfahren für SSO im Unternehmen bestenfalls zum Einsatz kommen kann.

Möglichst sicher, jedoch auch komfortabel sollte es sein. Denn nichts ist schlimmer, als andauernd wieder seine Zugangsdaten manuell eintippen zu müssen. In dieser Hinsicht unterscheidet sich das mobile Gerät deutlich vom klassischen Desktop. Es findet hier ja keine Anmeldung am Active Directory statt. Man startet bzw. entsperrt mobile Geräte meist mit biometrischen Verfahren sowie einer Kombination aus verschiedenen Codes bzw. Wischgesten.

Dank der Biometrie kann – im Vergleich zur PIN – der tatsächliche Anwender am Gerät erkannt werden; die Geräte wurden personalisierbar und intelligenter. Es macht also Sinn, die biometrischen Verfahren als einen Faktor im Authentifizierungsprozess zu berücksichtigen.  

MDM, Sandboxing, Micro-VPNs, SSO-Gateway, SDKs, Entwickler. Das alles ist in kleineren Unternehmen nicht unbedingt immer vorhanden. Dennoch können auch hier mit überschaubarem technischem und organisatorischem Aufwand unterschiedliche SSO-Szenarien auf den vorhandenen mobilen Geräten eingesetzt werden. Einige davon möchte ich in diesem Blog vorstellen; dies mit Fokus auf den SAP Fiori Client.

Sie werden erfahren, wie man mit SAP Single Sign-On 3.0 die SAML-Integration des SAP Fiori Client realisiert und darüber die OTP-basierte Authentifizierung mithilfe des SAP IdP und der SAP Authenticator-App ermöglicht. Zudem möchte ich auch über eine recht neue Möglichkeit der zertifikatsbasierten Anmeldung – direkt aus der Fiori-App heraus – informieren.
 

SSO-Verfahren im mobilen Umfeld

Authentifizierung an einer nativen Mobilanwendung ist eine große Herausforderung, da es keinen definierten Standard gibt, an den sich Entwickler halten müssen. Da stellt sich zunächst die Frage, welche SSO-Verfahren werden im mobilen Umfeld verwendet. Die kurze Antwort lautet: eine ganze Menge!

Cloud-Apps wie Instagram, Deezer, YouTube, Facebook und Konsorten nutzen meist das OAuth-Verfahren. Dabei verwaltet der Anbieter den Account (nicht das eigene Unternehmen) und daher greifen auch andere Passwortrichtlinien bzw. Wechselanforderungen. Zudem wird hier der Anmeldeprozess, meist gegen einen Authorization-Server/IdP in der Cloud, in der Regel einmalig beim Start der App durchgeführt. Anschließend sorgen OAuth Access- und Refresh Tokens transparent und automatisiert für alles weitere. OAuth 2.0 hat sich als standardisiertes Protokoll herauskristallisiert, um genau diese stark vereinfachte Authentifizierung (und Autorisierung) von nativen mobilen Anwendungen (Apps) zu ermöglichen. Die Idee besteht darin, jede Anwendung einzeln zu behandeln. Sie wird einzeln autorisiert und empfängt Ihre OAuth-Tokens, welche für nachfolgende API-Aufrufe notwendig sind.

Wird die Anwendung innerhalb der Lebensdauer des Refresh Token regelmäßig genutzt und steht somit in Kontakt mit dem Server, erhalten die Anwender laufend aktuelle Zugangstoken. Der Anbieter kann mit OAuth (ähnlich wie mit SAML) zudem ein Single Log-out unterstützen, z. B. wenn das mobile Gerät gestohlen wurde und der Account bewusst deaktiviert wurde.

Unter anderem auch die SAP Cloud Platform unterstützt das OAuth 2.0-Protokoll als Methode zum Schutz von Anwendungsressourcen.

Auch der Einsatz von Kerberos auf mobilen Geräten ist technisch machbar und wird zum Beispiel auf iOS-Geräten direkt unterstützt. Der Anwenderkomfort ist ohne weitere Komponenten aber eher gering. Das liegt daran, dass am Gerät ja mangels einer AD-Anmeldung keine Credentials vorliegen und somit die erste Authentifizierung mit AD Benutzername und Kennwort manuell am Gerät erfolgen müsste. Dabei werden dann TGT und STs bezogen. Das ist manchmal schon zu viel des Guten für den normalen Anwender. Angenehmer wird es erst mit Lösungen wie von MobileIron oder Citrix XenMobile, nur um einmal zwei Beispiele zu nennen. Solche Anbieter bringen spezielle sicherere Browser oder E-Mail Clients mit sich. Mit diesen können Unternehmensressourcen sicher angebunden und der Datenverkehr kann über VPNs getunnelt werden. Zudem muss sich der Anwender nur einmal beim Start der App anmelden und hat anschließend transparenten Zugriff auf interne Webanwendungen.

Android Enterprise kann mit Lösungen wie Hypergate um diesen Support erweitert werden. Somit könnte SSO für alle bestehenden Webanwendungen eines Unternehmens, wie vom Desktop gewohnt, über den mobilen Browser eingesetzt werden. Selbst native Apps können mit bestimmten Libraries und SDKs integriert werden. Auch der mobile Browser Microsoft Edge für iOS und Android unterstützt ein SSO für SaaS oder on-premise Anwendungen, sofern das Gerät in Azure AD registriert wurde.

OAuth / OpenID, Kerberos, SAML, X.509 Zertifikate sowie SSO-Gateways, MFA, PINs, Biometrie und Kennwörter… die Möglichkeiten sich mit mobilen Geräten an Unternehmens- bzw. Cloudanwendungen zu authentifizieren sind vielfältig und die Technologie dahinter ist oft komplex.
 

SAP Authenticator | SSO Authentication Library | SAP Identity Provider

Die SAP Authenticator-App ist für die Plattformen iOS, Android und Windows verfügbar. Er generiert nach Registrierung mit der SAP zugehörigen Backend-Komponente zeitbasierte Einmalpasswörter. Diese können, wie zum Beispiel vom Google Authenticator bekannt, als Passwortersatz oder zweiter Faktor genutzt werden. Basierend auf einem gemeinsamen Geheimnis und aktueller Systemzeit, wird alle 30 Sekunden ein 8-stelliger nummerischer Code generiert. Somit müssen Anwender Ihre regulären (statischen) Anmeldeinformationen nicht preisgeben. Folglich ist darüber die sichere Authentifizierung an kritischen on-premise Anwendungen bzw. der Zugriff auf exponierte Anwendungen möglich.

Neben diesem Einsatzszenario bietet der SAP Authenticator auch die Möglichkeit eines zentralen Einstiegspunktes für den mobilen Zugriff auf weitere SAP-Unternehmensanwendungen wie u. a. SAP Fiori Client. Mittels der zentralen OTP-Administrationskonsole können entsprechende Anwendungsprofile erstellt und automatisiert an alle mobilen Anwender bereitgestellt werden. Diese Profile enthalten angepasste Anwendungs-URLs und starten entweder native Apps, wie z. B. den SAP Fiori Client, oder öffnen eine festgelegte URL im Browser auf dem mobilen Gerät. Gleichzeitig wird das Einmalpasswort als Parameter zur Authentifizierung mitgegeben. Es ist zudem möglich, das Einmalpasswort als einzigen Faktor zur Anmeldung zu verwenden, worüber letztlich dann ein komfortables Single Sign-On ermöglicht wird. Der Start der SAP Authenticator-App selbst kann dabei mit einem PIN bzw. Kennwort geschützt werden.

Da dieses Szenario auf Einmalpassworten und SAML 2.0 sowie ausschließlich SAP-Komponenten basiert, benötigt man dafür auch zwingend den SAP Identity Provider. Technisch gesehen erfolgt die Authentifizierung am Identity Provider mit Einmalpassworten und die darauffolgende Authentifizierung am SAP Fiori Front-End Server mittels SAML 2.0. Für den SAML-Flow sorgen die in den Tools integrierten Browser-Engines.

Security Assertion Markup Language (SAML) ist ein dynamisches Token Modell und arbeitet auf der Grundlage von Behauptungen (sog. Assertions). Die zentrale Instanz, ein Identity Provider (IdP) belegt, dass sich ein Subjekt (User) erfolgreich ausgewiesen hat und eine Assertion bietet Platz für viele weitere Attribute, die von vertrauenden Systemen (sog. Service Provider) ausgewertet und zur Authentifizierung aber auch zum Zwecke der Federation genutzt werden können.
 

Funktionsweise

Mit dem Einsatz der zuvor genannten Komponenten aus der Lösungssuite SAP Single Sign-On 3.0 können die vom SAP Authenticator generierten Einmalpassworte zur Anmeldung am SAP IdP verwendet werden. Nur mit Deployment der SSO Authentication Library wird der SAP IdP um das TOTPLoginModule erweitert. Dabei basiert die eingesetzte OTP-Technik auf dem von der IETF im RFC6238 spezifizierten TOTP-Algorithmus.

Der SAP-Authenticator generiert ein neues Einmalpasswort und sendet es zusammen mit dem Benutzernamen an die im Profil hinterlegte Anwendung, welche die Parameter in der vorkonfigurierten SAP Fiori Client-URL verwendet. Der SAP Fiori Client generiert daraufhin eine Authentifizierungsanforderung an den SAP Identity Provider, was ein sogenanntes „Identity Provider initiated SSO“ auslöst. Der Identity Provider überprüft die Anmeldeinformationen und wenn die Prüfung erfolgreich ist, erstellt er in der SAML AuthnResponse eine Assertion für diesen Benutzer. Der SAP Fiori Client (oder Browser) wird geöffnet und der Benutzer ist automatisch und sicher angemeldet; ein entsprechend für SAML 2.0 konfigurierter SAP Fiori Front-End Server vorausgesetzt. Dieses Szenario eignet sich auch hervorragend für den externen Zugriff auf SAP Webanwendungen, die zum Beispiel durch einen SAP Web Dispatcher veröffentlicht wurden.

An dieser Stelle sei nochmals angemerkt, dass für dieses Szenario keine vorhandenen Identity Provider wie Microsoft ADFS/Azure, BIG-IP, Open AM, Shibboleth und andere eingesetzt werden können.

Anwender-Zertifikate auf mobilen Geräten

Für Zugriffe auf SAP-Webanwendungen von mobilen Geräten aus, empfiehlt sich in der Regel der Einsatz von X.509 Zertifikaten. Durch Integration der MDM-Lösung in eine vorhandene PKI, lassen sich mittels SCEP automatisiert Anwender-Zertifikate auf die Geräte verteilen. Abgesehen von speziellen Sandboxing Umgebungen, speziellen Browsern oder herstellerspezifischer Eigenentwicklungen, steht dieses Zertifikat (inkl. des zugrundeliegenden privaten Schüssels) zum Beispiel in der iOS System key-chain zur Verfügung. Damit können die Apple eigenen bzw. systemnahen Anwendungen wie Mail oder Safari auf dieses Zertifikat zugreifen. Das Zertifikat könnte somit bei einem direkten Zugriff auf entsprechend konfigurierte Web Dispatcher / SAP Backends wie gewohnt zur Authentifizierung eingesetzt werden. Einem Single Sign-On am Portal oder dem zentralen SAP Fiori Launchpad über den Safari Browser steht somit nichts im Wege.

Apps wie der SAP Fiori Client und andere, können aufgrund des im iOS verwendeten Sandboxing-Prinzips nicht auf die Zertifikate und Schlüssel des Systemschlüsselbundes zugreifen. Hier braucht es dann wieder SDKs bzw. Custom-App-Deployments, die in Verbindung mit dem SAP Mobile Platform Server bzw. der SAP Cloud Lösung zusätzliche Optionen für eine automatische Authentifizierung bereitstellen.

Ab Version 1.12.2 des SAP Fiori Client kann nun aber auch die System-Keychain eines iOS Geräts verwendet werden. Technisch wird der Zugriff auf vorhandene Anwender-Zertifikate und Schlüssel über den SFSafariWebView Controller realisiert. Ergebnis ist die Nutzung der auf dem Gerät befindlichen Zertifikate analog zur Möglichkeit wie dies bisher im Safari machbar war. Sofern sich bereits Zertifikate auf dem iOS Gerät befinden, stellt dieses Feature eine einfache Möglichkeit für eine automatische Authentifizierung am SAP Fiori Client zur Verfügung.

In diesem Szenario wird weder die SAP Mobile Platform Lösung noch der SAP Identity Provider oder SAP Authenticator benötigt.

Eine Auflistung unterstützter mobiler Geräte- und Betriebssysteme ist dem SAP Hinweis 2253818 zu entnehmen. Hilfreiche Informationen rund um den SAP Fiori Client sowie weitere unterstütze Single Sign-On Szenarien, zum Beispiel in Verbindung mit der SAP Mobile Platform, finden Sie hier und hier.

Xiting hat bereits mehrere Unternehmen bei der erfolgreichen Umsetzung einer SSO-Lösung für den SAP Fiori Client unterstützt.

Gerne unterstützen wir Sie in Ihrem Projekt!