routing_mode is role_based: instead of
the consumer owning registries directly, each request’s OIDC token is matched to a role, and
the role decides what that caller can reach.
This lets one consumer (one endpoint) serve many identities — each user or group routed to
different models and tools based on their token — without minting a consumer per tenant.
What a role defines
Claim matching
Eachoidc_mapping is a set of claim rules, matched with any or all semantics. A rule
tests a claim with equals, contains_any, or contains_all against the values you list —
so you can route on a groups, roles, or custom claim.
How selection works
- A client calls a
role_basedconsumer with anAuthorization: Bearer <oidc-jwt>. - The
oidcauth validates the token (issuer, audience, JWKS, scopes). - The token’s claims are matched against each role’s
oidc_mapping. - The matched role’s
registry_ids,model_policies, andmcp_policiesgovern routing for that request — intersected with what the token is allowed to reach.
Managing roles
CRUD lives under/v1/gateways/{gateway_id}/roles, plus registry binding:
…/roles/{role_id}/registries/{registry_id}(POST/DELETE) — attach/detach a registry to the role.- Attach a role to a consumer via
…/consumers/{id}/roles/{role_id}.