Grundlegende Konzepte
Die Authority basiert auf den Standards OAuth 2.0 und OpenID Connect 1.0.
OAuth 2.0
OAuth 2.0 ist ein Autorisierungs-Framework, das es Anwendungen ermöglicht, eingeschränkten Zugriff auf Benutzerkonten zu erhalten.
Authorization Code Flow
Der Authorization Code Flow ist der empfohlene Flow für Web-Anwendungen:
- Die Anwendung leitet den Benutzer zur Authority weiter
- Der Benutzer authentifiziert sich
- Die Authority leitet zurück zur Anwendung mit einem Authorization Code
- Die Anwendung tauscht den Code gegen einen Access Token ein
- Die Anwendung verwendet den Access Token für API-Anfragen
Client Credentials Flow
Der Client Credentials Flow wird für Server-zu-Server-Kommunikation verwendet:
- Die Anwendung sendet Client ID und Client Secret an die Authority
- Die Authority gibt einen Access Token zurück
- Die Anwendung verwendet den Access Token für API-Anfragen
OpenID Connect 1.0
OpenID Connect erweitert OAuth 2.0 um Authentifizierung.
ID Token
Der ID Token ist ein JWT (JSON Web Token), der Informationen über den authentifizierten Benutzer enthält:
{
"sub": "1234567890",
"name": "Max Mustermann",
"email": "max@example.com",
"iat": 1516239022
}Tokens
Die Authority verwendet drei Arten von Tokens:
Access Token
Der Access Token berechtigt zum Zugriff auf geschützte Ressourcen.
- Format: JWT
- Gültigkeit: Konfigurierbar (Standard: 1 Stunde)
- Verwendung: Authorization Header (
Bearer <token>)
Identity Token
Der Identity Token enthält Informationen über den authentifizierten Benutzer.
- Format: JWT
- Gültigkeit: Konfigurierbar (Standard: 1 Stunde)
- Inhalt: Benutzerdaten, Claims
Refresh Token
Der Refresh Token ermöglicht das Erneuern von Access Tokens ohne erneute Authentifizierung.
- Format: Zufälliger String
- Gültigkeit: Konfigurierbar (Standard: 30 Tage)
- Verwendung: Token Endpoint
Scopes
Scopes definieren grobe Zugriffsberechtigung und fassen mehrere Claims zusammen.
| Scope | Beschreibung |
|---|---|
openid | OpenID Connect Authentifizierung |
profile | Zugriff auf Benutzerprofil |
email | Zugriff auf E-Mail-Adresse |
engine_read | Lesezugriff auf Engine-Ressourcen |
engine_write | Schreibzugriff auf Engine-Ressourcen |
engine_observer | Zugriff auf Engine-Events |
upe_admin | Administratorzugriff auf UPE |
anonymous_session | Erstellen anonymer Sessions |
Claims
Claims sind Key-Value-Paare, die Berechtigungen oder Eigenschaften eines Benutzers beschreiben.
Standard Claims
| Claim | Beschreibung |
|---|---|
sub | Subject - eindeutige Benutzer-ID |
name | Vollständiger Name |
email | E-Mail-Adresse |
email_verified | E-Mail verifiziert |
Engine Claims
| Claim | Beschreibung |
|---|---|
can_read_process_model | Prozessmodelle lesen |
can_write_process_model | Prozessmodelle schreiben |
can_delete_process_model | Prozessmodelle löschen |
can_start_process_instance | Prozessinstanzen starten |
can_read_process_instance | Prozessinstanzen lesen |
can_terminate_process_instance | Prozessinstanzen beenden |
can_read_user_tasks | UserTasks lesen |
can_finish_user_tasks | UserTasks bearbeiten |
can_read_manual_tasks | ManualTasks lesen |
can_finish_manual_tasks | ManualTasks bearbeiten |
can_read_events | Events lesen |
can_trigger_events | Events auslösen |
can_subscribe_to_events | Events abonnieren |
UPE Claims
| Claim | Beschreibung |
|---|---|
upe_admin | Voller Zugriff auf UPE-Verwaltung |
can_manage_users | Benutzer verwalten |
can_manage_groups | Gruppen verwalten |
can_manage_claims | Claims verwalten |
can_manage_scopes | Scopes verwalten |
Custom Claims
Anwendungen können eigene Claims definieren:
{
"can_access_reports": true,
"department": "Sales",
"max_discount": 15
}Gruppen
Gruppen ermöglichen die zentrale Verwaltung von Berechtigungen.
- Eine Gruppe kann mehrere Claims haben
- Ein Benutzer kann mehreren Gruppen angehören
- Benutzer erben alle Claims ihrer Gruppen
- Änderungen an Gruppen wirken sich sofort auf alle Mitglieder aus
JWKS (JSON Web Key Set)
Die Authority stellt einen JWKS-Endpunkt bereit, über den Public Keys für die Token-Verifizierung abgerufen werden können:
GET http://authority:11560/.well-known/jwks.jsonDies ermöglicht es Anwendungen, Tokens zu verifizieren, ohne mit der Authority zu kommunizieren.