Skip to main content
Product-level enforcement is the runtime integration configured inside each protected Lerian product. It is not a third Access Manager service. When the product’s Auth client is enabled and has an Auth address, its route-level code calls Auth and either lets the request continue or rejects it before the product handler runs. Identity defines the access data. Auth decides whether a subject can perform an action on a resource. Product-level enforcement is where those decisions are actually applied to live traffic.

​
What it does

For each request on a route with enforcement configured, the product:
  • reads the bearer token from the Authorization header;
  • builds a permission check with the subject derived from token claims, the resource configured for the route, and the action configured for the route;
  • sends that check to Auth;
  • continues with the product handler when Auth returns an authorized decision;
  • rejects the request with the appropriate HTTP or gRPC error when Auth denies it;
  • uses token claims according to the product’s own tenant-aware integration when required.
Route protection is configured separately in each product. Its Auth client must be enabled and have an Auth address. Set AUTH_REQUIRED=true to make protected routes refuse with 503 if that client is disabled or misconfigured; without it, the middleware passes the request through by default. PLUGIN_AUTH_ENABLED configures Identity’s Auth client only; it does not enable enforcement in every Lerian product.
For example, a Midaz route can protect POST /transactions with the resource transactions and action post. Auth decides whether the subject in the bearer token has that permission.
Product-level enforcement does not manage users, issue tokens, or store policy data. It calls Auth and acts on the response.

​
Permission model

Access Manager evaluates the core permission decision with three values: Human authorization evaluates permissions embedded in identity data. Groups can organize permissions, and users can also receive direct user permissions. For a normal user token, the middleware derives the subject from its owner and sub claims. Unless the product configures local JWT verification, lib-auth parses those claims without signature verification; the authorization round trip to Auth is the trust anchor. Machine-to-machine authorization depends on AUTH_M2M_INVERSION_ENABLED. With its default value of false, the middleware derives a product-scoped admin/<product>-editor-role subject for any non-user token type and does not consult that token’s sub. With true, it uses the application’s token sub identity and rejects unknown token types.

​
Tenant IP allowlist

Identity stores each tenant’s IP allowlist and the surfaces where it applies. A non-empty list is enforced only on explicitly selected scopes: console for human traffic and api for machine traffic. With no selected scope, the list remains stored but is inert. Configure trusted proxies in the product integration so lib-auth forwards the resolved client IP, and configure TRUSTED_PROXIES in Auth before enforcing a list behind a proxy. The gate runs before Auth’s permission cache; tokens marked as internal bypass it. An empty list, a missing or unusable client IP, an untrusted proxy, or unavailable allowlist data does not deny the request. A token is internal when it carries the isInternal claim with the value true. Casdoor issues that claim only for applications that the platform provisions as internal Lerian services; the client-facing application API cannot set it. The bypass skips only the allowlist gate: Auth still validates the token against Casdoor before it authorizes the request, so a forged internal marker on an invalid token does not grant access.
These branches fail open. A missing or unusable client IP, an untrusted proxy, or unavailable allowlist data lets the request continue to the permission check. If you rely on the allowlist as a security control, monitor your deployment for these conditions.
In deployments where platform services call Casdoor from cluster networks, configure PLATFORM_INTERNAL_CIDRS in Identity with those CIDRs. Identity co-stores those ranges only while a tenant list exists so Casdoor’s native checks allow platform traffic; Auth subtracts them from the tenant policy before enforcement.

​
Resource and action names

Resource and action names are exact strings. They must match the values configured for the product route, and the route sends those configured values to Auth. Most API products use HTTP-method-style actions: Some products use semantic actions when the route is not best described by an HTTP method: Use Retrieve User Permissions to inspect the effective resources and actions available to the authenticated user.
Do not derive permission strings from endpoint paths by convention. Protected products enforce the resource and action values configured in Access Manager, not values inferred from the URL.

​
Request flow

  1. Receive the request
    • The product reads the bearer token from the Authorization header.
    • If the token is missing or malformed, the request is rejected before any permission check is attempted.
  2. Build the permission check
    • The product uses the resource and action configured for the route.
    • In tenant-aware deployments, the product applies its own configured tenant integration. Do not infer a universal tenantId-only authorization contract from this route-level flow.
  3. Ask Auth
    • The product calls Auth with the subject, resource, and action. Depending on its integration, it can also forward product and client-IP context.
    • Auth evaluates the request against the configured Access Manager permissions and may serve the answer from cache.
  4. Apply the decision
    • On authorized, the product continues to its handler.
    • On denied, the product returns the appropriate HTTP or gRPC error and does not invoke business logic.

​
Where this fits

When a product configures route-level enforcement, it sits between the network and the product handler. With an enabled and configured Auth client, Auth evaluates authorization before the handler runs. An authorized subject still needs the right resource-action permission to reach a specific operation and can be denied by a tenant IP allowlist active for that request’s scope. Auth can serve authorization decisions from cache. On the management side of this picture, see the Identity service. The runtime decision side is handled by the Auth service. For the day-to-day workflow against the APIs, see Using Access Manager.