JCON 2018, Düsseldorf: Vortrag von Christian Fritz (@chrfritz, Softwareingenieur bei QAware) Abstract: Durch die zusätzlichen Angriffsvektoren in der Cloud spielt Sicherheit im Cloud-Native-Umfeld eine prominente Rolle. OpenID Connect und OAuth2 sind ausgereifte Standards zur Autorisierung von Benutzern. Aber: Nahezu alle Systeme benötigen Backend-Calls, für die diese Standards keine guten Antworten bieten. Diese werden bisher üblicherweise mit technischen Benutzern oder dem von OAuth2 bekannten ""client_credentials"" abgesichert, wobei der Benutzer-Kontext verloren geht. Als Lösung schlagen wir eine Erweiterung des OAuth2 Standards vor. Diese authentifiziert bei Service-zu-Service Aufrufen den Aufrufer, behält gleichzeitig den Benutzerkontext bei und prüft diesen. Wir setzen das mit einem neuen Grant-Type um, den der Authorization Server zur Verfügung stellt. Über diesen kann sich der aufrufende Service einen neuen Token für den Zugriff auf den benötigten Service holen. In diesem Vortrag wird das Problem erklärt, die Lösung beschrieben und es werden die Vorteile davon aufgezeigt.

1. Christian Fritz, QAware GmbH
christian.fritz@qaware.de
Sichere Backend-Calls mit
Nutzerkontext
Düsseldorf, 09. Oktober 2018

2. Um was geht
es denn?
Foto: AzmanJaka - gettyimages.de

3. QAware 3
Authentisierung, Authentifizierung und Autorisierung
sind keine Synonyme
Alice
https://www.datenschutzbeauftragter-info.de/authentisierung-authentifizierung-und-autorisierung/
Icons:Ticket by teleymon, Passport by monkik from the Noun Project, passport control by Bernar Novalyi, stadium by Made by Made, Economy Class by
mikicon from the Noun Project
Authentisierung Authentifizierung Autorisierung

4. QAware 4
Monolithische Systeme brauchen die Authentifizierung
und Autorisierung oft nur an einer Stelle durchführen.
Service
(GUI + REST)
Icons: passport control by Bernar Novalyi from the Noun Project

5. QAware 5
In verteilten Microservice-Architekturen muss jeder
Service die Autorisierung selbst durchführen.
Service C
(REST)
Service A
(GUI + REST)
Service B
(GUI + REST)
Service D
(REST)
Icons: passport control by Bernar Novalyi from the Noun Project

6. Wo ist
eigentlich
das
Problem?
Foto: skynesher - gettyimages.de

7. QAware 7
Alle Requests sind doch abgesichert.?
Basic Auth, Session,
OAuth2, OpenID Connect
Basic Auth (gleich wie
bei B)
Token
Service C
Service A
(GUI + REST)
Service B
(GUI + REST)
Service D
Basic Auth
Stimmt:
Weiß aber Service B immer welcher Benutzer für den
Aufruf zuständig war?

8. QAware 8
Wer kennt wann den Endnutzer?
Service C
Service A
(GUI + REST)
Service B
(GUI + REST)
Service D
Alice Bob

9. Gescheiterte
Lösungsversuche
Foto: sturti - gettyimages.de

10. QAware 10
Meist in Form von Application ID/Secret oder Benutzername/Passwort
Statische Zugangsdaten
Werden selten gewechselt
Sind möglicherweise an verschiedenen Services gültig
Keine explizite 1-1 Verbindung zwischen beteiligen Services durch die Authentifizierung
Basic Auth ist einfach; verliert aber den Nutzerkontext.

11. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiw
iaWF0IjoxNTM5MDk5OTI0LCJleHAiOjE1MzkxMDM1MjR9.
rcL8L8NuZ4TnuB2THrk5cw54gY1n6e8I1JcRtX4NS24
QAware 11
Definierbare Gültigkeitsdauer
Weitere Informationen einbettbar,
wie beispielsweise:
Identität des Endbenutzers
Identität des anfragenden
Services
Informationen zum angefragten
Service
Entweder mit Shared Secret oder
asymmetrischen Schlüsseln signiert
Shared Secret: Allen denen das
Secret bekannt ist können Token
erzeugen
Asymmetrische Schlüssel:
Aufwendige Verteilung der Public
Keys
Selbst generierte JSON Web Token sind schon besser.
{
"alg": "HS256",
"typ": "JWT"
}
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1539099924,
"exp": 1539103524
}
HMACSHA256( base64UrlEncode(header) + "." +
base64UrlEncode(payload), "secret")

12. QAware 12
Es sind vier Rollen beteiligte:
Resource Owner
Resource Server
Authorization Server
Client
Der Authorization Server stellt nach erfolgter
Authentifizierung und Autorisierung Access-Tokens an den
Client zum Zugriff auf den Resource Server aus.
Es gibt verschiedene Authorization Flows:
authorization_code
client_credentials
password
implicit
OAuth2 ist ein Standard zur sicheren Authentifizierung
von API Calls für Desktop, Web und Mobil-Applications.

