...

Medical events Access policy can be found here

General Concept design

1. ABAC is an independent microservice
2. It is responsible for granting access to resources based on attributes of any business entity that are requesting access for.
3. Service will not support UI editing of rules
4. Service should provide RPC (or similar as service must not spend additional computation time on decoding/encoding and networking)
5. Service must store audit log in files with two main events: "Successful access grants", "Access rejects".
6. Service must cache data for resources, with cache lifetime on per resource sets
7. ABAC is additional level of authorization on the top of the regular scope-based access model.

...

1. ABAC might (NOT MUST) be used as a plug for any ME endpoint or even ehealth endpoint. Otherwise there might be performance issues.
2. It should be checked on the gateway level.
3. We do limit access by default. It means that all the rules describe conditions when access is allowed. If there is no rule matched - access is forbidden.
4. If ABAC failed to answer - access is forbidden.
5. ABAC - mission critical service
6. interfaceInterface: external: http, data providers: RPC
7. Input:
   1. WHO
      1. user_id
      2. client_id + client_type
         
   2. action: CREATE, READ, UPDATE, DELETE
   3. WHAT
      
      1.  object_type(resource) + object_id(optional)
      2. list of contexts (patient, episode):
         1. object_type + object_id
8. Output:
   1. decision: true/false

   2. Anchor
      Future Future

      To be considered in future!! Conditions - optional. Is relevant for lists. Defines additional instructions for the requested application.
      1. For example: client_id context should be applied
      2. For example: speciality context should be applied
9. Technically ABAC can take decision based on attributes of any entity. But to minimize load on the service it has been decided that we do restrict access not lower that on EPISODE level.
   1.  examples:
      1. access to endpoint like  `/api/patients/{patient_id}/conditions/{condition_id}` will be granted based on patient level rule
      2. access to endpoint like  `/api/patients/{patient_id}/conditions/` will be granted based on patient level rule
      3. access to endpoint like `/api/patients/{patient_id}/episodes/{episode_id}/encounters/` can be granted based on patient or episode level rule
      4. If there is a rule that allows user to get access to the patient level, but no rule that allows on the episode level, access should be allowed

Limitations

1. ABAC doesn't provide possibility to manage access to lists of resources - May be implemented in future
   
2. It means that if there is a business rule that '/api/patients/{patient_id}/conditions/' should return only conditions that are referenced to episodes of the legal_entity. This rule will not be implemented on ABAC

Limitations

1. When accessing list of entities, ABAC can only grant access to the whole list or forbid the whole list. ABAC does not cut the response in order to show only entities allowed by the rules.
2. When accessing list of entities, only one rule could be applied. That means ALL entities from the requested list should be allowed by that one rule. To achieve this, search parameters are used as context. For example, to read episodes, created in the doctor's MSP, doctor can request list of episodes, filtered by managing_organization_id. Managing organization, in this case, will be considered as a context and validated by corresponding rules. If one of the rule returns true, user can access the requested list. This way each entity from the list wasn`t validated by each rule separately, that significantly saves computing time.

Architecture

Data model

...

https://docs.google.com/spreadsheets/d/1A59VIXzxJGLxdd6XH2siPQqOcgVfkGy-1mpR7_4vK4Y/edit#gid=0

Permission definition language - TBD

Rules