Federated ID is not a universal ID

I run into people who miss-understand Federated ID as requiring everyone to change to a universally issued user identity with universally issued roles. This is absolutely not true. Let me lay some ground work then bring them together.

For the most part I don’t think that user identity is important in cross-enterprise transactions like EHR requests into an HIE. Not because they are a bad idea, or that they are not good security; but rather because most of the usecases that we are looking at, and the interactions that are being executed are system-to-system or organization-to-organization. In this mode the two systems (or organizations) need to trust that the other system has done the appropriate pre-conditions and will do the appropriate post-conditions. This is Policy and Procedure: Don’t let a system connect that you don’t trust has the appropriate governance. What this means is that the client machine has done appropriate user authentication, authorization, and is otherwise a secure system. The communications is highly authenticated (TLS) on both client and server. The result returned back to the client will be properly handled, exposed only to authorized individuals, and the maintain audit logs of all accesses from that point forward. If we add a user identity to this transaction, it is mostly for a little bit better audit log on the service side.

The other side of this is that even if a user identity was provided it would be about the user that is right-now connecting. If this is a request from a clinical system (e.g. EHR) the result will be stored and others on the clinical system will gain access. So although the initial connection could be access controlled, the other future accesses within the EHR must be trusted to do the right thing. I worry that people see the user assertion and end up with a false sense that all accesses are singular accesses back to the original system. Thus there is a false sense of security, rather than a healthy-suspicion that doesn’t let the whole-system connect at all until the downstream workflows are checked out too. There are other transactional complexities that simply adding an assertion doesn’t help. But there are also applications other than an EHR that can operate on single-read-only-use (more on this later in this post)..

If we look at an EHR today, it has user authentication and access controls that have been built up over time to meet the requirements of being an EHR. The user authentication likely is highly flexible to support some rather strange workflows. One of the strange workflows is the exam room, where an administrative person walks the patient to an exam room and sets up the exam-room-terminal with the right patient then ‘locks the screen’. Next the nurse comes in to take complaints and vitals logs in, enters them, and logs out. Next the doctor comes in for the exam, again logs in to enter data and logs out. Each of these people are authenticating, but the workflow on the desktop is all about the patient. These authentication methods and authorization methods are sufficient to protect the PHI that is maintained inside that EHR. It is possible that an organization has gone to an enterprise class authentication system like Active Directory or more generically Kerberos or LDAP, but this is not required.

Lets look at interacting with an HIE or other organization that requires a SAML assertion. A SAML assertion is issued by an Identity Provider that supports SAML. This Identity Provider is configured to understand specific targets of the SAML assertions (known in SAML terms as an ‘audience’). The configuration will include mapping tables that indicate that when creating a SAML assertion for use within a specific HIE that some list of attributes need to be added to the assertion. One likely attribute is the HIE-role values which is assigned based on the Role or attributes within the Identity Provider. Thus if I am known as a Physician in my local LDAP Directory, but the HIE wants the role to come from a different valueSet where my role within the HIE would be “Care Giver” then it is up to the Identity Provider to do this mapping. This is a common thing for Identity Providers to do, as role vocabulary is not stable within any organization (not just healthcare) nor is it likely to be stable inside the HIE. What is important to recognize is that the SAML assertion is issued by an Identity Provider that does this mapping. The native user directory does not need to have the HIE-roles. When this SAML assertion is received by the Service Provider it is validated which checks that it was issued by an identity provider that is on the trusted-identity-provider-list. This allows the Service Provider to support many different Identity Providers, likely one for each clinic and hospital connecting to the HIE. Given that all of those identity providers have normalized their roles to the HIE-role vocabulary it is clear what permissions the user should have in the context of this transaction in the HIE.

I now bring together these two ideas. Given that the EHR has a mature user authentication and authorization system that is likely highly customized to the clinical workflows it is not likely that system can be replaced. The good news is that this is a mature system. So, one first step is to have the EHR be the Identity Provider. It is simply XML with a digital signature. Yes, the HIE better do proper checkout of this Identity Provider, but after this happens the HIE would trust it. I wrote up in a white paper for IHE on this topic in 2005: “XUA Implementation Demo 2005 Guide.doc” .



This may work long-term, but likely enterprises will choose to go to an enterprise class user-authentication system to gain all of the advantages of single-sign-on and much quicker user provisioning and de-provisioning. But once this transition is done, then that enterprise class user-authentication system should be specified as a cross-enterprise class user-authentication system. The WS-Trust protocol would then be used to get SAML assertions issued.



Now is when I must add the exception to the rule. The above discussion was around clinical access to an HIE by an EHR. I think this is the most important HIE access and the one that brings the biggest benefit while being most simple. I think the same can be said about a PHR, although I have less sympathy for a PHR as they are generally less constrained on workflows (exam room) and are also rather newly designed. So a PHR could more easily provide user assertions, still I am not sure why that assertion is specifically useful. But there are other parties that are being connected to the HIE. I think these other parties may be more likely candidates for getting benefit from requiring assertions….