Authorization in PoC 11&13

[jorritspee]

Intro

We need to specify how we want to authorize incoming requests in the context of PoC 11&13, given the fact that we also want to define a generic function Authorization.

Interactions that need authorization

1. Receiver organisation authorizes incoming notification message
2. Sender organisation authorizes incoming read-request on Workflow/eOverdracht-Task
3. Sender organisation authorizes incoming read- and/or search-request(s) on data
4. Sender organisation authorizes incoming update-request on Task

Setup

1. We will use Policy-based access control (PBAC)
2. For each interaction a policy will be defined
3. Policies will be defined in Rego
4. Parties that are part of PoC 11&13 are free on how to implement the policies (using of not using Rego)
5. Knooppunt contains a PDP that supports policies defined in Rego
   • When using Knooppunt, Sender-party creates a Consent-resource that models the implicit consent before sending out the notification message

Policies

1. Receiver organisation authorizes incoming notification message

Only allow if

1. Requesting-party is a Healthcare Organisation
   • Proven by presenting a valid URA --> Authenticated using GF Authentication

Rego source-code: [INSERT LINK TO REGO]

2. Sender organisation authorizes incoming read-request on Workflow/eOverdracht-Task

Only allow if

1. Requesting-party is a Healthcare Organisation
   • Proven by presenting a valid URA --> Authenticated using GF Authentication
2. Requesting-party is owner/partOf of the workflow-task.
   • Proven by presenting a valid authorization-base from Notification-message AND/OR do something with the Consent-resource

Rego source-code: [INSERT LINK TO REGO]

3. Sender organisation authorizes incoming read- and/or search-request(s) on data

Only allow if

1. Requesting-party is a Healthcare Organisation
   • Proven by presenting a valid URA --> Authenticated using GF Authentication
2. Requesting-party is owner/partOf of the workflow-task.
   • Proven by presenting a valid authorization-base from Notification-message AND/OR do something with the Consent-resource
3. Requesting-party is a Healthcare professional
   • Proven by presenting a valid Dezi-number --> Authenticated using GF Authentication
4. Requesting-party has a medical profession
   • Proven by presenting a valid Dezi-role code (doctor) --> Authenticated using GF Authentication

Rego source-code: [INSERT LINK TO REGO]

4. Sender organisation authorizes incoming update-request on Task

Only allow if

1. Requesting-party is a Healthcare Organisation
   • Proven by presenting a valid URA --> Authenticated using GF Authentication
2. Requesting-party is owner/partOf of the workflow-task.
   • Proven by presenting a valid authorization-base from Notification-message AND/OR do something with the Consent-resource
3. State of Workflow-Task is not active (not "closed"/"complete"/"cancelled"
   • Find Task by URA of Requesting-party (see bullet 1)

Rego source-code: [INSERT LINK TO REGO]

[Dirklectisch]

@jorritspee The Nictiz specification for e-overdracht specifies that you need to move the task state forward through a PUT operation. This call needs to be authorised as well. We see a couple of ways forward:

1. Put this out of scope for the authorization generic function
2. Adapt the spec to use a PATCH instead of a PUT and check if the PATCH only modifies the status field
3. Keep using the PUT and implement some extra logic as input for the Rego policy

With regards to option 3. we thought how this could work in Knooppunt. We would introduce in case of a PUT an extra PIP call that fetches the resource and compares which fields have changed. The PolicyInput data model would contain a list of paths of changed fields.

In any case this needs to be part of the spec.

[jorritspee]

Sharp!
I forgot about this one. I think we need to add it, so I am not in favor of option 1.
I do not understand why a PATCH is so much different than a PUT. Why is that?

[SimonVeldhuijzen]

I don't see any reference to mutating the task in the script for Poc 11/13

[jorritspee]

I tried to process this in step 4 ✅

[Dirklectisch]

For 2.2 we thought to use a consent resource as a general solution for authorising single resources.

[Dirklectisch]

We also want to use this construct for 4.4 instead of deriving it from the call and resource itself.

[jorritspee]

Okay I didn't know. Will change this.
Can you provide an example of this Consent-resource and/or describe the rules that use this Consent-resource as a parameter?

[jorritspee]

And will also process it in 3.4

[jorritspee]

I think I processed it ✅

[Dirklectisch]

3.3 Requesting-party has a medical profession

Which role codes should we use? Is it a static list of codes?

[jorritspee]

Yes, there is a static list of codes for this (BIG-codes, see https://decor.nictiz.nl/pub/eoverdracht/e-overdracht-html-20120928T120000/vs-2.16.840.1.113883.2.4.15.111.html)

[edwinrozendom]

3.4: Sender organization authorizes incoming request on patient identifying data

The current "TA notified pull" spec uses a authorization-base claim in a authentication-token to link query-calls to an active workflow-Task (could also be a consent resource). Instead of "Find Task by URA" could it also be "Find Task by authorization-base", then you can have a more specific authorization within an organization (with also support if one patient has multiple tasks with the same organization).

e.g.

• Resource 1 is allowed to be queried if there is an active task with type X for Organization Z
• Resource 2 is allowed to be queried if there is an active task with type Y for Organization Z

TA notified pull:

[edwinrozendom]

@jorritspee see comment above, this was for item 3.2 (Requesting-party is mentioned in Consent-resource). It is now mentioned as "When using Knooppunt", but I think it's a policy that is also relevant for all implementations.

Verify if the workflow-task is active and that the requesting-party is part of the workflow-task would be a useful authorization. I would describe it as:

1. Requesting-party is a Healthcare Organisation
   • Proven by presenting a valid URA --> Authenticated using GF Authentication
2. Requesting-party is owner/partOf of the workflow-task.
   • suggestion: Proven by presenting a valid authorization-base (not sure if it can be a claim as part of GF authentication)

(one patient can have multiple workflow-tasks with the same organization)

[jorritspee]

I tried to process this ✅ .
Questions:
@bramwesselo: will we use the authorization-base element in the Notification-message?
@Dirklectisch: if we use the authorization-base element, do you still want/need to create a Consent-resource? I guess we can then do without it.

[edwinrozendom]

@jorritspee thanks a lot! Looks great. @bramwesselo and @Dirklectisch ☝️, did you take a look at the question from Jorrit?