Skip to main content
Access Manager guarda sus datos de identidad en Caradhras. Identity y Auth se conectan al mismo backend, cada uno para un trabajo distinto.

​
Para qué lo usa cada servicio

  • Identity almacena en el backend los usuarios, los grupos, las aplicaciones, los proveedores de comunicación, los vínculos entre aplicación y proveedor, y la configuración de MFA.
  • Auth se sitúa entre tus productos Lerian protegidos y Caradhras. Reenvía las solicitudes de token al backend y valida con él los refresh tokens. También lee los claims de token que identifican el sujeto y el contexto de tenant.
  • La aplicación en el nivel de producto depende de los claims que emite Caradhras. Un token es interno cuando lleva el claim isInternal con el valor true. Caradhras emite ese claim solo para las aplicaciones que la plataforma aprovisiona como servicios internos de Lerian.
Caradhras guarda los datos de acceso. Identity los escribe, Auth los lee para decidir, y cada producto protegido actúa según la decisión. Por ejemplo, Identity crea un usuario y lo pone en un grupo de producto. Auth luego emite el access token y responde las verificaciones de permisos que siguen.

​
Dónde viven los datos

Caradhras persiste estos datos en la base de datos PostgreSQL que configuras para Access Manager. PostgreSQL respalda a Caradhras. No lo reemplaza. Los cambios de esquema corren como un paso de migración aparte, nunca cuando un servicio arranca. Ambos servicios alcanzan el backend por HTTP en la dirección que configuras. Tanto Auth como Identity necesitan que el backend esté accesible antes de arrancar. El Helm chart de Access Manager despliega el backend junto a los dos servicios. Valkey guarda en cache los datos de token, de permisos y relacionados con MFA, de modo que Auth repite menos llamadas al backend durante la operación normal.

​
Tokens y claves

Los access tokens emitidos a las aplicaciones que crea Identity caducan después de una hora. Las aplicaciones creadas fuera de Identity llevan su propia duración. Cuando el cumplimiento está activo, los tokens machine-to-machine se verifican contra las claves de firma actuales del emisor, que se renuevan automáticamente. AUTHORIZER_JWT_CERTIFICATE guarda una clave pública. Un backend de identidad nuevo acuña su propio par de claves en el primer arranque, y esta variable le dice a Access Manager en qué clave pública confiar. Un valor configurado pero inservible impide que el servicio arranque.

​
Configuración

Cuatro variables conectan Access Manager con Caradhras.
  • AUTHORIZER_ADDRESS da la dirección del backend de identidad. Lee Instalar Access Manager.
  • AUTHORIZER_JWT_CERTIFICATE aporta la clave pública que valida los tokens que emite el backend de identidad. Lee Helm chart de Access Manager.
  • PLUGIN_AUTH_SSO_STATIC_ORGANIZATION fija el SSO previo al inicio de sesión a una sola organización de Caradhras. Lee Servicio Identity.
  • PLATFORM_INTERNAL_CIDRS declara las redes desde las que los servicios de la plataforma llaman a Caradhras. Cuando una lista de IP permitidas del tenant está activa, Auth puede denegar solicitudes de plataforma que vengan de redes no listadas aquí. Lee Lista de IP permitidas del tenant.