(Last Updated On: 6. Juli 2017)

Machen Sie sich Gedanken um die Implementierung von Single Sign-On? Dann werden Sie zweifelsfrei schon die Begriffe SAML und OAuth2 gehört haben. Nicht nur in der Web-Entwicklung, sondern auch in der SAP-Welt rücken diese Technologien mehr und mehr in den Vordergrund. Aus alten Zeiten sind hier eher noch X.509-Zertifikate oder die Kerberos-Authentifizierung in der Vorreiter-Rolle.

Kerberos – Weiterhin interessant, aber nicht für die Cloud

Kerberos funktioniert ähnlich wie SAML 2.0 und OAuth2, wie wir später in diesem Beitrag noch sehen werden. SAML und OAuth2 vergeben sogenannte Assertions, Kerberos vergibt Tickets. Beide haben jedoch technisch die selbe Bedeutung. Es handelt sich um Dateipakete, die Sicherheits-Informationen enthalten. Diese Sicherheits-Bürgschaften sichern dem jeweiligen Inhaber zu, dass er eine bestimmte Identität und damit auch gewisse Rechte besitzt. Diese Bürgschaften frägt der Client von einem zentralen Server an.

Kerberos wird weiterhin interessant bleiben. Und zwar zur Authentifizierung innerhalb eines Unternehmens-Netzwerk. Wenn das Unternehmen ohnehin schon beispielsweise eine Microsoft Active Directory Struktur nutzt, ist die Kerberos-Infrastruktur schon mit dabei. Es gibt also keinen Grund, diese Kerberos-Infrastruktur nicht zu nutzen. Kerberos hat sich in den letzten Jahren als stabil und zuverlässig erwiesen.

Dennoch ist Kerberos aus genau diesem Grund für einen Single Sign-On Prozess über das Internet weniger interessant. Das System, welches das Kerberos-Ticket anfrägt, muss im gleichen lokalen Netzwerk sein wie der Kerberos Ticket Granting Server. Das heißt während man also beispielsweise noch ein von außen über VPN erreichbares Intranet-Portal weiterhin über Kerberos abwickeln kann, bekommt man bei Systemen in der Cloud schon wieder Probleme.

Immer mehr Unternehmen lagern bestimmte IT-Services in die Cloud aus. In der SAP-Welt sind dies beispielsweise Dienste wie Concur, SuccessFactors oder C4C. Diese Cloud-Dienste sind eben nicht beispielsweise über VPN in das lokale Firmen-Netzwerk integriert, sondern nur über das öffentliche Internet erreichbar. Daher befinden sich diese Systeme nicht in der selben Kerberos Domain wie der Kerberos Ticket Granting Server des Unternehmens. Somit steht der Single Sign-On Prozess über Kerberos hierfür nicht zur Verfügung.

Verstehen Sie mich nicht falsch: Das heißt nicht, dass Sie Ihr LDAP-Verzeichnis bzw. Ihr Active Directory nicht weiterhin als zentralen Ablageort für Anmeldeinformationen verwenden können. Sie müssen in dem Fall den zentralen Identity Provider von SAML bzw. OAuth2 nur mit dem LDAP-Verzeichnis verbinden und sich der Tatsache bewusst sein, dass der zentrale Identity Provider nach außen hin offen liegt.

SAML und OAuth2: Ähnliche Infrastruktur

SAML und OAuth2 haben eine ähnliche Infrastruktur.

