Stream: hapi
Topic: Security per resource
Sean McIlvenna (Sep 12 2018 at 06:12):
There are examples of implementing security for resource types, or for compartments. But, are there examples of how to secure each individual resource? For example, Joe has access to Observation/1 while Jane only has access to Observation/2? They might be able to create their own resources, but wouldn't be able to see other resources unless they are given permission by someone who already has access to the resource?
John Moehrke (Sep 12 2018 at 15:10):
This is a question that should be directed to the Security and Privacy stream --- It seems you are asking about an implementation detail, not FHIR model, or hapi toolkit question.
Sean McIlvenna (Sep 12 2018 at 15:23):
No.. I'm asking how to do this in HAPI
John Moehrke (Sep 12 2018 at 15:30):
HAPI client or HAPI server? Meaning are you trying to access a server that has this level control, or are you trying to implement a server with this level control?
Sean McIlvenna (Sep 12 2018 at 15:33):
implement a server with this level of control
Sean McIlvenna (Sep 12 2018 at 15:33):
To add a little more information:
I'm considering using the Provenance resource to indicate what resources each user (who is also associated with a Person resource) is allowed to access.
I believe I figured out that from the "Authorization Interceptor" docs that you can create a conditional rule that runs custom logic for each request...
I was thinking something like this:
RuleBuilder rb = new RuleBuilder();
rb.allow().updateConditional().allResources().withTester(new TestAuthRuleTester(userPersonId));
rb.allow().deleteConditional().allResources().withTester(new TestAuthRuleTester(userPersonId));
However, in my TestAuthRuleTester implementation, I'm not sure how I would gain access to the resources in the server...
I took a look through the RequestDetails class and there doesn't appear to be anything that would grant me access to the resources in the DB. There is getFhirContext(), but that appears to only return resource definitions baked into the server (such as the base StructureDefinition for Observation, Patient, etc.)
John Moehrke (Sep 12 2018 at 15:36):
Okay, that is a far more specific question the HAPI experts can focus on. Yes, in those interceptors you would need to be able to access other resources (Consents, Provenance, the meta element of the resource being accessed, etc).
John Moehrke (Sep 12 2018 at 15:38):
what tends to throw people is when asking about Security, people often get blinders thinking you have an OAuth question. But in your case, due to the fine-grain access control, you need to add business logic above-and-beyond OAuth that is implemented at the Resource Server API.
Jens Villadsen (Mar 20 2019 at 10:40):
@Sean McIlvenna - if you intend to use withTester() you essentially need to inspect the datagraph and access the database using your own custom logic
James Fadeley (Oct 01 2020 at 16:16):
I'm actually having a similar issue.
As we have it, a Patient is supposed to have access to their Coverage, Related Person, Contract, Patient and Explanation of Benefit details. An example rule is like:
new RuleBuilder().allow().read().resourcesOfType(ExplanationOfBenefit.class).inCompartment(<IdType for Patient>)...
For the patient endpoints, this works perfectly fine for reads and searches. For EOBs however, it only permits the search request to go through if patient is explicitly mentioned either like _id=Patient/X or patient=X. Is there anyway to allow the search to go on and confirm the resources is in the Patient's compartment without stating it?
Jens Villadsen (Oct 01 2020 at 16:21):
@James Fadeley have a look at https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-server/ca/uhn/fhir/rest/server/interceptor/auth/class-use/IAuthRuleTester.html - it can be used in various ways to add custom security checks
Jens Villadsen (Oct 01 2020 at 16:22):
James Fadeley (Oct 01 2020 at 16:32):
Jens Villadsen said:
Thank you! I'll have a look.
James Fadeley (Oct 01 2020 at 17:41):
So the SearchNarrowingInterceptor seems to be a step in the right direction but the AuthorizationInterceptor is still coming down hard. Is there something I'm supposed to do to connect the two, or make the AuthorizationInterceptor recognize the addendum of SearchNarrowingInterceptor?
Jens Villadsen (Oct 01 2020 at 18:23):
see https://hapifhir.io/hapi-fhir/docs/security/search_narrowing_interceptor.html
James Fadeley (Oct 01 2020 at 18:55):
I did read and apply that. The interceptor is visited first and appends the Patient IdTypes to the AuthorizedList under compartments. However, it then visits AuthorizationInterceptor and still feels the need to deny the request.
In the Search Narrowing:
AuthorizedList cascadingList = new AuthorizedList() .addCompartment(<IdType>);
And in the Authorization Interceptor:
new RuleBuilder().allow().read().resourcesOfType(ExplanationOfBenefit.class).inCompartment(<IdType for Patient>)...
And it still blocks. Is there anything I'm not grasping?
Jens Villadsen (Oct 01 2020 at 19:02):
well ... you should allow access to the resource without the requirement of the 'inCompartment
Jens Villadsen (Oct 01 2020 at 19:03):
eg: ruleBuilder.allow().read().resourcesOfType(ExplanationOfBenefit.class).withAnyId().withTester( MyTester()).andThen() ...
James Fadeley (Oct 01 2020 at 19:07):
I'll give it a shot. Thank you!
Last updated: Apr 12 2022 at 19:14 UTC
