Role-Based Access Policies

Users can interact with the system in some context. For example, as a Patient. You need a resource to store this context information (i.e. patient_id or practitioner_id, for example). The simplest approach is to store this info in User resource, by extending it or using generic User.data element. This information will be available for AccessPolicies, because the user resource is a part of request context. Here is an example access policy for the patient/user:
1
---
2
resourceType: User
3
id: user-1
4
data:
5
  patient_id: pt-1
6
​
7
---  
8
resourceType: Policy
9
engine: matcho
10
matcho:
11
  uri: '#/Patient/.*'
12
  request-method: get
13
  params:
14
    # this is parameter. which is set into resource.id
15
    resource/id: .user.data.patient_id
Copied!
The problem with this approach can appear, if you want to allow the user update his User resource. Or for multi-tenant systems, where users can be a part of multiple organisations or departments,  they can potentially interact with a system in different roles. You can imagine Outpatient EHR with multiple locations and physicians, who can work in some of these locations. Aidbox provides you with the Role resource, which can keep this context information and integrated it with the Access Control engine in a sophisticated way. Let's say we have multi-organisation system with users, who can play different roles in different organisations.
A new Role resource is intended to help solve such problems. 
1
---
2
desc: User role
3
attrs:
4
  name:
5
    type: string
6
    isRequired: true
7
    search: { name: name, type: string }
8
  description:
9
    type: string
10
  user:
11
    type: Reference
12
    isRequired: true
13
    refers: [ User ]
14
    search: { name: user, type: reference }
15
  links:
16
    attrs:
17
      patient:
18
        type: Reference
19
        refers: [ Patient ]
20
      practitionerRole:
21
        type: Reference
22
        refers: [ PractitionerRole ]
23
      practitioner:
24
        type: Reference
25
        refers: [ Practitioner ]
26
      organization:
27
        type: Reference
28
        refers: [ Organization ]
29
      person:
30
        type: Reference
31
        refers: [ Person ]
32
      relatedPerson:
33
        type: Reference
34
        refers: [ RelatedPerson ]
35
  context: { isOpen: true }
36
​
Copied!
Role links User and AccessPolicy with roleName = Role.name:
1
---
2
# special role policy
3
PUT /AccessPolicy/practitioner-role
4
​
5
roleName: practitioner
6
engine: matcho
7
matcho:
8
  uri: '#/Practitioner/.*'
9
  params:
10
    # you can access role by .role
11
    resource/id: .role.links.practitioner.id
12
​
13
---
14
PUT /Role/pr-u-1
15
​
16
# should match roleName of AccessPolicy
17
name: practitioner
18
user: {id: user-1, resourceType: 'User'}
19
links:
20
  practitioner: {id: pr-1, resourceType: 'Practitioner'}
Copied!
AccessPolicies with .roleName attribute evaluated only if a User has roles such as Role.name=policy.roleName . Such AccessPolicy can access user role resource as .role for macho engine or {{role...}} for SQL and JSON engines. 

Access Policies tutorial

Access Control

Last modified 1yr ago

Copy link