by Mario Szpuszta

Summary: Healthcare is one of the fastest growing marketsin the IT industry. It is also one of the most delicate and challengingindustries. That is because of the highly heterogeneous technical environmentand the various political interests of involved parties—reaching from medicalpractitioners or pharmacies through hospitals to the ministry of healthcare.For architects, such environments mean we have to build bridges—our systemsneed to be able to deal with both technical diversity and political interests,especially when it comes to responsibilities and security. The concepts of theIdentity Meta-System Vision and its federated approach help us architect andbuild such systems. In this article, we will discuss those core concepts anddrill into parts of proposals we made during a prototyping engagement with theAustrian Medical Association, SVC GmBH.—an IT daughter of the Austrian nationalinsurance responsible for the Austrian electronic healthcare ID-cardinfrastructure (e-card)—and, finally, the Microsoft Innovation CenterCopenhagen.

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 identitymeta-system vision, originally invented by Kim Cameron, within one sentence isa 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 GebaraFilho’s article on page 4). One of the primary targets of the identitymeta-system vision is the development of concepts, models, and processes tounify and structure the way we deal with digital identities in the future fromall perspectives, including parties that issue digital identities, rely ondigital identities and—especially important –deal with digital identities (weas end users).

Today such concepts, models, and processes do not really exist asa standardized common layer across all areas. This is the main reason we (endusers) are losing control of our information, our digital fingerprints, in thecloud. We are sharing information about ourselves in an unstructured way withmany different parties. (How many user profiles do you have?) We specifyinformation for each and every registration with an Internet site and finallywe lose control of what we specified where and for which reason. Even moreinteresting is the reality that we are protecting this information with veryweak mechanisms such as simple user name and password combinations that can beeasily stolen (see www.antiphishing.org).

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

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

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

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

Figure 2. Trust-chain between identity providers

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

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

Austria’s Healthcare Infrastructure and Future Plans

Austriahas an infrastructure in place available for every insured citizen and for amajority of medical practitioners called the e-card system. Originally, the e-cardsystem was intended to support electronic processing for insurance-relatedtasks such as payments for treatments without the need for additionalpaperwork. For patients, this means they do not need to worry about anypaper-printed health insurance certificates. The e-card system involves smartcards for patients and medical practitioners, some special equipment medicalpractitioners need to install in their ordinations to be able to use the e-cardsystem, and back-end services for querying information about e-card holders andto start insurance-based back-end processes. For our purposes here, we don’tneed 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 manyfuture 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 anational insurance. It does not cover people without such aninsurance, whether they are just visiting Austriaor not. These patients need other means of authentication, such as citizencards. Second and more important is the issue of political responsibility andownership. The national insurance is willing to manage some, but not all,information about patients and medical practitioners. For example, they do notstore complete healthcare records such as lab reports or analysis reports fromhospitals because “that’s not their job”. The responsibility for managing thesekinds of information is assigned to hospitals or other types of medicalpractitioners (such as lab physicians). That means they are also responsiblefor securing information about patients. In order to support patients with andwithout e-cards, they need to accept multiple types of authentication. Thisbrings about a situation where a patient’s information (records) is spreadaround the country between several different parties. The advantage of this isthat there is no single point of attack for those who want to compromise thepatient’s privacy and security. On the other hand, wouldn’t it be great if amedical practitioner or hospital had access to all pertinent information abouta patient in order to ensure the best possible medical treatment? Of course itwould, and that’s why the Austrian Ministry of Healthcare started a workinggroup to design a system for electronic healthcare record management. Thissystem should give medical practitioners, hospitals, pharmacies, and patientsaccess to all necessary medical information. Access should be possible anywherein the country whenever needed, but only if the patient agrees. A centralizedsolution is not an option for Austriadue to its very strong data protection law that protects the patient’s securityand privacy in multiple ways. Therefore, storing information in a distributedfashion across several systems managed by different parties is a corerequirement for an electronic healthcare record system. And that is one of themain reasons we have taken a federated approach into account when we designedour prototype. Furthermore, the architecture needs to support other types ofauthentication in addition to the e-card. The e-card system is a widelydeployed and accepted standard and it will play a core role in Austria’sfuture e-health developments. Therefore, we’ve taken the e-card as a startingpoint and worked on proposals for extending its service interfaces to supportfederated identity scenarios.

Data Protection of Patient’s Data Is Core

One of the major debates within all the electronic health-carerecords discussions revolves around the patient’s security and privacy. Austriahas one of the strongest data protection laws in the world and acts as anexample across the European Union. Short and simplified: The data protectionlaw states that access to ANY information about an individual must be approvedby that individual each and every time. According to the Austrian MedicalAssociation, there must be a combination of an organizational and technicalprocess in place to allow the following (while health service provider can beany party with healthcare offerings such as medical practitioners, pharmacies,hospitals, etc.):

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

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

