Saltar al contenido principal
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. Midaz, Matcher, Reporter, Streaming Hub, Pix Lerian y Pix Indirect BTG leen AUTH_REQUIRED: defínelo como true para que las rutas protegidas rechacen con 503 si el cliente de Auth está deshabilitado o mal configurado. Sin eso, el middleware deja pasar la solicitud de forma predeterminada. En Access Manager, PLUGIN_AUTH_ENABLED configura solo el cliente de Auth de Identity. No habilita la aplicación en otros 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, el middleware 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 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 Auth y en cada proceso de producto listado en Requisitos de despliegue (BYOC). Cada proceso debe usar los CIDR del load balancer o del ingress que está delante de él. En Auth, incluye también las redes desde las que los productos llaman a Auth. El producto resuelve la IP del cliente y la envía a Auth como clientIp. 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 que usa la institución 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. 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 permite una solicitud sin IP de cliente de un llamador en sus TRUSTED_PROXIES o PLATFORM_INTERNAL_CIDRS. Auth también permite una solicitud de producto de un llamador con una dirección no pública fuera de ambos. Auth cuenta ambos casos en métricas, y debes monitorearlos.
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, en Auth y en Caradhras 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. Caradhras admite a los llamadores de la plataforma a partir de su propia copia del valor. Auth los resta de la política del tenant antes de la aplicación.

Nombres de recurso y de acción

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.