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

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

1. MIS: Request login page using {client_id}
2. eHealth: Check whether MSP with {client_id} is not blocked (is_blocked=false)
   1. in case of error return 401 error: 'Authentication failed'
3. User: Log in to eHealth using username/password
4. eHealth: Callback to MIS with {code_grant}

5. MIS: exchange {code_grant} to {access_token} using {client_secret}

   {access_token} has grants to get_contexts, set_context only

6. MIS: request available user contexts (list of MSP) via get_contexts

7. MIS: Set current user context via set_context and exchange {access_token} according to current context
8. 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.

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:

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

tokens