This is especially hard in a federated environment (like XDS and XCA)
What is the SAML claiming?
SAML assertion (i.e. XUA) is a claim about the 'user' that caused the transaction to happen. This isn't wrong, if that is indeed going to be the scope of the access that will be given to the response. This perception is common, because we sometimes need to use the example of 'user' to help differentiate the SAML assertion from the TLS identity (i.e. ATNA). The reality is that they can be the same, if that is the right scope. One might do this too, as the SAML assertion is far more accessible on the service layer application code, the TLS identity is hard to get at.
The most likely case is that the response to a request will be incorporated into the requesting system (e.g. EHR), and thus further managed by that requesting system's access control rules. Thus the SAML assertion should be identifying the 'entity' that represents the scope of where the data will be available. This thus should then be the sum total of the roles, where your local roles are harmonized into the role vocabulary used in the Exchange.
This is also true about the PurposeOfUse statements. Meaning one must ask for all intended PurposeOfUse. One can't presume that 'treatment' is understood by the recipient as meaning both 'treatment' and 'payment'; and certainly doesn't mean 'research' and 'marketing'.
Deeper dive on the DS4P use-caseThis issue was brought to light during the DS4P efforts. This is especially troubling in this environment as the Legal Release is a targeted release, and thus a broad request should be rejected. Thus we have a miss-match between the desire to get the most broad access to the data, while the data might need to be fine-grain controlled. How to resolve this is not yet clear. The DS4P presumes that a broad request can be responded to with constricted rules, but there is no pathway for this returned restriction.
Authorization vs IdentityThe point to be made at this point is that the SAML assertion we generally use (e.g. XUA) is an assertion of identity, yet a SAML assertion can be an assertion of authorization. These authorization assertions are more commonly associated with XACML environments. Note that in OAuth, they are all primarily authorization tokens where the authorization is ignored and the identity is used. Same result different perspective.
OAuth token scope constraint. In both XACML and OAuth there is presumed to be a central all-knowing Access Control authority. This is simply not true in a federated architecture. So we tend to make multiple levels of decision, allowing the resource holder to be the final decider.
So what do we do with a SAML Identity Assertion environment?The current architecture, using SAML Identity Assertions, result is that somehow the requester needs to ask for a rather broad request, yet recognize that this broad request might be too broad for the access control rules to allow. Which means you might get rejected. The rejection code should indicate that the rejection in this case is due to too broad of a request. You could then try again with a more constrained SAML Identity Assertion.
ConclusionSo, the currently used SAML identity assertion (e.g. XUA) should identify the widest scope. Resources should recognize this. This is reality, not some hack. This is backoff mechanism is cumbersome, but if you tune your initial requests to 80% of the cases (Normal medical records for treatment use only), then the result is mostly success. The 20% (I am not claiming real values) then recognize that they need to be handled differently (probably individually and without automatic incorporation into the EHR). This can all be handled automatically by the requesting software. It does NOT need to involve the user.
Moving beyond this model is very hard. It requires a backbone of Access Control decision points that are 'all-knowing', and 'fully trusted'. I don't see this happening. I think Federation is more sustainable, and scales.
I have other articles on the Access Control topic:
- Healthcare access control scope constraints on OAuth tokens
- Advanced Access Controls to support sensitive health topics
- Policy Enforcing XDS Registry
- Healthcare Metadata
- Texas HIE Consent Management System Design
- Data Classification - a key vector enabling rich Security and Privacy controls
- Healthcare Access Controls standards landscape
- Handling the obligation to prohibit Re-disclosure
- Access Controls: Policies --> Attributes --> Implementation
- IHE - Privacy and Security Profiles - Consistent Time
- IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
- IHE - Privacy and Security Profiles - Enterprise User Authentication
- IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
- IHE - Privacy and Security Profiles - Access Control