• Beide nutzen wie Kerberos einen Server, welcher Sicherheits-Bürgschaften ausstellt. Unter SAML heißt dieser Service einfach nur Identity Provider Server, unter OAuth 2.0 heißt er Authorization Server. Dieser Server enthält sämtliche gespeicherten User-Identitäten und deren Identitätsmerkmale (Passwörter u. Ä.).
• Der Client, also der User, besucht ein System, von welchem er etwas möchte. Das kann beispielsweise ein System in der Cloud sein. Dieses System wird unter SAML Service Provider und unter OAuth2 Resource Server genannt. Dieses System wurde so konfiguriert, dass es die Authentifzierung von Benutzern nicht selbst abwickelt. Stattdessen erstellt dieses System nun einen Auth Request, unterschreibt und verschlüsselt diesen und leitet den User mit diesem Request an den eigentlichen Identity Provider weiter.
• Der Identity Provider nimmt den Auth Request und prüft, ob er von einem System kommt, welches der Identity Provider kennt. Ist dies der Fall, bekommt der User eine Eingabemaske für seine Logindaten.
• Der User gibt in dieses Formular seine Zugangsdaten ein. Der Identity Provider prüft, ob diese Zugangsdaten mit den Daten übereinstimmen, die für diesen User hinterlegt sind. Trifft dies zu, stellt der Identity Provider dem User einen Token aus. Dieser Token enthält Informationen über den User, beispielsweise seinen Usernamen, seine E-Mail-Adresse und seine Credentials (letzteres nur SAML). Der Identity Provider leitet diesen SAML Token und leitet ihn an das System weiter, welches der User eigentlich besuchen möchte.
• Das zu besuchende System prüft den SAML Token. Stammt dieser nachweislich vom Identity Provider, ist dieser gültig. Bei einem gültigen SAML-Token loggt das System den User nun erfolgreich ein. In einer Web-Applikation wird hierzu beispielsweise häufig ein Cookie oder eine Session genutzt. Solange der User das Cookie bzw. die Session besitzt, muss kein neues SAML-Token angefragt werden.

SAML gegen OAuth2 – Vorteile und Nachteile

Beide nutzen also eine ähnliche Struktur. Der Teufel liegt hier im Detail. Während SAML längere Nachrichten über eine HTTP POST Message schicken muss, kann OAuth2 diese Nachrichten auch über URL-Parameter versenden. In der Praxis bedeutet dies, dass OAuth2 in der Entwicklung es leichter von der Hand geht, wenn Mobile Apps damit angebunden werden sollen. Denn unter OAuth2 muss man kein Handling für das „Abschicken eines Formulars“ implementieren. Jedoch funktionieren beide Standards mit ausreichendem Entwickler-Wissen problemlos.

Ein wichtiger Punkt, den es noch zu erwähnen gilt: Der SAML Token entählt die Identitäts-Informationen des Benutzers. Der OAuth2-Token hingegen verlangt standardmäßig keine Signierung des Tokens. Dies kann jedoch konfiguriert werden, so dass der Resource Server nach Erhalt des Tokens noch einmal beim Authorization Server nachfrägt, ob der Token auch wirklich von ihm kommt. In diesem Fall prüft der Authorization Server dann die Signatur des Tokens. Ist dies der gleiche Token, den er kürzlich ausgestellt hat, bestätigt der Authorization Server und der Resource Server winkt den User-Login durch. Der Nachteil bei OAuth2 ist hier, dass im Vergleich zu SAML ein zusätzlicher Round-Trip notwendig ist, um die Anmeldung zu bestätigen.

Der zentrale Mehrwert von OAuth2

OAuth2-Token haben jedoch einen anderen Vorteil. Der OAuth2-Token enthält, im Gegensatz zum SAML-Token, nicht die Credentials des Benutzers. Der Vorteil: Die Credentials sind ausschließlich beim Authorization Server und nicht noch einmal zusätzlich an dritter Stelle irgendwo hinterlegt.

Stellen Sie sich folgendes Szenario vor: Bob kann mit seinen Anmeldeinformationen sich einmal an einem sehr vertraulichen SAP-System über eine Desktop-App (z. b. SAPGui) anmelden und hat dort ausschweifende Berechtigungen. Bob verwendet außerdem eine Mobile App, mit der er Urlaubsanträge genehmigt. Der Security Officer wäre von Natur aus sehr empfindsam, wenn sich Bob mit den selben Zugangsdaten auf der App für Urlaubsanträge anmeldet. Denn die Mobile App erfüllt nicht die selben Sicherheits-Standards wie das SAP-System von Bob.

