Stream: implementers
Topic: Security example
Oskari Koskimies (Nov 26 2019 at 21:19):
@Grahame Grieve
Hi Grahame,
You mentioned during today's presentation in Helsinki that you had an example showing why access control logic cannot sit outside the repository in the GraphQL layer? (leftmost vs. rightmost case on the attached slide)
BR,
--Oskari
John Moehrke (Nov 26 2019 at 23:33):
When elaboration, please differentiate Access Control 'decision' from 'enforcement'. Clearly enforcement is, and will always bee something that is within the FHIR Server. That said, the current SMART scopes are rather blunt to support many authorization decisions.
Grahame Grieve (Nov 27 2019 at 04:54):
this is a prompt for me to elaborate the use case
Oskari Koskimies (Nov 27 2019 at 05:24):
Clearly enforcement is, and will always bee something that is within the FHIR Server.
Could you elaborate? I'm new to FHIR, but if I have a simple CRUD REST API service for a given set of resources, I can't think of any reason why you couldn't implement both access control decision and enforcement in the GraphQL layer on top of the REST API (assuming of course that the REST API cannot be accessed directly by users). See e.g. https://www.apollographql.com/docs/apollo-server/security/authentication/. So there is something special to FHIR in this regard?
Grahame Grieve (Nov 27 2019 at 07:07):
in principle, you can enforce security in a layer in front of the engine as long as all the decision are made based on what you can see. So a graphQL based decision maker can see all the request and response resources, and decide, for instance, that a returned resource from the REST Api has a security label on it, and not return it
Grahame Grieve (Nov 27 2019 at 07:09):
this approach doesn't work if access control decisions are made on resources that don't you don't even see on the graphql layer. This principally occurs with chained search parameters
Grahame Grieve (Nov 27 2019 at 07:10):
e.g. if I do
GET [base]/Observation?code=xxx
The graphQL layer can inspect each returned resource, and decide whether it's acceptable according to some security rules
Grahame Grieve (Nov 27 2019 at 07:10):
but if the I do
GET [base]/Observation?code=xxx&encounter.class=yy
Grahame Grieve (Nov 27 2019 at 07:11):
the security rules for whether I can do that join, and which encounters can be seen in that join, cannot be enforced outside the join engine - e.g. in the graphQL engine that consumes that the REST Api. It doesn't know anything about the encounters
Grahame Grieve (Nov 27 2019 at 07:13):
in fact, extending that... a perfectly reasonable rule in the REST Api would be that you can't see observations associated with encounters that you can't see.... that's also pretty difficult to enforce in the graphQL layer, since the encounters aren't naturally visible
Also, this is all terribly slow compared to integrating these security things into you index / joins
John Moehrke (Nov 27 2019 at 14:23):
that is hard enough in pure FHIR REST... so, yes I could see how it is much harder in graphQL layer.
Also, similar complexity comes if the access control is "Attribute Based Access Control (ABAC)", that is where rules are leveraging various elements within Resources. Such as use of security/privacy tags in .meta.security to segment data.
John Moehrke (Nov 27 2019 at 14:25):
is it appropriate to consider graphQL in a case where data is so highly segmented based on privacy rules and business rules? It seems to be more appropriate to data that are singularly protected (such as a de-identified research database). In the case of a de-identified research database this would not be such a problem.. right?
Grahame Grieve (Nov 27 2019 at 15:50):
@John Moehrke this discussion was effectively about our diagram on the security page that shows implementation of a security engine in front the RESTful API. When teaching in Finland this week, I claimed that you could not implement all of the things you need to do for security in front of the API. the specific question nominated graphQL here because of personal relevance, but it's not the point; it's simply: what is it that you need to integrate into the query engine and you can't achieve in front of it
Grahame Grieve (Nov 27 2019 at 15:50):
and you're right that a de-identified database probably doesn't have any such cases
John Moehrke (Nov 27 2019 at 16:00):
yup. all models are broken, some are useful
Oskari Koskimies (Dec 08 2019 at 21:09):
in principle, you can enforce security in a layer in front of the engine as long as all the decision are made based on what you can see. So a graphQL based decision maker can see all the request and response resources, and decide, for instance, that a returned resource from the REST Api has a security label on it, and not return it
this approach doesn't work if access control decisions are made on resources that don't you don't even see on the graphql layer. This principally occurs with chained search parameters
Thanks for the explanation! I think the main difficulty I had in understanding the picture on the slide was that it only shows the GraphQL access to the system, and the system looks like a simple data repository. If it were only a database with REST API on top and a GraphQL interface on top of the REST API, I don't think there would be any issue with access control in the GraphQL layer. But in reality it is of course an arbitrarily complex healthcare backend system which has also other interfaces and which might not expose all of its data via the REST API (like you said). Maybe make the "clinical/healthcare repository" icon on the slide look less like a database and more like a backend system?
Grahame Grieve (Dec 08 2019 at 21:47):
ok I'll see what I can do in future, thanks
Last updated: Apr 12 2022 at 19:14 UTC
