What does the SAML assertion mean in a XDS/XCA query/retrieve?

I have received this question from multiple sites. I will take this as a really good thing. It shows a maturing of the HIE market. The question comes about from a few different perspectives, but ultimately it boils down to a question of what the meaning is of that SAML assertion that is put into the XDS or XCA query and retrieve transactions. The reality is that the problem is not unique to XDS/XCA, it is true of any transaction that uses the PULL model. That is where a request is made for some information, and some information is returned back.

This is especially hard in a federated environment (like XDS and XCA)

, as the Access Control decision can't be made ONCE. There is no central authority. The Access Control decisions and enforcement are federated / distributed. The Requesting environment (e.g. EHR) is expected it controls things within their environment, it has access controls inside the EHR system. The Responding environment may trust the Requester has done the right Access Control, it still would like the identity for audit logging purposes. The Responding environment might also want to do further access control rules.

In XCA (XCPD shown for emphasis that this isn't just XCA but any PULL style transaction.) there are multiple intermediaries, and the request will end up at many endpoints. Those endpoints can't be predicted at request time.This picture is even simple showing only two levels. This can be nested almost infinite levels.

What is the SAML claiming?

A common mistake is to presume that the 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-case

This 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 Identity

The 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.

The XACML way to do this is through two step mechanism. That is I ask the Access Control engine for authorization to access broad data.  I get back from that an authorization assertion, possibly with a constrained list of users/roles/purposeOfuse/etc. I use that authorization to do the XCA query.  Where as to day the SAML assertion is an identity assertion, not an authorization assertion. This is the topic I cover for  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.

Conclusion

So, 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