Permission (/right) registration from Service

Status

Proposed.

Context

Currently the roles a user is assigned is composed of a number of boolean permissions. These permissions are aspects of any one service for it to ensure that the user/principle has the required permission for some given operation of that service. For expediency however a basic design maxim of our Independent Services was bypassed while implementing this system: the set of permissions owned by a Service was hard-coded into the Reference Data service. Doing this violates the design goal of having independently deploy-able services: every service that owned a permission(s) was dependent on the Reference Data service to be updated and deployed first, should the set of permissions from that service change.

In correcting this design toward independent deployability, we have considered a number of approaches, including moving a Service’s permissions to be federated and discoverable among the services, and allowing a service to register it’s permissions with the Reference Data service at run-time. We’ve also considered how permissions, and their assignment to Roles, can change over the lifetime of a Service in keeping with our design principle for easy upgrades.

Decision

• We will build in GET and PUT operations to the API of the Reference Data service to register a Permission.

• We will not build API operations for DELETE of the Reference Data service to de-register a Permission.

• We will not build API operations to find Roles with a given permission, to migrate permissions, as this hasn’t been needed to date.

• Any service with a Permission to register will do so with Reference Data at run-time. If the Reference Data service is unavailable, the service will try again until successful.

Consequences

• New services will be written to register their Permission(s) with Reference Data.

• The currently hard-coded Permissions in each Service will be migrated out of Reference Data, into a run-time registration activity that the owning service will register.

• Permission to Role assignments, user-permission strings, and other aspects of Permissions will stay in the Reference Data service of active deployments - no migration needed.