MIS authorization

Purpose & Requirements

separate MIS API-key has to be introduced
API-key would be issued for new specific user-type in mithrill (i.e. MIS)
each MIS would have list of allowed scopes as per mithril spec
MIS API key authorization has to take precedence over all other user (i.e. MSP/client) authorization checks. For example: if MIS is unauthorized to register Declaration, but MSP is authorized, request has to be REJECTED, because MIS check has higher priority.
we have to decide on a specific error message to be returned in case of unauthorized MIS. Message should be very specific, and not overlapping with any other messages in the system, i.e "403 Forbidden Client"

Implementation

MIS API-key

For identifiers MIS clients (client_type = MIS) we use term API-key. We store API-key in `secret` attribute шт 'clients` table.

Condition for validate MIS API-key mandatory

For some clients (client_type = MSP, PHARMASY, ..) we need require mandatory access only transfer across MIS (MIS is a broker).
Proposed use new column `access_over_broker` (boolean) in table `client_types` for mark such clients.

We extract client_type from token, analyze `access_over_broker` = TRUE, and require broker (not own) API-key in WS request.

Client_type	Purpose	access_over_broker
Auth_FE	Auth frontEnd
MSP	Medical service provider	TRUE
MIS	Medical information system
NHS_Admin	Admin console of the NHS
MITHRIL ADMIN	Admin console of the Mithril itself
PHARMACY	Pharmacy	TRUE
UADDRESSES ADMIN	Admin of UA adresses

Send & Get API-key

All clients (all client_types) must be send (mandatory) API-key as a attribute `API-key` in HEADER all request.

Example:

curl --include \
     --request POST \
     --header "Content-Type: application/json" \
     --header "Authorization: Bearer mF_9.B5f-4.1JqM" \
     --header "API-key: d09vQUFlWTZ6Q0RXRDJISldUOVQ3dz09" \
     --data-binary "{
  \"medication_request_request\": { 
....

Manage MIS transfer scope

For some clients (client_type = MIS) which provide transfer for call API - we need mandatory validate possibility access to API endpoints.

Proposed use new column `validate_broker_scopes` (boolean) in table `client_types`.

Client_type	Purpose	validate_broker_scopes
Auth_FE	Auth frontEnd
MSP	Medical service provider
MIS	Medical information system	TRUE
NHS_Admin	Admin console of the NHS
MITHRIL ADMIN	Admin console of the Mithril itself
PHARMACY	Pharmacy
UADDRESSES ADMIN	Admin of UA adresses

For clients (client_type = MIS) on which we will check access for call API endpoint - we need describe the list `broker_scopes`.
Proposed manage & store list `broker_scopes` in attribute `settings` in table `clients`.

Example:

{
  "allowed_grant_types": [
    	"password",
    	"access_token"
  ],
  "broker_scopes": 
  		"legal_entity:read
		 declaration:read
		 employee:read"
}

In case of need complex disconnect MIS for transfer of call API endpoints - we need full clear him `broker_scopes`.

Validate MIS transfer scope

When MSP call specific API endpoint over (transfer) MIS we need validate possibility to access.

Get `client_id` from `token`
Read `clients` for `client_id`. (further in the text - `REQUEST_CLIENT`)
Read `API-key` from `API-key`
Validate `API-key`.
1. Validate exists `secret` in table `clients`
  1. if invalid - return error "Not found API-key!" (!!! TBD)
2. Read `client_types` for REQUEST_CLIENT. Validate `access_over_broker`=TRUE
  1. If invalid - break validation.
3. Read `clients` with `secret`(API-key) in header. (further in the text - `BROKER_CLIENT`)
  Read `client_types` for this BROKER_CLIENT.
  Validate `validate_broker_scopes`=TRUE
  1. if invalid - return error "Incorrect API-key!" (!!! TBD)
Get `broker_scopes` from `settings` in table `clients` for `BROKER_CLIENT`
Read needed scopes for call API Endpoint (read from GateWay configuration)
Validate exist all needed scopes in `broker_scopes` of `BROKER_CLIENT`.
1. if invalid - return error "Conflict !" (!!! TBD)