Although some organizational details are still being discussedbetween the different political parties, they all agree that a process such asthe one outlined in this section must be in place. This requirement definitelyinfluenced 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, theversatile authorization decisions, and the need for afederated security architecture for e-health systems in Austria,we came up with the idea of extending the e-card system to a security tokenservice. As such, the e-card system issues tickets based on thewell-established e-card authentication process. These tickets include claims,which are essentially statements about the patient and/or the medicalpractitioner in a specific situation. These tickets, or the claims in thetickets, allow e-health systems (such as an electronic prescription system) tomake authorization decisions. The tickets need to be digitally signed by thee-card system so that the relying e-health systems can trust the tickets andaccept them as verification of specific information about patients, medicalpractitioners, and the current situation they are acting in. Figure 3illustrates 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 aresplitting the responsibilities—as the identity meta-system vision proposes withits models as well. The e-health service is no longer responsible forauthenticating the request. It delegates this complex task to a serviceoriginally built for authenticating patients and medical practitioners—thee-card system. That means every e-health service just needs to tell its clientcounterparts which statements about the patient, doctor, and their currentsituation need to be verified and which identity provider is able to verifythese 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 accepttickets from other identity providers that support other types ofauthentication such as citizen cards (e.g. from foreign countries). It evengives the e-health service the ability to accept tickets from identityproviders, which verify additional information about a patient compared to thatverified by the e-card system. In such a scenario, we would have a trust chainbetween another identity provider and the e-card system as an identityprovider. Furthermore, the authorization within the e-health service itself isvery simple: It just queries and analyzes claims stored in the ticket createdand signed by the e-card system and forwarded through the software running atthe doctor’s ordination.

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

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

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

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

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

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

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

Extending the e-card system to a security token service was justthe first step. It turned out that the e-card system is able to proof a largeset of information about patients, doctors, etc.—but not all information thatmight be necessary for any future e-health service. Also, the e-card system andits owners do not want to own all information for political reasons, whichbrought us to the next idea of extending the model to a federated securitysystem 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 thefact 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 toprovide all possible types of claims to drive (!!) authorization decisions. Accordingto them, other parties will have the necessary know-how and political positionto 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 cannotbe made available by the e-card system, it should be possible to introduceadditional security token services capable of issuing tickets for access tothese 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 systemand will issue tickets based on a ticket that has already been issued by thee-card system—if they rely on e-card authentication.

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

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

This architecture allows flexible future extensions of thesecurity infrastructure in the system by adding new security token services asnew flavors of authorization that require additional types of claims arisewithout losing or affecting existing investments. The model also allowssplitting up “authorization responsibilities” for several reasons ranging frompolitical, technical, up to know-how. Finally, the model also allows for theconsolidation of security token services if the landscape changes,and simplification is possible for any reason without really affecting theimplementation of the different e-health services. For the e-health services,just the identity provider changes, with some extensions or consolidationswithin the overall system. As long as the claim-types remain available, youonly need to configure another STS for the e-health service and everythingremains fine. Figure 5 illustrates this situation.

Figure 5. Future extensibility, flexibility, and agility dueto federation

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

Can We Implement the Model? Mapping Technologies!

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

Figure 6. Standards in the identity meta-system vision

All these standards are part of the WS-* stack, which isstandardized by OASIS on top of the existing W3C standards for Web services.But having standards does not necessarily mean we can easily implement thesystems. So what about the support in development frameworks and runtimes?Generally speaking, the world of the identity meta-system is much more real andthe 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 verypromising.

Interoperability based on the standards shown in Figure 6 worksbetween a variety of platforms including Microsoft .NET, Java, PHP, and evenRuby. At Catalyst Europe, vendors verified interoperability between severalplatforms including Eclipse Higgins, xmldap.org, Bandit (Novell), Verisign PIP,and the Microsoft .NET Framework. The .NET Framework has supported thenecessary protocols since version 3.0 with the Windows Communication Foundation(WCF). Digital identity selectors are supported through Windows Cardspace, alsopart of the .NET Framework 3.0. The protocol binding you have to look for inWCF is the wsFederationHttpBinding (for more information take a look at thefollowing 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 conceptsand ideas of the identity meta-system vision are at home. We discussed the mostimportant concepts of the identity meta-system that help you build services insuch a complex environment. These concepts include a clear separation of rolesand responsibilities. These are divided into identity providers, relyingparties, and subjects. The meta-system also defines the communication paths andprotocols based on WS-* Web services standards. You can apply these concepts bytaking a look at a prototype we’ve built in Austria together with the AustrianMedical Association, the SVC GmbH. (an IT daughter of the national insurance),and the Microsoft Innovation Center Copenhagen. Clearly defined roles andresponsibilities help architects build loosely coupled systems where differentparties with different interests are involved by decoupling authentication andassignment of permissions through claims from the actual authorization code inthe business services—all based on open WS-* standards. These are the types ofarchitectures that help us build bridges — whether they are technical orpolitical!

About the author

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

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