Skip to main content
El control de acceso a nivel de producto es la integración en tiempo de ejecución configurada dentro de cada producto protegido de Lerian. No es un tercer servicio de Access Manager. Cuando el cliente Auth del producto está habilitado y tiene una dirección de Auth, su código a nivel de ruta llama a Auth y deja continuar la solicitud o la rechaza antes de que se ejecute el handler del producto. Identity define los datos de acceso. Auth decide si un sujeto puede realizar una acción sobre un recurso. El control de acceso a nivel de producto es donde esas decisiones se aplican realmente al tráfico en vivo.

​
Qué hace

Para cada solicitud en una ruta con el control de acceso configurado, el producto:
  • lee el bearer token del header Authorization;
  • construye una verificación de permiso con el sujeto derivado de claims del token, el resource configurado para la ruta y el action configurado 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 claims del token según la integración propia del producto con conciencia de tenant cuando se requiere.
La protección de rutas se configura por separado en cada producto. Su cliente Auth debe estar habilitado y tener una dirección de Auth. Configura AUTH_REQUIRED=true para que las rutas protegidas rechacen con 503 si ese cliente está deshabilitado o mal configurado; sin ello, el middleware deja pasar la solicitud por defecto. PLUGIN_AUTH_ENABLED configura solo el cliente Auth de Identity; no habilita el control de acceso 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.
El control de acceso a nivel de producto no gestiona usuarios, no emite tokens ni almacena datos de políticas. Llama a Auth y actúa según 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 integrados en los datos de identidad. Los grupos pueden organizar permisos y los usuarios también pueden recibir permisos directos. Para un token de usuario normal, el middleware deriva el sujeto de sus claims owner y sub. Salvo que el producto configure la verificación local de JWT, lib-auth analiza esos claims sin verificar la firma; la llamada de autorización a Auth es el ancla de confianza. La autorización máquina a máquina depende de AUTH_M2M_INVERSION_ENABLED. Con su valor predeterminado de 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.

​
Allowlist IP del tenant

Identity almacena la allowlist IP de cada tenant y las superficies donde se aplica. Una lista no vacía solo se aplica en los ámbitos seleccionados explícitamente: console para tráfico humano y api para tráfico de máquina. Sin ningún ámbito seleccionado, la lista se conserva pero permanece inactiva. Configura proxies de confianza en la integración del producto para que lib-auth reenvíe la IP de cliente resuelta y configura TRUSTED_PROXIES en Auth antes de aplicar una lista detrás de un proxy. El control se ejecuta antes de la caché de permisos de Auth; los tokens marcados como internos lo omiten. Una lista vacía, una IP de cliente ausente o inutilizable, un proxy no confiable o datos de allowlist no disponibles no deniegan la solicitud. Un token es interno cuando lleva el claim isInternal con el valor true. Casdoor emite ese claim solo para aplicaciones que la plataforma aprovisiona como servicios internos de Lerian; la API de aplicaciones orientada al cliente no puede establecerlo. La omisión solo salta el control de la allowlist: Auth sigue validando el token con Casdoor antes de autorizar la solicitud, por lo que un marcador interno falsificado en un token inválido no otorga acceso.
Estas ramas fallan en abierto (fail-open). Una IP de cliente ausente o inutilizable, un proxy no confiable o datos de allowlist no disponibles dejan que la solicitud continúe hacia la verificación de permisos. Si dependes de la allowlist como control de seguridad, monitorea tu despliegue para detectar estas condiciones.
En despliegues donde los servicios de plataforma llaman a Casdoor desde redes del clúster, configura PLATFORM_INTERNAL_CIDRS en Identity con esos CIDR. Identity almacena conjuntamente esos rangos solo mientras existe una lista del tenant para que las comprobaciones nativas de Casdoor permitan el tráfico de plataforma; Auth los resta de la política del tenant antes de aplicarla.

​
Nombres de recursos y acciones

Los nombres de recursos y acciones 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 al estilo de los métodos HTTP: Algunos productos usan acciones semánticas cuando la ruta no se describe mejor con un método HTTP: Usa Obtener permisos del usuario para inspeccionar los recursos y acciones efectivos disponibles para el usuario autenticado.
No deduzcas los strings de permiso a partir de las rutas de los endpoints 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 falta o está mal formado, la solicitud se rechaza antes de intentar cualquier verificación de permiso.
  2. Construir la verificación de permiso
    • El producto usa el recurso y la acción configurados para la ruta.
    • En despliegues con conciencia 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 a 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 el contexto de producto e IP de cliente.
    • Auth evalúa la solicitud contra los permisos configurados en Access Manager y puede servir la respuesta desde caché.
  4. Aplicar la decisión
    • Si está autorizada, el producto continúa hacia su handler.
    • Si está denegada, el producto devuelve el error HTTP o gRPC correspondiente y no invoca la lógica de negocio.

​
Dónde encaja

Cuando un producto configura el control de acceso a nivel de ruta, este se sitúa entre la red y el handler del producto. Con un cliente Auth habilitado y configurado, Auth evalúa la autorización antes de que se ejecute el handler. Un sujeto autorizado aún necesita el permiso de recurso-acción correcto para llegar a una operación específica y puede ser denegado por una allowlist IP de tenant activa para el ámbito de esa solicitud. Auth puede servir decisiones de autorización desde caché. Para el lado de gestión de este panorama, consulta el servicio Identity. Para el lado de la decisión en tiempo de ejecución, consulta el servicio Auth. Para el flujo de trabajo del día a día contra las APIs, consulta Usar Access Manager.