Role naming

This was initially proposed by developers in probation and has been adopted by prison teams more recently.

General naming principles

Parts separated by two underscore characters

Single underscore character to separate words within parts

Role name parts

ROLE_{API}__{SUB DOMAIN}__{RESOURCE}__{ACCESS TYPE}

API: The name of the API, e.g. PRISONER_SEARCH

Sub domain: Optional sub domain area e.g. RESTRICTED_PATIENT

Resource: Optional name of the specific resource/operation e.g. MATCH

Access type: Level of access: Read only / Read and write (either RO or RW) etc…

Examples:

ROLE_PRISONER_SEARCH__RESTRICTED_PATIENT__MATCH__RO

ROLE_PRISONER_SEARCH__GLOBAL_SEARCH__RO

ROLE_MANAGE_USERS__USER_BASIC_DETAILS__RO

ROLE_MANAGE_USERS__NOMIS__CREATE_USER__RW

ROLE_CALCULATE_RELEASE_DATES__CALCULATE__RW

ROLE_CALCULATE_RELEASE_DATES__WORKING_DAY__RO

Exception

In addition to specifying the above fine grain role, a more general role name may be used for a specific trusted client.

An example of this would be making specific resources available for a dedicated UI - possibly in regard to using the Backend for Frontend pattern.

This will mean that the UI will not need so many roles adding and should make development of that UI a lot easier.

an example could be: ROLE_CALCULATE_RELEASE_DATES__CALCULATE_RELEASE_DATES_UI for instance and then the UI would only need that one role granting for all endpoints in Calculate Release Dates API.