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 attribute `access_type` with values (`direct`, `broker`) in JSON object in column `client.priv_settings` for mark such clients.
We extract client access type from token, analyze `access_type` = broker, and require brokers (not own) API-key in WS request.
Client_type | Purpose | access_type |
---|---|---|
Auth_FE | Auth frontEnd | direct |
MSP | Medical service provider | broker |
MIS | Medical information system | direct |
NHS_Admin | Admin console of the NHS | direct |
MITHRIL ADMIN | Admin console of the Mithril itself | direct |
PHARMACY | Pharmacy | broker |
UADDRESSES ADMIN | Admin of UA adresses | direct |
Send & Get API-key
Some clients (which `access_type` = broker) 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 broker 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 attribute `broker_scopes` in JSON object in column `client.priv_settings`.
If attribute `broker_scopes` not exist in `client.priv_settings` - we don`t need validate access over broker!
Client_type | Purpose | client.priv_settings |
---|---|---|
Auth_FE | Auth frontEnd | |
MSP | Medical service provider | |
MIS | Medical information system | "broker_scopes": "legal_entity:read declaration:read employee:read" |
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 `priv_settings` in table `clients`.
Example:
{ "allowed_grant_types": [ "password", "access_token" ], "access_type": "direct", "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`.
Clear, but not delete!
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`)
- Extract `access_type` from `priv_settings`.
- If `access_type` = `broker`
- Read `API-key` from HEADER
- Validate `API-key`.
- Validate exists `secret` in table `clients`
- if invalid - return error "Not found API-key!" (!!! text error - TBD)
- Read `clients` with `secret`(API-key) in header. (further in the text - `BROKER_CLIENT`)
- Extract `access_type` from `priv_settings`.
- If `access_type` = `broker` - return error "Incorrect API-key!" (!!! text error - TBD)
- Extract `broker_scopes` from `priv_settings` .
- if not found `broker_scopes` - - return error "Incorrect broker settings!" (!!! text error - TBD)
- Read needed scopes for call API Endpoint (read from GateWay configuration - "/gateway-config.yaml")
- Validate exist needed scopes in `broker_scopes` of `BROKER_CLIENT`.
- if invalid - return error "Conflict !" (!!! text error - TBD)
- Validate exists `secret` in table `clients`
- If `access_type` = `direct`
- break validation.
Configuration examples
Comments | clients.priv_settings |
---|---|
MSP | { "allowed_grant_types": [ "password", "access_token" ], "access_type": "broker" } |
Incorrect MSP | { "allowed_grant_types": [ "password", "access_token" ], "access_type": "direct" } |
Normal MIS | { "allowed_grant_types": [ "password", "access_token" ], "access_type": "direct", "broker_scopes": "legal_entity:read declaration:read employee:read" } |
Full blocked MIS | { "allowed_grant_types": [ "password", "access_token" ], "access_type": "direct", "broker_scopes": "" } |
Incorrect MIS | { "allowed_grant_types": [ "password", "access_token" ], "access_type": "direct" } |
Incorrect MIS 2 | { "allowed_grant_types": [ "password", "access_token" ], "access_type": "broker", "broker_scopes": "legal_entity:read declaration:read employee:read" } |