Authentication and authorisation


Every Restspace service has authentication settings. These specify which if any roles a user needs to have membership of to be able to access the service. These are given in 3 settings:

  • readRoles
  • writeRoles
  • createRoles

readRoles specifies who can read the data in the service, or for processes which process data, who can process data through the service. This means that a POST request for processing services has its authentication given by readRoles, but for data storage services, where it generally means write the data, it has its authentication given by writeRoles. A GET request is always authenticated by readRoles, and a PUT request is always authentication by writeRoles (or createRoles). createRoles is optional and if supplied, is used to authenticate requests where a new data item is created rather than an existing one being modified.

Users in Restspace can be members of an arbitrary set of roles, but Restspace has a standard set of roles: 'U' (ordinary site user) 'E' (non-administrative content editor) and 'A' (administrator). 

A roles list is a space separated list of identifiers, each identifier is a role that could be found on the roles list of a user. For instance a service with

E A Technical

as its readRoles could be read by any user with at least one of the roles 'E', 'A' or 'Technical' in their roles list.

A roles list can also specify variant roles for subpaths of the path space controlled by the service. As an example

E /restricted A Super

would mean that for a service whose base path was /json, any requests to /json/restricted would require a user to have at least one of the roles 'A' or 'Super', whereas for all other paths beginning /json, the user would have to have the role 'E'.

Notice there's no built in heirarchy in the roles system, while you would assume an Administrator could do everything a User could, you need to explicitly implement this by giving Administrator users the 'U' role as well as the 'A' role.

Technical details

Restspace's authentication is managed by the authenticationService, together with the userService. The userService stores user data referred to by the authenticationService to allow login. Currently there is only one type of authentication. On successful login the authenticationServices sets a cookie on the request with a JWT (JSON Web Token). The authenticationService then inspects any incoming request for such a cookie and sets the user on the request if one is found.

Role checks are only applied by the routing system to external requests. Once the check is passed, it is not repeated for further internal requests, for instance made by a pipeline. In general a service should not be configured so that it makes requests to other services with stronger security restrictions than it has itself, unless it is being used to expose a part of the data under that service's control with lower restrictions.

Since all services are by default exposed to the internet, care should be taken not to expose functionality you do not want externally available.