- Organizations, the boundary that owns every other object.
- Users, the people who sign in.
- Groups and roles, the two ways to collect subjects.
- Permissions, which pair a resource with an action.
- Applications, the OAuth clients that machine-to-machine callers use.
- Certificates, the key material behind token signatures.
Protocols
Caradhras supports these protocols and authentication methods:
- OAuth 2.0 and OIDC
- SAML 2.0
- CAS
- SCIM 2.0 for user provisioning
- LDAP: authenticates users against an external directory. Caradhras does not run a directory.
- WebAuthn and passkeys
- TOTP and MFA
Authorization model
Caradhras expresses authorization with Casbin, which supports ACL, RBAC, and ABAC models. A permission names a resource and an action. Access Manager evaluates that pair against the subject in the token before a product handler runs. Subjects nest. A group can belong to a parent group. A role can include other roles.
Your identity provider
Your identity provider connects to Caradhras as an upstream provider over OAuth 2.0 and OIDC, SAML 2.0, or LDAP. OIDC providers include Google, Microsoft Entra ID, Okta, or a custom OIDC provider. Your provider does not replace Caradhras. Your users then authenticate at your provider. Access Manager still reads their identity data from Caradhras, and it still decides what they can reach. Access Manager does not connect directly to arbitrary identity-provider APIs.
How it ships
Caradhras is part of the Access Manager deployment. You do not install it as a separate product. The Access Manager Helm chart deploys Caradhras as the identity backend, and the Auth and Identity services call it. Caradhras persists its identity data in the PostgreSQL database that you configure for Access Manager. To see what each Access Manager service uses the backend for, read Caradhras in Access Manager.

