The request at the service should have:
Original-Request-Urirequired header, that specifies the request path to check acl;
Original-Request-Methodrequired header, that specifies the request method to check acl;
Authenticationoptional header, to authenticate logged user calling the api;
Client-Typeoptional header, to handle client type in acl expression;
isbackofficeoptional header, to handle isbackoffice parameters in acl expression.
The authorization service proxies the request and all the headers specified in
HEADERS_TO_PROXY env variables to an url (set by
USERINFO_URL) and waits for the the url to respond with the user data in json, or with an http error or an empty body, in case the user is not logged.
The authorization service calls a service, that should handle user authentication and returns logged user body. Request timeout is set to 1 minute. The user structure must contains:
groups: a list of groups
- a unique identifier of the user (default
subbut configurable through
CUSTOM_USER_ID_KEY). User id cannot be empty.
Headers set by
mia-allowed: set to 0 or 1. 0 -> not allowed. 1 -> allowed
mia-userid: if the api is called by logged user, it is filled with user id (customizable through
CUSTOM_USER_ID_KEY). Otherwise it is empty.
mia-groups: if the api is called by logged user, it is filled with comma separated list of user groups. Otherwise it is empty.
mia-userproperties: it is possible to set into
USER_PROPERTIES_TO_PROXYa comma separated list of user properties to evaluate acl expressions.
By default the
authorization-service is in strict mode.
In this mode, the response could be:
- 200 with mia-allowed header set to 1: if user has access to the resource;
- 200 with mia-allowed header set to 0: if resource is not found in authorization-service configuration;
- 401 with mia-allowed header set to 0: if access to the resource is requested without a logged user;
- 403 with mia-allowed header set to 0: if user request aims at accessing a resource which does not have enough permissions.
In this mode,
authorization-service always responds 200 with
mia-allowed set to 0 if the user does not have permission to access the resource or 1 if they have the permission.
It is possible to set the environment variable
AUTHORIZATION_HEADERS_TO_PROXY as a comma separated list of headers which could contain the authorization token used by the user service called by the
This env variable is not required, and if it is not set the user service is called for every incoming request. If this env var is set, it brings an enhancement in performance for all APIs called without an authorization header since it avoids calling the user service: user is set as empty.
The responses of the authorization service are the same as before, when the get user api responds with 401.