Implement Access Control

[hhund]

Implement access control for all resources based on either properties of the resource itself or a Provenance-resource "attached" to the resource with explicit read access. This is an umbrella feature request issue. For concrete implementation tasks see related issues #5, #14 an others that might be mentioned in the discussion below in future.

Generally speaking the idea is to only write Task-resources on remote FHIR-Endpoints and include absolute references within these Task-resources to other Resources (e.g. Binary) for the remote organization to download from you. Like this write access is generally not allowed for remote users except for Task-resources and read access needs to be granted based on properties or Provenance-resources for all other resource but is not allowed without explicit authorization.

[hhund]

We might not want to use Provenance resources for access control since Provenance resource are typically only used to document successfully executed task/events.

From the FHIR R4 specification: http://hl7.org/fhir/provenance.html

Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.

[usax001]

Maybe I overlooked it, but I am missing a general thread about Authentication and Authorization - which is closely intertwinded. Access Control may mean both.
So where do we get our user identities from with the cedentials that have to be presented at the PEP.

We looked at eduGAIN and other EU ressources before - fine.
DFN might be fine for Germany.
Others are looking at keycloak.org - any comments on that?

[hhund]

Maybe I overlooked it, but I am missing a general thread about Authentication and Authorization - which is closely intertwinded. Access Control may mean both.
So where do we get our user identities from with the cedentials that have to be presented at the PEP.

We looked at eduGAIN and other EU ressources before - fine.
DFN might be fine for Germany.
Others are looking at keycloak.org - any comments on that?

Thanks @usax001 for your comment, here are a few of my ideas on the subject.

We need to look at two distinct authentication/authorization problems within the Data Sharing Framework (DSF):

• Authentication and authorization of organizations with the DSF network. Authentication is based on DFN-certificates and authorization will be accomplished using a white-list and rules per resource. More on the authentication of organization in the authentication wiki page.
• Authentication and if necessary authorization of users. Within the DSF users only interact with there local FHIR and BusinessProcessEngine instances. But Users will be referenced by FHIR resource and need to be recognized across organizations. For example the ResearchStudy resource references a study PI and is used to communicate inclusion and exclusion criteria for sharing data.
  If we want to reference users across organizations we need to represent them as FHIR resources (Practitioner, PractitionerRole) on the DSF FHIR endpoint or a different FHIR server.
  If users should be allowed to directly perform (create/read/update/delete) actions on the FHIR server or the BuisnessProcessEngine they need to be authenticated and authorized at there local organization. This could be accomplished using SAML or OAuth2 (OpenID Connect) tokens. Keycloak is an authentication provider that could be used to create SAML or OAuth2 tokens. The Keycloak Server typically communicates via LDAP with the local organizations ActiveDirectory.
  If we want users to be able to authenticated them self across organizations the above mentioned tokens could be transferred via the DSF to the target organization. This will deviate from the typical (login with google/facebook) approach because the user never directly interacts with DSF FHIR endpoints and BusinessProcessEngines at remote organizations.

Looking at existing authentication networks like DFN-AAI, I'm not sure that they are a perfect fit for the problems we have to solve within the HiGHmed DSF. But I'm certain we can learn a lot from them especially when it comes to organizational procedures.

[hhund]

Some additional thoughts:

• Authentication and authorization of users for more traditional applications. If we were to run an application to support tumor board reviews centrally, traditional distributed approaches like DFN-AAI might suite our needs. With the exception that they might only differentiate roles like students, staff and professors. But I might be wrong here.

[hhund]

Some thoughts on different REST methods:

• GET / HEAD (by ID), needed for external organizations. filtered based on context, only allow resources with a link to the requesting external organization or for local user, link to the Practitioner / PractitionerRole resource.
• GET (search) only for local users, filter by link to the Practitioner / PractitionerRole resource
• POST / PUT / DELETE only for local users, only resources modifiable with link to the current users Practitioner / PractitionerRole resource.