Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt

Use this file to discover all available pages before exploring further.

Product-level enforcement is the runtime integration inside each protected Lerian product. It is not a third Access Manager service. It is the route-level code that calls Auth on every incoming request 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

On every protected request, the product:
  • reads the bearer token from the Authorization header;
  • builds a permission check with the sub (subject) from the token, 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 trusted token claims such as tenantId when tenant-aware authorization is required.
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 for the tenant carried in the same token.
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 authorization with three values:
ValueMeaning
SubjectThe authenticated user or machine-to-machine application.
ResourceThe protected area of a product, such as users, applications, accounts, reports, or templates.
ActionThe operation being requested, such as get, post, patch, delete, read, or write.
Human users receive permissions through groups. Each group is tied to one or more product roles, and each role grants access to a defined set of resources and actions. Machine-to-machine applications receive permissions through their application identity. Auth resolves the calling application and checks it against the permission set configured for that application.

​
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:
ExampleMeaning
users:getRead users.
applications:postCreate machine-to-machine applications.
reports:patchUpdate reports.
templates:deleteDelete report templates.
Some products use semantic actions when the route is not best described by an HTTP method:
ExampleMeaning
transfers:createCreate a Bank Transfer transfer.
transfers:processProcess a Bank Transfer transfer.
system_config:readRead Bank Transfer system configuration.
workflows:activateActivate a Flowker workflow.
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 relies on the tenantId claim already present in the token rather than reading tenant identifiers from headers or payloads.
  3. Ask Auth
    • The product calls Auth with the subject, resource, and action.
    • 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.
Tenant scope is established by the token. In SaaS and multi-tenant BYOC deployments, the tenantId claim is resolved automatically by the platform on every API request, so you don’t need to pass a tenant identifier in headers or request bodies. Learn more about multi-tenancy.

​
Where this fits

Product-level enforcement sits between the network and the product handler. It is the reason a valid bearer token is required on every protected route after Access Manager is enabled, and the reason an authorized subject still needs the right resource-action permission to reach a specific operation. 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.