Przejdź do głównej zawartości

Uwierzytelnianie

Każde wywołanie /osl/* niesie token Bearer JWT. Silnik autoryzuje względem scope’ów i ról tokenu, a punkt egzekwowania polityk stosuje ACL wywołującego po stronie serwera.

Authorization: Bearer <jwt>

JWT niesie:

Claim Znaczenie
chain[] Łańcuch delegacji, root → leaf (działający podmiot to ostatnie ogniwo)
sub Opcjonalny; jeśli obecny, musi równać się chain[-1]
roles[] Przypisane role
tenant Komórka tenanta
scopes[] osl:read, osl:write, osl:execute, osl:admin
exp Wygaśnięcie (wymagane)

Dostęp jest ewaluowany nad łańcuchem podmiotów (root → leaf), a nie pojedynczą tożsamością — zobacz Dostęp i zdolności. Łańcuch jest wewnątrz podpisanego payloadu (HS256), więc wywołujący nie może go skrócić ani sfałszować bez złamania podpisu:

{
"iss": "opendome",
"chain": ["ana@company.com", "agent://copilot-finance"],
"roles": ["analyst"],
"iat": 1750000000,
"exp": 1750000300
}
Edycja Wystawca
OSS standalone Apache-2.0 Komórka emituje tokeny HS256 lokalnie. Chart tenant-semantic-api generuje Secret podpisujący; użyj scripts/osl-token.sh <tenant> --roles <r>, aby wygenerować token. Silnik standalone nie ufa nagłówkowi X-Actor-Roles — wywołujący przez publiczny Ingress nie może podszyć się pod role.
Enterprise / zarządzane Enterprise Control-plane wystawia i rotuje JWT. Możesz też postawić przed silnikiem własne proxy świadome IdP, które ustawia X-Actor-Roles, i przełączyć auth.trustActorRolesHeader=true (BYO-OIDC).

Domyślne, per podmiot:

Endpoint Limit
POST /osl/query 60 rps
POST /osl/sample 30 rps
GET /osl/schema 5 rps (cacheowane)

Przekroczenie → 429 Too Many Requests z Retry-After. Limity są konfigurowane per tenant w tierze zarządzanym.

Każde żądanie — 200 czy nie — produkuje niezmienny, łańcuchowany hashem wpis audytowy z request_id, podmiotem, akcją, FQN-ami dotkniętych obiektów, decyzją i znacznikiem czasu.