Skip to main content
La aplicación en el nivel de producto es la integración de runtime dentro de cada producto Lerian protegido. No es un tercer servicio de Access Manager. Un producto con su cliente de Auth habilitado y una dirección de Auth llama a Auth desde su código en el nivel de ruta. Ese código en el nivel de ruta deja continuar la solicitud o la rechaza antes de que corra el handler del producto. Identity define los datos de acceso. Auth decide si un sujeto puede hacer una acción sobre un recurso. La aplicación en el nivel de producto aplica esas decisiones al tráfico en vivo.

​
Qué hace

Para cada solicitud en una ruta con la aplicación configurada, el producto:
  • lee el Bearer token del header Authorization.
  • arma una verificación de permiso con el sujeto derivado de los claims del token, el resource configurado para la ruta y la action configurada para la ruta.
  • envía esa verificación a Auth.
  • continúa con el handler del producto cuando Auth devuelve una decisión autorizada.
  • rechaza la solicitud con el error HTTP o gRPC correspondiente cuando Auth la deniega.
  • usa los claims del token según la propia integración con reconocimiento de tenant del producto cuando se requiere.
Configuras la protección de rutas por separado en cada producto. Habilita el cliente de Auth de cada producto y define una dirección de Auth. Define AUTH_REQUIRED=true para que las rutas protegidas rechacen con 503 si ese cliente está deshabilitado o mal configurado. Sin eso, el middleware deja pasar la solicitud de forma predeterminada. PLUGIN_AUTH_ENABLED configura solo el cliente de Auth de Identity. No habilita la aplicación en todos los productos Lerian.
Por ejemplo, una ruta de Midaz puede proteger POST /transactions con el recurso transactions y la acción post. Auth decide si el sujeto del Bearer token tiene ese permiso.
La aplicación en el nivel de producto no gestiona usuarios, no emite tokens ni almacena datos de políticas. Llama a Auth y actúa sobre la respuesta.

​
Modelo de permisos

Access Manager evalúa la decisión de permiso central con tres valores: La autorización humana evalúa permisos incrustados en los datos de identidad. Los grupos pueden organizar permisos, y los usuarios también pueden recibir permisos de usuario directos. Para un token de usuario normal, el middleware deriva el sujeto de sus claims owner y sub. A menos que el producto configure la verificación local de JWT, lib-auth analiza esos claims sin verificación de firma. El viaje de ida y vuelta de autorización hacia Auth es el ancla de confianza. La autorización machine-to-machine depende de AUTH_M2M_INVERSION_ENABLED. Con su valor predeterminado false, el middleware deriva un sujeto admin/<product>-editor-role con alcance de producto para cualquier tipo de token que no sea de usuario y no consulta el sub de ese token. Con true, usa la identidad sub del token de la aplicación y rechaza los tipos de token desconocidos.

​
Lista de IP permitidas del tenant

Para la guía de cliente de esta funcionalidad, lee Lista de IP permitidas. Identity almacena la lista de IP permitidas de cada tenant y las superficies donde aplica. Una lista no vacía aplica solo en los ámbitos seleccionados explícitamente: console para tráfico humano y api para tráfico de máquinas. Sin ningún ámbito seleccionado, la lista sigue almacenada pero queda inerte. Configura TRUSTED_PROXIES en cada proceso de producto que use lib-auth y en el propio Auth. Cada proceso debe usar los CIDR del load balancer o del ingress que está delante de él. Del lado del producto, lib-auth resuelve la IP del cliente y la envía a Auth como clientIp. Auth usa su propio ajuste para decidir si puede confiar en esa dirección para aplicar la lista. La compuerta corre antes del cache de permisos de Auth. Los tokens marcados como internos la evitan. Una lista vacía no aplica la compuerta. Un token es interno cuando lleva el claim isInternal con el valor true. Caradhras emite ese claim solo para aplicaciones que la plataforma aprovisiona como servicios internos de Lerian. La API de aplicaciones de cara al cliente no puede definirlo. La omisión salta solo la compuerta de la lista de IP permitidas. Auth aún valida el token contra Caradhras antes de autorizar la solicitud, así que una marca interna falsificada en un token inválido no concede acceso.
Si Caradhras no está disponible y Auth tiene una política en cache, Auth sirve la última política válida conocida y aún puede denegar. Solo una consulta sin política en cache falla en abierto. Un TRUSTED_PROXIES sin definir en Auth también falla en abierto y emite la señal de proxy no confiable. Auth deniega una solicitud con una IP de cliente ausente o inutilizable cuando aplica una lista no vacía. La excepción es una solicitud cuyo par de transporte está en PLATFORM_INTERNAL_CIDRS. Auth permite esa falla de reenvío interna de la plataforma, y debes monitorearla.
En despliegues donde los servicios de plataforma llaman a Caradhras desde redes del clúster, configura el mismo valor de PLATFORM_INTERNAL_CIDRS en Identity y en Auth con esos CIDR. Cada entrada debe incluir un prefijo explícito. Un prefijo comodín se rechaza en el arranque porque confiaría en todos los llamadores y quitaría cada entrada de tenant de la aplicación. Identity almacena también esos rangos solo mientras existe una lista de tenant, para que las verificaciones nativas de Caradhras permitan el tráfico de plataforma. Auth los resta de la política del tenant antes de la aplicación.

​
Nombres de recurso y de acción

Los nombres de recurso y de acción son strings exactos. Deben coincidir con los valores configurados para la ruta del producto, y la ruta envía esos valores configurados a Auth. La mayoría de los productos de API usan acciones con estilo de método HTTP: Algunos productos usan acciones semánticas cuando un método HTTP no describe bien la ruta: Usa Retrieve User Permissions para inspeccionar los recursos y las acciones efectivos disponibles para el usuario autenticado.
No derives strings de permiso a partir de rutas de endpoint por convención. Los productos protegidos aplican los valores de recurso y acción configurados en Access Manager, no valores inferidos de la URL.

​
Flujo de la solicitud

  1. Recibir la solicitud
    • El producto lee el Bearer token del header Authorization.
    • Si el token está ausente o malformado, el producto rechaza la solicitud antes de cualquier verificación de permiso.
  2. Armar la verificación de permiso
    • El producto usa el recurso y la acción configurados para la ruta.
    • En despliegues con reconocimiento de tenant, el producto aplica su propia integración de tenant configurada. No infieras un contrato de autorización universal basado solo en tenantId a partir de este flujo en el nivel de ruta.
  3. Consultar a Auth
    • El producto llama a Auth con el sujeto, el recurso y la acción. Según su integración, también puede reenviar contexto de producto y de IP de cliente.
    • Auth evalúa la solicitud contra los permisos configurados en Access Manager y puede servir la respuesta desde el cache.
  4. Aplicar la decisión
    • Si el resultado es autorizado, el producto continúa hacia su handler.
    • Si el resultado es denegado, el producto devuelve el error HTTP o gRPC correspondiente y no invoca la lógica de negocio.

​
Dónde encaja esto

Cuando un producto configura la aplicación en el nivel de ruta, esta queda entre la red y el handler del producto. Con un cliente de Auth habilitado y configurado, Auth evalúa la autorización antes de que corra el handler. Un sujeto autorizado aún necesita el permiso de recurso y acción correcto para llegar a una operación específica. Una lista de IP permitidas del tenant activa para el ámbito de esa solicitud aún puede denegarla. Auth puede servir decisiones de autorización desde el cache. Del lado de gestión de este panorama, consulta el servicio Identity. El servicio Auth se encarga del lado de las decisiones de runtime. Para el workflow del día a día contra las APIs, consulta Usar Access Manager.