Access Rights

The protection of available data is handled at multiple layers. We use an industry standard system based on IdentityServer4 to handle identity management in a product name Passport, and propretary methods to implement authorization in a product called Vault. Using these two systems in conjuntion with each other we can ensure the security of our public and private systems.

It is important to note the difference between Authentication and Authorization.

  • Authentication is determining who the user is.
  • Authorization is determining what the user can do.

3rd party applications also require some governance in the form of which capabilities they have and what actions they can carry out against our endpoints. This feature is provided by Passport.

Client Applications

Each unique client application will require it’s own Client ID and Client Secret registered with Passport. These details will need to be passed to Passport when initiating a User session. Using this information, Passport will return a list of valid scopes in the access token. This list defines the capabilities of the Client Application and is used by the services the application connects to.

Roles

We use Roles to implement coarse grained permissions. Generally this is whether or not a User has access to a particular product. A Role is bound to a User, and a User can have multiple Roles. Roles should appear in the access token when one is requested correctly, and can be viewed when deserialised.

Permissions

Permissions are fine grained access rights and are provided by Vault. These rights are not visible directly to the public. They control the behaviour of services when a user interacts with it. Each system determines it own set of permissions.

Access Token

An Access Token issued by Passport is used to make subsequent authorised calls to any of our services. It will be formatted as a JSON Web Token (JWT) which is an industry standard (RFC 7519). Information about it’s structure and implementation can be found on Wikipedia. If you wish to inspect a token, you can visit jwt.io.

Conventions used

Roles, Scopes, and ClientID’s can be coded with any text value. However, to reduce confusion we have implemented a set of conventions to help dispel any ambiguity.

  • Roles are ‘:’ separated values (service:level) e.g. Passport:Administrator
  • Custom Scopes are ‘/’ separated values (service/capability) e.g. Zenith/Trading
  • ClientID’s are ‘$’ separated values (client$app) e.g. Motif$Web