General description

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.

Protection levels

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

Functional requirements

Authentication

The system should allow a user to:

Login to the system using a user name and password
Retrieve a missing password
Change a password
Authorize with 2-factor authentication
Change factor for 2-factor authentication

The system should allow a system administrator to:

Create user accounts, including login name, password, and appropriate roles and permissions
Activate and deactivate user accounts
Set time boundaries to user accounts (e.g. 06/08/09-08/14/09 for summer interns)
Manage users 2-factor authentication

Roles and Permissions Requirements

The system should allow authorized users to:

Provide security for different levels of user, e.g. Owner, HR, Doctor, Accountant, etc.
Define security at the function level, e.g. allow a user to access data entry functions only.
Restrict certain functions to authorized personnel only, e.g. certain user group has read-only access, another user group has ability to modify data.

OAuth 2 Flow (with 2-Factor Authentication ) is used

Source file for diagramm: OAuth 2 flow.txt

{client_id} and {client_secret} is generated for each MIS during registration process

MIS: Request login page using {client_id}
eHealth: Check whether MSP with {client_id} is not blocked (is_blocked=false)
1. in case of error return 401 error: 'Authentication failed'
User: Log in to eHealth using username/password
eHealth: Callback to MIS with {code_grant}
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
MIS: Set current user context via set_context and exchange {access_token} according to current context
eHealth: Respond with new {access_token} according to current context

Auth flow implementation

Auth ERD

Erd file in repository : https://github.com/edenlabllc/mithril.api/blob/master/specs/mithril.erd

users

roles

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

user_roles

Links between users and roles. Role can be assigned only within some client context

clients

List of clients, registered within the system

client_types

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

E-Health

Auth