13. QAware 13
authorization_code Flow von OAuth2 im Detail
Resource Owner Authorization Server Resource ServerUserAgent Webservice
GET /resource
Anfrage Resource GET /resource
HTTP 302 Authorization Request
Login FormularAnzeige Login Formular
Post Request & Authentifikation / AutorisationEingabe Login Daten
HTTP 302 Authorization Code
Authorization Code
GET /resource + access_token
POST Request
access_token
Senden & Anzeigen der Antwort

14. QAware 14
Nur zur Authentifizierung von Endbenutzern an Services
Zentraler Service für Tokens
Rudimentäre Unterstützung für Backend-Calls durch den client_credentials Flow
Token-Basiert
Keine Identität des Endbenutzers enthalten
Vergleichbar mit Basic Auth nur mit (kurzlebigen) Token
Auch das etablierte OAuth2 löst nicht alle Probleme.

15. QAware 15
{
"keys": [
{
"kid": "latest-key-id",
"alg": "RS256",
"kty": "RSA",
"e": "AQAB",
"use": "sig",
"n": "uDumfjVEoV..."
},
{
"kid": "next-key-id",
"alg": "HS256",
"kty": "oct",
"use": "sig",
"k": "wiPZsSrmmhyJ5019eKY0X6KLEImFkxeQu1aAdSpoHKM"
}
]
}
Endpunkte zur Abfrage der Identität
/userinfo
Eigener Identity-Token
JWT mit erweiterten Identitäts-
Informationen
Verteilung von Public-Keys zur
Signaturprüfung per JSON Web Key
Set (JWKS)
Automatische Client Registrierung
Optionaler Logout
Keine weiteren Authorization Flows
OpenID Connect als Erweiterung für OAuth2 hilft auch
nur bedingt weiter.

16. Die Lösung

17. QAware 17
Wir führen einen neuen Grant Type ein:
backend_access_token
Authorization Service
Perform OAuth2 / OpenID Connect Login
Return access_token
Request JSON Web Keys
JSON Web Key Set
do service request
+ access_token
response
backend_access_token
Request access_token with client credentials and ui access_token
Perform backend request with
backend_access_token
Response of
backend request
loop [For every backend service]
opt [If no valid backend_access_token]
[If key for kid is not cached]opt
UI Service A Backend Service

18. QAware 18
Basiert auf OpenID Connect / OAuth 2
Nutzt JSON Web Tokens zur Authentifizierung
Signaturprüfung durch Public Keys
Verteilung der Public Keys gemäß OpenID Connect über JSON Web Key Sets (JWKS)
Token Beantragung mit:
Client Credentials: Client ID und Client Secret
Erhaltenen Access Token (UI oder anderer Service)
Benötigtem Service
Gegebenenfalls notwendige Scopes
Inhalte:
Identität des Endbenutzers
Identität des aufrufenden Services
Information über den aufgerufenen Service
Erlaubte Scopes
Wir führen einen neuen Grant Type ein:
backend_access_token

19. {
"typ": "JWT",
"alg": "RS256", // Signatur Algorithmus
"kid": "latest-key-id" // Welcher Key wurde zur Signatur genutzt (ID)
}
{
"iss": "https://authorization-service.iam/", // Wer hat den Token ausgestellt
"sub": "ldap|254838", // für welchen Benutzer (ID) wurde der Token ausgestellt
"aud": [ // für welche Services ist der Token gültig
"service-b",
"https://authorization-service.iam/userinfo"
],
"iat": 1539099924, // Wann wurde der Token ausgestellt (09.10.2018 17:45:24)
"exp": 1539103524, // Bis wann ist der Token gültig (1 h)
"azp": "service-a", // Welcher Service hat den Token angefordert
"scope": "openid profile email customer creditcard-only“ // Welche Scopes (Rechte) sind erlaubt
}
QAware 19
Auch der backend_access_token ist ein JWT.
Nur mit mehr Inhalt:

20. QAware 20
Wer kennt wann den Endnutzer?
Service C
Service A
(GUI + REST)
Service B
(GUI + REST)
Service D
Alice Bob
Alice Alice
Alice
Bob

21. Stolperfallen
Foto: nicolamargaret - gettyimages.de

22. QAware 22
Erste Variante: Das IDM Anpassen.
Nicht immer Möglich
Erhöhter Wartungsaufwand für das IDM
Zweite Variante: Eigenen Token-Service entwickeln
Dieser muss das eigene JSON Web Key Set mit dem vom IDM mergen.
Alle Services müssen gegen dieses die Signaturen Validieren
Alle Services müssen dennoch den Token-Service als auch das IDM als Issuer akzeptieren
Der Token-Service muss Tokens vom IDM als auch eigene Token akzeptieren um neue Token
auszustellen.
Ein vorhandenes Identitäts-Management-System muss
auch eingebunden werden.

23. QAware 23
Caching um Anfragen an den Authorization Server zu vermeiden
Token werden im Quell-Service gecached
Caching Schlüssel basiert auf dem Ziel-Service und der Benutzer Identität
Caches müssen in verschiedenen Instanzen eines Services synchron gehalten werden
Caching gegen Performance Einbußen nutzen.

24. QAware 24

25. Christian Fritz
christian.fritz@qaware.de
@chrfritz xing.com/companies/qawaregmbh
linkedin.com/company/qaware-gmbh slideshare.net/qaware
twitter.com/qaware github.com/qaware
youtube.com/qawaregmbh