Skip to content

Authentication

Authentication is enforced by the api-gateway which validates session cookies / headers, & adds a x-prismeai-user-id header to the request before forwarding it to the target microservice. Thus, other backend microservices do not enforce any authentication mechanism & rely on this x-prismeai-user-id header when needing access to the authenticated user id. Therefore, these backend microservices must be securely kept inside a private & trusted network.

The API Gateway will reject un-authenticated requests only if the target API is protected by an authentication policy inside the gateway.config.yml. .

Authorization

Although API Gateway is the only authentication keeper, each backend microservice can manage its own permissions system (using @prisme.ai/permissions package), with their own custom roles & policies.

For instance, when accessing a specific workspace, prisme.ai-workspaces service will check that authenticated user (given by x-prismeai-user-id header) has a read policy on the target object. This read policy might be granted in different ways : specific policy attribution, role, or with an API Key.
More details on Permissions & API Keys

Authorization configuration

Roles, permissions & API Keys are implemented by @prisme.ai/permissions package, which provides generic helpers allowing each service to implement their custom authorization policies with minimal efforts.

Each backend microservice keep this configuration inside a src/permissions folder.
This folder has 2 main files :
- config.ts : declares the existing roles (i.e owner), object types (i.e workspace) and the rules defining the allowed / forbidden interactions
- index.ts : Instantiates the @prisme.ai/permissions with the above configuration + a persistance Mongoose schema (optional, only if we want the package to handle the permissions persistance)

The config.ts can also specify an optional customRulesBuilder callback used to dynamically generate roles given an external payload, by returning the same kind of rules as present in rbac and abac fields.
This is how api keys are created under the hood, with this callback mapping the api key settings to the corresponding rules which will be evaluated when validating this API Key against a given access request.
For a more concrete example, see services/events/src/permissions/config.ts.