ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Purpose & Requirements

  1. separate MIS API-key has to be introduced
  2. API-key would be issued for new specific user-type in mithrill (i.e. MIS)
  3. each MIS would have list of allowed scopes as per mithril spec
  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. 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_typePurposeaccess_type

Auth_FE

Auth frontEndDIRECT
MSPMedical service providerBROKER
MISMedical information systemDIRECT
NHS_AdminAdmin console of the NHSDIRECT
MITHRIL ADMINAdmin console of the Mithril itselfDIRECT
PHARMACYPharmacyBROKER
UADDRESSES ADMINAdmin of UA adressesDIRECT

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_typePurposevalidate_broker_scopes

Auth_FE

Auth frontEnd
MSPMedical service provider
MISMedical information system"broker_scopes": "legal_entity:read declaration:read employee:read"
NHS_AdminAdmin console of the NHS
MITHRIL ADMINAdmin console of the Mithril itself
PHARMACYPharmacy
UADDRESSES ADMINAdmin 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.

  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
    2. Validate  `API-key`.
      1. Validate exists `secret` in table `clients`
        1. if invalid - return error  "Not found API-key!" (!!! text error - TBD)
      2. Read `clients` with `secret`(API-key) in header.  (further in the text - `BROKER_CLIENT`)
      3. Extract `access_type` from `priv_settings`. 
        1. If `access_type` = `BROKER` - return error  "Incorrect API-key!" (!!! text error - TBD)
      4. Extract `broker_scopes` from `priv_settings` . 
        1. if not found `broker_scopes` - - return error  "Incorrect broker settings!" (!!! text error - TBD)
      5. Read needed scopes for call API Endpoint (read from GateWay configuration - "/gateway-config.yaml")
      6. Validate exist needed scopes in `broker_scopes` of `BROKER_CLIENT`.
        1. if invalid - return error "Conflict !" (!!! text error - TBD)
  5. If `access_type` = `DIRECT
    1. break validation.


Configuration examples 

Commentsclients.priv_settings
MSP{ "allowed_grant_types": [ "password", "access_token" ], "access_type": "broker" }
Normal MIS{ "allowed_grant_types": [ "password", "access_token" ], "access_type": "direct", "broker_scopes": "legal_entity:read declaration:read employee:read" }
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" }
  • No labels