FHIR Operations in AccessPolicy #4374
Replies: 1 comment
-
@codyebberson Did you have any use cases off the top of your head for these types of constraints? Mostly curious about the decision to go with FHIRPath expression for resource constraints vs. search expressions. One argument I could see for that is to put less pressure on our in-memory search implementation. One possible resolution to the unwieldiness of
We'd have to define a precedence, but we can maybe leverage some best practices from AWS IAM (they have deny > allow). |
Beta Was this translation helpful? Give feedback.
-
Background
Medplum has a very powerful
AccessPolicy
feature, which can be used to control access to FHIR Resources.Some quick examples of
AccessPolicy
features:One area that is missing from the current
AccessPolicy
implementation is FHIR Operations.This all becomes even more powerful considering that Medplum specific entities are represented as FHIR Resources (
Project
,User
,ProjectMembership
, etc), and many non-FHIR Medplum APIs are represented as FHIR Operations (Agent/$push
,Bot/$execute
, etc)Considerations
Backwards compatibility vs breaking changes
The
AccessPolicy
structure has been stable for a while, by design. Users generally do not like to modify security settings, as there is always the inherent risk of inadvertently breaking things when you touch it.We should be sensitive and respectful of user needs when making changes to
AccessPolicy
.When considering backwards compatibility vs breaking changes, we should clearly choose one:
Interaction vs Operation
We have several internal conversations going on about aligning "interaction" and "operation" into a unified framework within the Medplum server implementation.
Currently, these are implemented in somewhat ad hoc fashion, typically as routes on a router. But that means that some aspects such as permissions and logging are implemented ad hoc as well.
There may be an elegant option here where "interaction" and "operation" are both represented together in
AccessPolicy
in a unified way.AccessPolicy inheritance
Currently, each AccessPolicy is completely independent, no inheritance of includes or
partOf
orlink
or anything like that.There is a very clear and desirable feature, to be able to reference other AccessPolicies, especially for something like "IP access rules", which enterprise customers often manage globally rather than per "group" or user type.
How would operations fit in with that?
"Resource.resourceType" vs "Element.path"
Tangentially related to this change, in the past we have discussed making
AccessPolicy
centered onElement
andElementDefinition
rather thanResource
. That has some elegant properties to it, such as aligning withStructureDefinition
and the FHIR spec in general. But it would probably also move us into "breaking changes" territory, for unclear gains.I think the "Resource" vs "Element" change is probably out of scope for this discussion. I only bring it up so that we can evaluate how the solution to FHIR Operations may be forward compatible with that change in the future.
Possible implementations
Super dumb and simple:
AccessPolicy.resource.allowedOperations
We have an existing backbone element on
AccessPolicy.resource
which represents access controls for a given resource type:We could add a new element:
Pros:
Cons:
Medium: Operation Rules
Similar to the previous option, we could add a new element
operationRules
and a new typeAccessPolicyOperationRule
.The model would use a linear list of rules, existing at the first matching rule.
Parameters
Pros:
Cons:
Others?
I know Medplum team members and community members have ideas here. Please share!
Beta Was this translation helpful? Give feedback.
All reactions