Authorization module performs access control to the eHealth resources. Protected objects - REST endpoint + method
For example:
GET /api/legal_entities
POST /api/employee_requests
POST /api/employee_requests/:id/approve
Auth module doesn't take into attention the exact instance of the resource. It stops on the resource type level.
For example `POST /api/employee_requests/:id/approve`. Auth will check whether user can approve employee_requests in general, not the particular :id of employee_request.
Level | Description |
---|---|
no protection | some endpoints are not protected at all. In this case auth is not used. User→>eHealth system-->>eHealth For example: GET /api/dictionaries GET /api/uaddresses/regions |
direct access | Is used to access resources directly without MIS brokers. User-->>eHealth System will check whether user has access to the requested resource. access_token with the proper scope is required to access resource for example, endpoints that are used by the NHS admin: GET /api/innms |
broker access | Is used to access ehealth resources via MIS providers User-->>MIS-->>eHealth access_token with the proper scope is required MIS api-key with the proper broker_scope is required Most of the endpoints are protected with this level |
api-key access | Is used to access ehealth resources by other systems (clients). For example - MISes. No user token is required. MIS→>eHealth List of endpoints: GET /api/events/id GET /api/events POST /api/legal_entities |
The system should allow a user to:
The system should allow a system administrator to:
The system should allow authorized users to:
Source file for diagramm: OAuth 2 flow.txt
{client_id} and {client_secret} is generated for each MIS during registration process
MIS: exchange {code_grant} to {access_token} using {client_secret}
{access_token} has grants to get_contexts, set_context only |
MIS: request available user contexts (list of MSP) via get_contexts
Erd file in repository : https://github.com/edenlabllc/mithril.api/blob/master/specs/mithril.erd
Dictionary of user roles. Whenever new role is added in this dictionary, it should be implemented and supported in the system.
In PRM User_role is mapped to the employee_type.
role |
---|
ADMIN |
MIS USER |
UADDRESSES ADMIN |
MITHRIL ADMIN |
NHS ADMIN |
OWNER |
DOCTOR |
Links between users and roles. Role can be assigned only within some client context
List of clients, registered within the system
dictionary of client types. Whenever new role is added in this dictionary, it should be implemented and supported in the system.
Mithril will not allow client to request scopes that are not listed in the client_types.scope
Currently there are below client types:
Client_type | Purpose |
---|---|
eHealth_Auth | Auth frontEnd |
MSP | Medical service provider |
MIS | Medical information system |
NHS_Admin | Admin console of the NHS |
Auth_Admin | Admin console of the Mithril itself |
Auth flows may work differently based on the client_types:
1) TOKENS_TYPES_ADMIN - Results are filtered by the request parameters if any, client_id from token is ignored
2) TOKENS_TYPES_PERSONAL - Results are filtered by the request parameters if any, only records that belong to client_id from the token will be returned
3) TOKENS_TYPES_MIS - Results are filtered by the request parameters if any, only records that are created by client_id from the token will be returned
It is configured in the environment variables