SlideShare ist ein Scribd-Unternehmen logo
1 von 25
Downloaden Sie, um offline zu lesen
Christian Fritz, QAware GmbH
christian.fritz@qaware.de
Sichere Backend-Calls mit
Nutzerkontext
Düsseldorf, 09. Oktober 2018
Um was geht
es denn?
Foto: AzmanJaka - gettyimages.de
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
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
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
Wo ist
eigentlich
das
Problem?
Foto: skynesher - gettyimages.de
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?
QAware 8
Wer kennt wann den Endnutzer?
Service C
Service A
(GUI + REST)
Service B
(GUI + REST)
Service D
Alice Bob
Gescheiterte
Lösungsversuche
Foto: sturti - gettyimages.de
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.
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")
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.
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
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.
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.
Die Lösung
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
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
{
"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:
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
Stolperfallen
Foto: nicolamargaret - gettyimages.de
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.
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.
QAware 24
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

Weitere ähnliche Inhalte

Ähnlich wie Sichere Backend-Calls mit Nutzerkontext

Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?
team-WIBU
 
Bürgerclient und eID
Bürgerclient und eIDBürgerclient und eID
Bürgerclient und eID
guest3326f6
 
bitkasten - Identverfahren für BiPRO
bitkasten - Identverfahren für BiPRObitkasten - Identverfahren für BiPRO
bitkasten - Identverfahren für BiPRO
Christian Gericke
 
German_iSignthis Brochures
German_iSignthis BrochuresGerman_iSignthis Brochures
German_iSignthis Brochures
John Karantzis
 

Ähnlich wie Sichere Backend-Calls mit Nutzerkontext (20)

API Authentifizierung und Autorisierung
API Authentifizierung und Autorisierung API Authentifizierung und Autorisierung
API Authentifizierung und Autorisierung
 
Integrations-Pattern für OpenID Connect
Integrations-Pattern für OpenID ConnectIntegrations-Pattern für OpenID Connect
Integrations-Pattern für OpenID Connect
 
Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Co...
Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Co...Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Co...
Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Co...
 
Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?
 
SharePoint Claims und FBA
SharePoint Claims und FBASharePoint Claims und FBA
SharePoint Claims und FBA
 
Aufbau einer PKI in einer Domino Umgebung
Aufbau einer PKI in einer Domino UmgebungAufbau einer PKI in einer Domino Umgebung
Aufbau einer PKI in einer Domino Umgebung
 
Webinar: Online Security
Webinar: Online SecurityWebinar: Online Security
Webinar: Online Security
 
Bürgerclient und eID
Bürgerclient und eIDBürgerclient und eID
Bürgerclient und eID
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der Praxis
 
D3 000908 Lotusday Hagen Bcc Id Vault
D3 000908 Lotusday Hagen Bcc Id VaultD3 000908 Lotusday Hagen Bcc Id Vault
D3 000908 Lotusday Hagen Bcc Id Vault
 
Open Source Camp Kubernetes 2024 | User Authentifizierung mit OpenID Connect ...
Open Source Camp Kubernetes 2024 | User Authentifizierung mit OpenID Connect ...Open Source Camp Kubernetes 2024 | User Authentifizierung mit OpenID Connect ...
Open Source Camp Kubernetes 2024 | User Authentifizierung mit OpenID Connect ...
 
Artikel Netzguide: Sicherheit für service- orientierte Architekturen
Artikel Netzguide: Sicherheit für service- orientierte ArchitekturenArtikel Netzguide: Sicherheit für service- orientierte Architekturen
Artikel Netzguide: Sicherheit für service- orientierte Architekturen
 
Continuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn AgileContinuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn Agile
 
bitkasten - Identverfahren für BiPRO
bitkasten - Identverfahren für BiPRObitkasten - Identverfahren für BiPRO
bitkasten - Identverfahren für BiPRO
 
German_iSignthis Brochures
German_iSignthis BrochuresGerman_iSignthis Brochures
German_iSignthis Brochures
 
SharePoint Konferenz 2014 Munich - Wie Sie Office 365 mit Windows Azure steue...
SharePoint Konferenz 2014 Munich - Wie Sie Office 365 mit Windows Azure steue...SharePoint Konferenz 2014 Munich - Wie Sie Office 365 mit Windows Azure steue...
SharePoint Konferenz 2014 Munich - Wie Sie Office 365 mit Windows Azure steue...
 
2 Faktor Authentifizierung - WordPress Login absichern
2 Faktor Authentifizierung - WordPress Login absichern2 Faktor Authentifizierung - WordPress Login absichern
2 Faktor Authentifizierung - WordPress Login absichern
 
So funktioniert es: Identitätsprüfung via online ausweischeck
So funktioniert es: Identitätsprüfung via online ausweischeckSo funktioniert es: Identitätsprüfung via online ausweischeck
So funktioniert es: Identitätsprüfung via online ausweischeck
 
Das kleine Einmaleins der sicheren Architektur
Das kleine Einmaleins der sicheren ArchitekturDas kleine Einmaleins der sicheren Architektur
Das kleine Einmaleins der sicheren Architektur
 
Sicherheit in Single-Page-Web-Anwendungen
Sicherheit in Single-Page-Web-AnwendungenSicherheit in Single-Page-Web-Anwendungen
Sicherheit in Single-Page-Web-Anwendungen
 

Mehr von QAware GmbH

"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
QAware GmbH
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
QAware GmbH
 

Mehr von QAware GmbH (20)

50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf50 Shades of K8s Autoscaling #JavaLand24.pdf
50 Shades of K8s Autoscaling #JavaLand24.pdf
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN MainzFully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
 
Down the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile ArchitectureDown the Ivory Tower towards Agile Architecture
Down the Ivory Tower towards Agile Architecture
 
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!"Mixed" Scrum-Teams – Die richtige Mischung macht's!
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit PlaywrightDer Tod der Testpyramide? – Frontend-Testing mit Playwright
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
 
Was kommt nach den SPAs
Was kommt nach den SPAsWas kommt nach den SPAs
Was kommt nach den SPAs
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
 
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See... Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
 
Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!Kubernetes with Cilium in AWS - Experience Report!
Kubernetes with Cilium in AWS - Experience Report!
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAPKontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
 
Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.Service Mesh Pain & Gain. Experiences from a client project.
Service Mesh Pain & Gain. Experiences from a client project.
 
50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling50 Shades of K8s Autoscaling
50 Shades of K8s Autoscaling
 
Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.Blue turns green! Approaches and technologies for sustainable K8s clusters.
Blue turns green! Approaches and technologies for sustainable K8s clusters.
 
Per Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API GatewaysPer Anhalter zu Cloud Nativen API Gateways
Per Anhalter zu Cloud Nativen API Gateways
 
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
 

Sichere Backend-Calls mit Nutzerkontext

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