RC (PCAB) MIS authorization

Purpose

This process is designed to perform and validating authorization of MIS clients.

Key points & Requirements

1. For identifiers of MIS clients (as a broker) we use term API-key.

2. API-key would be issued for new specific user-type in mithrill (i.e. MIS). API-key is a mis_client_secret - Medical Information System secret key issued upon integration request.

3. Each MIS would have list of allowed scopes

4. 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.

5. If MIS don't send api-key in Request HEADER, API return 401 error wih message "API-KEY header required".

6. For identifiers of MIS clients we use header X-Custom-PSK.

7. We use X-Custom-PSK header for check hosting provider. If X-Custom-PSK is correct we get access to `kong` MIS routes.

8. Each MIS must mandatory send X-Custom-PSK when called any eHealth API.

Service logic 

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. 

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:

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!

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:

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.

1. Get `client_id` from `token`

2. Read `clients` for `client_id`.   (further in the text - `REQUEST_CLIENT`)

3. Extract `access_type` from `priv_settings`. 

4. If `access_type` = `BROKER` 

   1. Read   `API-key` from HEADER

      1. if API-key missing - return 401 error  "API-KEY header required !" 

   2. Validate  `API-key`. (see details: RC (PCAB) [Internal] Apikey verify )

      1. Validate exists `secret` in table `clients`

         1. if invalid - return 401 error  "API-KEY header required !" 

      2. Read `clients` with `secret`(API-key) in header.  (further in the text - `BROKER_CLIENT`)

      3. Extract `broker_scopes` from `priv_settings` . 
         
         

         1. if not found `broker_scopes` -  return 401 error  "Incorrect broker settings!" 

      4. Read needed scopes for call API Endpoint (read from GateWay configuration - "/gateway-config.yaml")

      5. Validate exist needed scopes in `broker_scopes` of `BROKER_CLIENT`.

         1. if invalid - return 403 error " Scope is not allowed by broker"

5. If `access_type` = `DIRECT` 

   1. break validation.

Configuration examples