Zum Inhalt springen

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 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)

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
}
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).

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.