by Mario Szpuszta

Summary: Healthcare is one of the fastest growing markets in the IT industry. It is also one of the most delicate and challenging industries. That is because of the highly heterogeneous technical environment and the various political interests of involved parties—reaching from medical practitioners or pharmacies through hospitals to the ministry of healthcare. For architects, such environments mean we have to build bridges—our systems need to be able to deal with both technical diversity and political interests, especially when it comes to responsibilities and security. The concepts of the Identity Meta-System Vision and its federated approach help us architect and build such systems. In this article, we will discuss those core concepts and drill into parts of proposals we made during a prototyping engagement with the Austrian Medical Association, SVC GmBH.—an IT daughter of the Austrian national insurance responsible for the Austrian electronic healthcare ID-card infrastructure (e-card)—and, finally, the Microsoft Innovation Center Copenhagen.

Contents

Federation and the Identity Meta-System Vision
Austria’s Healthcare Infrastructure and Future Plans
Data Protection of Patient’s Data Is Core
A First Step: E-Card System as a Security Token Service
The Next Step: Federated Security Model
Can We Implement the Model? Mapping Technologies!
Conclusion

Federation and the Identity Meta-System Vision

Summarizing the concepts and the primary goal of the identity meta-system vision, originally invented by Kim Cameron, within one sentence is a challenge, as you can see by taking a look at Kim’s article on MSDN (http://msdn.microsoft.com/en-us/library/ms996456.aspx; a condensed list of the seven laws of identity appears in Fernando Gebara Filho’s article on page 4). One of the primary targets of the identity meta-system vision is the development of concepts, models, and processes to unify and structure the way we deal with digital identities in the future from all perspectives, including parties that issue digital identities, rely on digital identities and—especially important –deal with digital identities (we as end users).

Today such concepts, models, and processes do not really exist as a standardized common layer across all areas. This is the main reason we (end users) are losing control of our information, our digital fingerprints, in the cloud. We are sharing information about ourselves in an unstructured way with many different parties. (How many user profiles do you have?) We specify information for each and every registration with an Internet site and finally we lose control of what we specified where and for which reason. Even more interesting is the reality that we are protecting this information with very weak mechanisms such as simple user name and password combinations that can be easily stolen (see www.antiphishing.org).

By defining standards that include common concepts, models, and processes with clear roles when dealing with digital identities, the identity meta-system vision tries to solve the aforementioned issues. These concepts target the missing “standardized Identity Layer” in typical layered models such as OSI. Today, these include standards for things such as communication or address resolution; they do not talk about identities. Figure 1 illustrates one model that has evolved within the identity meta-system. This model emphasizes the clear separation of responsibilities for different parties as well as the communication paths between them.

Figure 1. A model for clear separation of roles when dealing with digital identities

The model differentiates between identity providers, relying parties, and subjects. An identity provider (IP) essentially is responsible for managing information about us. Typically, we trust identity providers and therefore let them store our personal information. Identity providers also validate identities and verify the correctness of an individual’s information. Technically, an identity provider is a Web service called a “Security Token Service (STS),” which implements certain interfaces. Then, we have relying parties (RP), implemented as applications or services. Relying parties typically have some offerings that they make available to subjects if those subjects can prove that they fulfill certain requirements. These requirements are statements about us, called “claims”. These statements associate end users with properties, permissions, or anything similar. For that, the relying party trusts an identity provider who can verify the correctness of these statements. A relying party authorizes based on statements (claims) verified by an identity provider. This mechanism is typically called claims-based security. Finally, there is the subject, which represents the individuals in the model. Each individual needs to verify statements about them when accessing services of a relying party. If a relying party requests a verification, the subject is in control of which identity provider it uses for providing the required, verified list of statements. With that selection, the subject also decides which information is forwarded to the relying party. Essentially, a subject selects an identity with a so-called identity selector. The identity selector and its underlying standards provide the “common, unified user experience.” Identity selectors are outside the scope of this article. We essentially rely on the role-separation as well as the protocols defined in the model you’ve seen in Figure 1.

There is one important fact to keep in mind about this model: It neither prescribes any specific type of authentication against the identity provider nor does it prescribe any specific security token type that identity providers need to issue. It just specifies clear separation of responsibilities and defines communication paths based on standardized Web service protocols based on leveraging the WS-* standards, as you will see in the last section of this article. Another important fact is that relying parties are no longer responsible for storing and managing information about the subjects. That is the task of identity providers, with the long-term goal that we as users have just a couple of trusted identity providers that are storing information about us –as is the case in the real world. This is a big difference from today’s digital world, where nearly every Web site creates user profiles and stores all the personal information we have entered for user profiles within other sites as well. In the real world this is much different: Only a few identity providers have information about us and we typically know what information they have. Furthermore, in the real world many identity providers do not store the same information about us again and again. They rely on other identity providers in cases where they require that information. That has a couple of interesting effects: There is no central data storage available that has all our information, which is important from a data protection and privacy perspective, and responsibilities in terms of verifying statements about subjects can be delegated between a set of identity providers. And that brings me to the most important aspect of the model in Figure 1 for our healthcare discussion: The flexibility of this model by its nature, due to the fact that the “authentication” against the identity provider is not prescribed in any way, allows us to do what we do in the real world: build trust chains and delegate responsibilities between identity providers. What does this mean? Well, authentication against identity providers can happen either via classic authentication mechanisms such as smart cards, Kerberos (bound to user name, password—yes, that’s still possible), certificates or—and this is the interesting part—through a token issued by another identity provider. Every identity provider can be a relying party of another identity provider, as well. This helps us build federated systems with trust chains and responsibility delegation, which in turn helps us bridge political and technical silos. Figure 2 illustrates this.

Figure 2. Trust-chain between identity providers

As you can see, identity provider 1 requires a token issued by identity provider 2 that proves certain information before identity provider 1 can prove other information required by the relying party. Every identity provider in this scenario can prove a certain set of statements about a subject and therefore can associate permissions with the subject, but none of the IPs can prove all the required information about the subject. The relying party then authorizes based on statements proved by one or both identity providers. Essentially, the identity providers are controlling the authorizations of the relying party by providing (or not providing) certain statements. So in Figure 2 you have two identity providers that can independently (or together) affect the authorization decisions made by the relying party.

With that, we can now discuss how these concepts can be used to effectively structure security in a federated environment– based on the proposals we made in Austria.

Austria’s Healthcare Infrastructure and Future Plans

Austria has an infrastructure in place available for every insured citizen and for a majority of medical practitioners called the e-card system. Originally, the e-card system was intended to support electronic processing for insurance-related tasks such as payments for treatments without the need for additional paperwork. For patients, this means they do not need to worry about any paper-printed health insurance certificates. The e-card system involves smart cards for patients and medical practitioners, some special equipment medical practitioners need to install in their ordinations to be able to use the e-card system, and back-end services for querying information about e-card holders and to start insurance-based back-end processes. For our purposes here, we don’t need to cover the technical details about the e-card system and its deployment.

While the e-card system is seen as a platform for enabling many future e-health services, it is really just one system within a complex, heterogeneous landscape of systems in Austria. First, the availability of the e-cards is limited to patients who have a national insurance. It does not cover people without such an insurance, whether they are just visiting Austria or not. These patients need other means of authentication, such as citizen cards. Second and more important is the issue of political responsibility and ownership. The national insurance is willing to manage some, but not all, information about patients and medical practitioners. For example, they do not store complete healthcare records such as lab reports or analysis reports from hospitals because “that’s not their job”. The responsibility for managing these kinds of information is assigned to hospitals or other types of medical practitioners (such as lab physicians). That means they are also responsible for securing information about patients. In order to support patients with and without e-cards, they need to accept multiple types of authentication. This brings about a situation where a patient’s information (records) is spread around the country between several different parties. The advantage of this is that there is no single point of attack for those who want to compromise the patient’s privacy and security. On the other hand, wouldn’t it be great if a medical practitioner or hospital had access to all pertinent information about a patient in order to ensure the best possible medical treatment? Of course it would, and that’s why the Austrian Ministry of Healthcare started a working group to design a system for electronic healthcare record management. This system should give medical practitioners, hospitals, pharmacies, and patients access to all necessary medical information. Access should be possible anywhere in the country whenever needed, but only if the patient agrees. A centralized solution is not an option for Austria due to its very strong data protection law that protects the patient’s security and privacy in multiple ways. Therefore, storing information in a distributed fashion across several systems managed by different parties is a core requirement for an electronic healthcare record system. And that is one of the main reasons we have taken a federated approach into account when we designed our prototype. Furthermore, the architecture needs to support other types of authentication in addition to the e-card. The e-card system is a widely deployed and accepted standard and it will play a core role in Austria’s future e-health developments. Therefore, we’ve taken the e-card as a starting point and worked on proposals for extending its service interfaces to support federated identity scenarios.

Data Protection of Patient’s Data Is Core

One of the major debates within all the electronic health-care records discussions revolves around the patient’s security and privacy. Austria has one of the strongest data protection laws in the world and acts as an example across the European Union. Short and simplified: The data protection law states that access to ANY information about an individual must be approved by that individual each and every time. According to the Austrian Medical Association, there must be a combination of an organizational and technical process in place to allow the following (while health service provider can be any party with healthcare offerings such as medical practitioners, pharmacies, hospitals, etc.):

(1)   Patients must have the opportunity during every visit to a health service provider (e.g., doctor) to give their explicit consent for access to their personal data (health record). If patients do not give their consent, their data may not be accessed.

(2)   Information about a patient in e-health systems may only be made available to other health service providers for other treatments with the patient’s explicit, additional consent (beyond the general consent described in item 1 in this list) given in a confidential discussion with the health service provider (e.g., doctor).

Although some organizational details are still being discussed between the different political parties, they all agree that a process such as the one outlined in this section must be in place. This requirement definitely influenced the way we designed our prototype.

A First Step: E-Card System as a Security Token Service

Based on the concepts of the identity meta-system vision, the versatile authorization decisions, and the need for a federated security architecture for e-health systems in Austria, we came up with the idea of extending the e-card system to a security token service. As such, the e-card system issues tickets based on the well-established e-card authentication process. These tickets include claims, which are essentially statements about the patient and/or the medical practitioner in a specific situation. These tickets, or the claims in the tickets, allow e-health systems (such as an electronic prescription system) to make authorization decisions. The tickets need to be digitally signed by the e-card system so that the relying e-health systems can trust the tickets and accept them as verification of specific information about patients, medical practitioners, and the current situation they are acting in. Figure 3 illustrates this simple but powerful concept.

Figure 3. The e-card system as a Security Token Service (STS)

The really nice thing about this solution is the fact that we are splitting the responsibilities—as the identity meta-system vision proposes with its models as well. The e-health service is no longer responsible for authenticating the request. It delegates this complex task to a service originally built for authenticating patients and medical practitioners—the e-card system. That means every e-health service just needs to tell its client counterparts which statements about the patient, doctor, and their current situation need to be verified and which identity provider is able to verify these statements. In our prototype, the identity provider is the e-card system, which then performs this complex task if the e-card authentication succeeds. But the architecture also gives the e-health system the ability to accept tickets from other identity providers that support other types of authentication such as citizen cards (e.g. from foreign countries). It even gives the e-health service the ability to accept tickets from identity providers, which verify additional information about a patient compared to that verified by the e-card system. In such a scenario, we would have a trust chain between another identity provider and the e-card system as an identity provider. Furthermore, the authorization within the e-health service itself is very simple: It just queries and analyzes claims stored in the ticket created and signed by the e-card system and forwarded through the software running at the doctor’s ordination.

Now let’s take the data protection requirements as an example of how claims can simplify the implementation of relying parties. Referring back to the previous section about data protection, it could be implemented with the claims-based architecture and the e-card system as a security token service as follows (simplified scenario):

·         The patient goes to a medical practitioner and uses the e-card for authentication by pushing the e-card into a card-reader. During the process of authentication, the patient gets the chance to formally agree to give the doctor access to the electronic healthcare record.

·         Depending on whether or not the patient agrees, the e-card system issues a different ticket. If the patient agrees, the ticket could contain a claim signed by the e-card system that states the doctor (its software) will have read-only access to the patient’s electronic healthcare record for the validity-period of the ticket. In its simplest form, this claim could be a Boolean flag. As it is signed by the e-card system and issued during the authentication process, other e-health services can trust that claim within the signed ticket and grant access to specific parts of their services and information.

·         Next, the patient has a private discussion with the doctor. During that discussion, the doctor’s software can use the previously issued ticket.

·         At the end of the discussion, the doctor creates a diagnostic report that would be useful to other doctors during the patient’s medical treatment. According to our data protection requirements outlined in the previous section, the patient needs to have the opportunity to give an additional, explicit agreement for this step by pushing his e-card a second time and running through an additional authentication process. During that authentication process, the e-card system requires that the e-card be pushed, as well as the previously issued ticket for issuing another ticket that includes a claim for verifying that the patient gave an additional requirement.

·         This new ticket is then used by the doctor’s software to go to an e-health service that allows sharing diagnostic reports with other medical practitioners. This e-health service will share a report only if it gets a ticket containing the claim that verifies that the patient authenticated a second time. The mechanisms for implementing such a service are exactly the same as any other– the service just evaluates one additional claim in a ticket issued by the e-card system. The e-health service can trust this ticket and the claim because it is issued by the trusted e-card system and the trusted e-card system in turn issues the ticket only based on a previously issued ticket stating the first-time logon.

With that process and architecture in place, our architectural proposal would allow a very simple implementation of the two-phase agreement according to the data protection law. And furthermore, this complex and critical requirement would then be implemented in one single place and not again and again for every service, as the e-card system can do the patient-agreement verification for us as an identity provider. This demonstrates the power of claims-based security and how it simplifies the way we deal with rather complex requirements. My first thought was: “It can’t be that simple.” But when you think about how things work in the real world, we have to admit that the real world is nearly as simple. So often authorization decisions are made based on simple statements on a ID card or a conference badge (e.g. people wearing the conference badges with a red band are speakers and may walk into the speaker lounge, others may not).

Extending the e-card system to a security token service was just the first step. It turned out that the e-card system is able to proof a large set of information about patients, doctors, etc.—but not all information that might be necessary for any future e-health service. Also, the e-card system and its owners do not want to own all information for political reasons, which brought us to the next idea of extending the model to a federated security system based on the standards proposed by the identity meta-system.

The Next Step: Federated Security Model

The reasoning behind creating a federated security model was the fact that the e-card system will not be able to deliver all claims in tickets, which might be necessary for all the different e-health services in the future. Also, for political reasons, the owners of the e-card system don’t want to provide all possible types of claims to drive (!!) authorization decisions. According to them, other parties will have the necessary know-how and political position to manage claims requiring more specific authorization decisions. Therefore, the idea was that if an e-health system requires additional information (claims) in order to carry out an authorization, and if this information cannot be made available by the e-card system, it should be possible to introduce additional security token services capable of issuing tickets for access to these particular e-health services (or a set of particular e-health services). Of course, these systems must have a trust-relationship with the e-card system and will issue tickets based on a ticket that has already been issued by the e-card system—if they rely on e-card authentication.

Let’s take a possible, typical scenario: A diagnostic report delivery system that, in order to be able to limit access to diagnostic reports, needs to make authorization decisions based on specifics defined by laboratories, laboratory specialists, hospitals, and doctors. These specifics are potentially not known by the e-card system and therefore the necessary claims for making an authorization possible are managed by the aforementioned parties (laboratories, doctors, etc.). For issuing such claims, an additional security token service is necessary. Figure 4 illustrates that scenario with an e-health service that requires its own security token service.

Figure 4. Trust chain between the e-card system and an STS dedicated to specific e-health services

This architecture allows flexible future extensions of the security infrastructure in the system by adding new security token services as new flavors of authorization that require additional types of claims arise without losing or affecting existing investments. The model also allows splitting up “authorization responsibilities” for several reasons ranging from political, technical, up to know-how. Finally, the model also allows for the consolidation of security token services if the landscape changes, and simplification is possible for any reason without really affecting the implementation of the different e-health services. For the e-health services, just the identity provider changes, with some extensions or consolidations within the overall system. As long as the claim-types remain available, you only need to configure another STS for the e-health service and everything remains fine. Figure 5 illustrates this situation.

Figure 5. Future extensibility, flexibility, and agility due to federation

As you can see in iteration 3 of Figure 5, it is possible to include further authentication mechanisms and factors in the future while still reusing existing e-health services without affecting their implementations—as long as the claim-types remain the same. This is exactly the flexibility and agility we need for complex and heterogeneous environments such as the health-care industry. This is also why standardization efforts such as IHE are moving in this direction (while IHE leaves the used standards and protocols open and stays on an even more conceptual level).

Can We Implement the Model? Mapping Technologies!

An architectural model is worth nothing if we cannot implement it. Therefore, the next step is to assess how far along the technologies are and whether it is practical to implement a system as previously outlined. First, we need to define the standards for implementing the federated security model as proposed in the identity meta-system vision. Figure 6 highlights the most important standards:

Figure 6. Standards in the identity meta-system vision

All these standards are part of the WS-* stack, which is standardized by OASIS on top of the existing W3C standards for Web services. But having standards does not necessarily mean we can easily implement the systems. So what about the support in development frameworks and runtimes? Generally speaking, the world of the identity meta-system is much more real and the best proof is the Catalyst Europe conference held last winter (see http://www.identityblog.com/?p=889). At this conference, several technology vendors (commercial and open source) were invited to test interoperability of their relying party, identity provider, and identity selector/subject implementations, and the results were very promising.

Interoperability based on the standards shown in Figure 6 works between a variety of platforms including Microsoft .NET, Java, PHP, and even Ruby. At Catalyst Europe, vendors verified interoperability between several platforms including Eclipse Higgins, xmldap.org, Bandit (Novell), Verisign PIP, and the Microsoft .NET Framework. The .NET Framework has supported the necessary protocols since version 3.0 with the Windows Communication Foundation (WCF). Digital identity selectors are supported through Windows Cardspace, also part of the .NET Framework 3.0. The protocol binding you have to look for in WCF is the wsFederationHttpBinding (for more information take a look at the following article on MSDN: http://msdn.microsoft.com/en-us/library/aa395215.aspx).

Conclusion

Health care as a politically and technically complex, heterogeneous environment is definitely one of the places where the concepts and ideas of the identity meta-system vision are at home. We discussed the most important concepts of the identity meta-system that help you build services in such a complex environment. These concepts include a clear separation of roles and responsibilities. These are divided into identity providers, relying parties, and subjects. The meta-system also defines the communication paths and protocols based on WS-* Web services standards. You can apply these concepts by taking a look at a prototype we’ve built in Austria together with the Austrian Medical Association, the SVC GmbH. (an IT daughter of the national insurance), and the Microsoft Innovation Center Copenhagen. Clearly defined roles and responsibilities help architects build loosely coupled systems where different parties with different interests are involved by decoupling authentication and assignment of permissions through claims from the actual authorization code in the business services—all based on open WS-* standards. These are the types of architectures that help us build bridges — whether they are technical or political!

About the author

Mario Szpuszta works as an architect in the Developer and Platform Group of Microsoft Austria and supports software architects of enterprise accounts and top 10 Web site accounts in Austria. Mario always focused on working with Microsoft technologies and started working with the .NET Framework very early. In the past years, he focused on secure software development, ASP.NET Web development, Web services, as well as integrating Microsoft Office Clients and Servers in custom applications using Microsoft .NET, Office Open XML File Formats, and Web services. Mario coauthored “Advanced .NET Remoting 2nd Edition” with Ingo Rammer and participated in writing “Pro ASP.NET 2.0 in C#” as well as “Pro ASP.NT 3.5 in C#” with Matthew MacDonald.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.