Knackt jemand die App für Urlaubs-Anträge, wäre es einem Angreifer möglich, die Token abzugreifen, die Bob dem Urlaubs-System schickt. Da im OAuth2-Token jedoch keine Anmeldeinformationen gespeichert sind, helfen dem Unbefugten diese Daten nichts. Er erlangt dadurch keinen Zugriff auf das SAP-System. wird nun der unbefugte Zugriff erkannt, kann der OAuth2-Token für das Urlaubssystem einfach im Authorization Server gesperrt werden und der Angreifer fliegt aus dem Urlaubs-System heraus. Bob merkt davon nichts, weil der Administrator Bob’s Passwort nicht ändern muss – denn der Angreifer hat von diesem keine Kenntnis erlangt. Der Administrator schließt die Sicherheits-Lücke des Urlaubs-System bzw. auf der Mobile App und Bob kann weiter arbeiten wie bisher. Aufgrund dieser Eigenschaft wird OAuth2 aktuell verstärkt im SAP NetWeaver Gateway implementiert.

Beide Token-Verfahren sind sicherer als traditionelle Anmeldeverfahren

Grundsätzlich ist OAuth2 ein neuerer Standard (2012) als SAML 2.0 (2005). Dies sollte aber keine allzu große Rolle bei der Frage nach der Implementierung spielen. Beide Standards funktionieren zuverlässig und stabil und erhöhen in jedem Fall die Sicherheit im Vergleich zu einer hash-basierten Speicherung von Credentials in der Datenbank einer Webanwendung. Denn die Anmeldeinformationen sind nur beim zentralen Identity Provider bzw. Authorization Server hinterlegt und nicht in der Anwendung. Hat die Anwendung also eine bekannte Sicherheitslücke, erhält der Angreifer nicht gleich den Zugang zu den Zugangsdaten des Benutzers. Im Fall von SAML  muss der Angreifer erst einen SAML-Token abfangen, im Fall von OAuth2 hat er sogar gänzlich Pech gehabt.

Die beiden OAuth 2.0 Flows im SAP NetWeaver ABAP

Die OAuth2 Implementierung des SAP NetWeaver AS ABAP unterstützt aktuell zwei Abläufe für die Authentifzierung nach OAuth 2.0 Spezifikation.

• Der SAML 2.0 Bearer Assertion Flow basiert allein auf der Konfiguration des Administrators und ist gut geeignet für den serverseitigen Konsum von Java Servlets, WebDynpros, BSPs, JSPs, ASP und Batch-Jobs.
• Der Authorization Code Flow benötigt zusätzlich zur Vorkonfiguration des Administrators außerdem eine Genehmigung des „Resource Owners“ und ist somit interaktiv. Dieser Fluss implementiert also ein Genehmigungsverfahren. Damit eignet sich dieses Verfahren sehr gut für den interaktiven Konsum von clientseitigen Applikationen. Alles, was also ein „Rumgeklicke“ auf Seiten des Besuchers erfordert, sollte mit diesem Fluss abgebildet werden.

Andere Security-Artikel von mir:

• SAP S/4HANA Security in Verbindung mit der ISO 27001
• Security Weaver Produkte zur Verbesserung der Sicherheit Ihrer SAP-Systemlandschaft
• CyberSafe TrustBroker als Lösung für Single Sign-On und Mehr-Faktor-Authentifzierung im SAP-Umfeld
• Konsequent 2-Faktor-Authentifizierung (2FA, MFA) nutzen
• IT Security – wie geht’s weiter nach den Babyschritten?
• Mehr Security durch Passwortmanager wie KeePass
• Einführung in SAP Identity Management

 

 

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!