> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Caradhras in Access Manager

> See what the Auth and Identity services use Caradhras for, where the identity data lives, and which variables point Access Manager at it.

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](/en/platform/access-manager/installing-access-manager).
* `AUTHORIZER_JWT_CERTIFICATE` supplies the public key that validates the tokens the identity backend issues. Read [Access Manager Helm chart](/en/platform/helm/access-manager/access-manager-helm).
* `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` pins pre-login SSO to one Caradhras organization. Read [Identity service](/en/platform/access-manager/identity-plugin).
* `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](/en/platform/access-manager/product-level-enforcement#tenant-ip-allowlist).