Skip to main content
Access Manager keeps its identity data in Caradhras. Identity and Auth connect to the same backend, each for a different job.

​
What each service uses it for

  • Identity stores users, groups, applications, communication providers, application-provider links, and MFA configuration in the backend.
  • Auth sits between your protected Lerian products and Caradhras. It forwards token requests to the backend and validates refresh tokens with it. It also reads the token claims that identify the subject and the tenant context.
  • Product-level enforcement depends on the claims that Caradhras issues. A token is internal when it carries the isInternal claim with the value true. Caradhras issues that claim only for applications that the platform provisions as internal Lerian services.
Caradhras holds the access data. Identity writes it, Auth reads it to decide, and each protected product acts on the decision. For example, Identity creates a user and puts that user in a product group. Auth then issues the access token and answers the permission checks that follow.

​
Where the data lives

Caradhras persists this data in the PostgreSQL database that you configure for Access Manager. PostgreSQL backs Caradhras. It does not replace it. Schema changes run as a separate migration step, never when a service starts. Both services reach the backend over HTTP at the address you configure. Auth and Identity both need the backend reachable before they start. The Access Manager Helm chart deploys the backend alongside the two services. Valkey caches token, permission, and MFA-related data, so that Auth repeats fewer calls to the backend during normal operation.

​
Tokens and keys

Access tokens issued to the applications that Identity creates expire after one hour. Applications created outside Identity carry their own lifetime. When enforcement is on, machine-to-machine tokens are verified against the issuer’s current signing keys, refreshed automatically. AUTHORIZER_JWT_CERTIFICATE holds a public key. A fresh identity backend mints its own key pair on first start, and this variable tells Access Manager which public key to trust. A configured but unusable value stops the service from starting.

​
Configuration

Four variables connect Access Manager to Caradhras.
  • AUTHORIZER_ADDRESS gives the address of the identity backend. Read Installing Access Manager.
  • AUTHORIZER_JWT_CERTIFICATE supplies the public key that validates the tokens the identity backend issues. Read Access Manager Helm chart.
  • PLUGIN_AUTH_SSO_STATIC_ORGANIZATION pins pre-login SSO to one Caradhras organization. Read Identity service.
  • PLATFORM_INTERNAL_CIDRS declares the networks that platform services call Caradhras from. When a tenant IP allowlist is active, Auth can deny platform requests from networks not listed here. Read Tenant IP allowlist.