Authentifizierung
Jeder /osl/*-Aufruf trägt ein JWT-Bearer-Token. Die Engine autorisiert gegen
die Scopes und Rollen des Tokens, und der Policy Enforcement Point wendet die ACL
des Aufrufers serverseitig an.
Authorization: Bearer <jwt>Das Token
Abschnitt betitelt „Das Token“Das JWT trägt:
| Claim | Bedeutung |
|---|---|
chain[] |
Die Delegationskette, Root → Leaf (das handelnde Subject ist das letzte Glied) |
sub |
Optional; falls vorhanden, muss es chain[-1] entsprechen |
roles[] |
Zugewiesene Rollen |
tenant |
Die Zelle des Tenants |
scopes[] |
osl:read, osl:write, osl:execute, osl:admin |
exp |
Ablauf (erforderlich) |
Die Delegationskette
Abschnitt betitelt „Die Delegationskette“Zugriff wird über eine Kette von Subjects (Root → Leaf) ausgewertet, nicht über eine einzelne Identität — siehe Zugriff & Capabilities. Die Kette liegt innerhalb des signierten Payloads (HS256), sodass ein Aufrufer sie nicht kürzen oder fälschen kann, ohne die Signatur zu brechen:
{ "iss": "opendome", "chain": ["ana@company.com", "agent://copilot-finance"], "roles": ["analyst"], "iat": 1750000000, "exp": 1750000300}Woher Tokens kommen
Abschnitt betitelt „Woher Tokens kommen“| Edition | Aussteller |
|---|---|
| OSS standalone Apache-2.0 | Die Zelle prägt HS256-Tokens lokal. Der tenant-semantic-api-Chart generiert ein Signing-Secret; nutze scripts/osl-token.sh <tenant> --roles <r>, um eines zu prägen. Die Standalone-Engine vertraut dem X-Actor-Roles-Header nicht — ein Aufrufer über einen öffentlichen Ingress kann keine Rollen fälschen. |
| Enterprise / managed Enterprise | Die Control-Plane stellt JWTs aus und rotiert sie. Du kannst der Engine auch deinen eigenen IdP-fähigen Proxy vorschalten, der X-Actor-Roles setzt, und auth.trustActorRolesHeader=true aktivieren (BYO-OIDC). |
Rate-Limits
Abschnitt betitelt „Rate-Limits“Standardwerte, pro Subject:
| Endpoint | Limit |
|---|---|
POST /osl/query |
60 rps |
POST /osl/sample |
30 rps |
GET /osl/schema |
5 rps (gecacht) |
Überschritten → 429 Too Many Requests mit Retry-After. Die Limits werden in
der Managed-Stufe pro Tenant konfiguriert.
Jeder Request — 200 oder nicht — erzeugt einen unveränderlichen,
hash-verketteten Audit-Eintrag mit request_id, Subject, Action, den berührten
Objekt-FQNs, der Entscheidung und einem Timestamp.