Implement location/role based AccessChecker

[vivekmittal07]

Any practical Healthcare solution needs some form of Role based access control and also limit the access based on the primary location, organization, careteam of a practitioner.

We should support a configurable access checker to ease onboarding process for our partners.

Blocked on

• Design location/role based AccessChecker #105

[bashir2]

Thanks @vivekmittal07 for filing this; do you mind separating this to at least two (or maybe more) issues to make them more fine-grained. For example, the requirement/design doc can be a separate issue and based on that we can have 2-3 other tickets for the implementation. Please also add a little bit of context to the main issue description.

[jjtswan]

Marking as new, since this is blocked on #105.

[bashir2]

Moving to backlog until we clarify what the plugin should look like (and it is generic enough).

[bashir2]

Discussing this further with @vivekmittal07 and the team, it seems it is unlikely to implement something that is generic enough to be used out-of-the-box by any implementer. So this would serve only as another example. We decided this is not a Beta launch blocker.

[jjtswan]

Providing something usable out-of-the-box, or at least that was a potential stretch to if possible while providing a meaningful example that developers could look at as a reference example for their own policies - which was the actual main goal Without this, I think it will be very hard for developers to grasp and see here. Do we have such an example today? And if not, what would be an alternate, meaningful proposal after the research and investigation that has already been done?

…

On Mon, Mar 27, 2023, 8:48 AM Bashir Sadjad ***@***.***> wrote: Discussing this further with @vivekmittal07 <https://github.com/vivekmittal07> and the team, it seems it is unlikely to implement something that is generic enough to be used out-of-the-box by any implementer. So this would serve only as another example. We decided this is not a Beta launch blocker. — Reply to this email directly, view it on GitHub <#103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBU37TMRL2ITJ43Z6Y3KTLW6GZDHANCNFSM6AAAAAAU3ID6BQ> . You are receiving this because you commented.Message ID: ***@***.***>

[jjtswan]

Based on that I still believe this to be a beta blocker for viability of the FHIR gateway. But I was not at the discussion. On Mon, Mar 27, 2023, 8:59 AM Justin Jesada Tansuwan ***@***.***> wrote:

…

Providing something usable out-of-the-box, or at least that was a potential stretch to if possible while providing a meaningful example that developers could look at as a reference example for their own policies - which was the actual main goal Without this, I think it will be very hard for developers to grasp and see here. Do we have such an example today? And if not, what would be an alternate, meaningful proposal after the research and investigation that has already been done? On Mon, Mar 27, 2023, 8:48 AM Bashir Sadjad ***@***.***> wrote: > Discussing this further with @vivekmittal07 > <https://github.com/vivekmittal07> and the team, it seems it is unlikely > to implement something that is generic enough to be used out-of-the-box by > any implementer. So this would serve only as another example. We decided > this is not a Beta launch blocker. > > — > Reply to this email directly, view it on GitHub > <#103 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADBU37TMRL2ITJ43Z6Y3KTLW6GZDHANCNFSM6AAAAAAU3ID6BQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[vivekmittal07]

There are 2 possible goals for this -

1. Enable a partner to adopt FHIR Gateway by implementing an access checker which is generic and meets their access control requirements.
2. Build a sample Role/Location based access checker which may not solve a partner's use-case but can provide a good reference to start. Best case is if they are able to modify a few things to customize this based on their requirement.

We as a group think option 1 is more useful and also this will help with the FHIR Gateway adoption.
For option 2 we will make assumptions which might not be valid for a realistic usecase. Also we already have good access checkers which show how someone can consume data from Keycloak and read FHIR data for making access decision.

Action items for beta

• writeup design sketch of something that IPRD could/would use.
• Collect feedback from the FHIR community on the access control model.
• Add a design doc on github explaining how someone can implement Role/Location based access control model

Post beta, it would be good to implement this to see if we can get IPRD to start using this.