Ir al contenido

Autenticación

Cada llamada /osl/* lleva un token JWT Bearer. El motor autoriza contra los scopes y roles del token, y el punto de aplicación de política aplica la ACL del llamante server-side.

Authorization: Bearer <jwt>

El JWT lleva:

Claim Significado
chain[] La cadena de delegación, raíz → hoja (el sujeto que actúa es el último eslabón)
sub Opcional; si está presente, debe ser igual a chain[-1]
roles[] Roles asignados
tenant La celda del tenant
scopes[] osl:read, osl:write, osl:execute, osl:admin
exp Caducidad (obligatoria)

El acceso se evalúa sobre una cadena de sujetos (raíz → hoja), no sobre una única identidad — ver Acceso y capacidades. La cadena está dentro del payload firmado (HS256), de modo que un llamante no puede acortarla ni falsificarla sin romper la firma:

{
"iss": "opendome",
"chain": ["ana@company.com", "agent://copilot-finance"],
"roles": ["analyst"],
"iat": 1750000000,
"exp": 1750000300
}
Edición Emisor
OSS standalone Apache-2.0 La celda acuña tokens HS256 localmente. El chart de tenant-semantic-api genera un Secret de firma; usa scripts/osl-token.sh <tenant> --roles <r> para acuñar uno. El motor standalone no confía en la cabecera X-Actor-Roles — un llamante de un Ingress público no puede falsear roles.
Enterprise / managed Enterprise El control-plane emite y rota los JWTs. También puedes anteponer al motor tu propio proxy con conciencia de IdP que ponga X-Actor-Roles y activar auth.trustActorRolesHeader=true (BYO-OIDC).

Valores por defecto, por sujeto:

Endpoint Límite
POST /osl/query 60 rps
POST /osl/sample 30 rps
GET /osl/schema 5 rps (cacheado)

Excedido → 429 Too Many Requests con Retry-After. Los límites se configuran por tenant en el tier managed.

Cada petición — 200 o no — produce una entrada de auditoría inmutable y encadenada por hash con request_id, sujeto, acción, los FQNs de los objetos tocados, la decisión y un timestamp.