Identity Federation in Federated Trust Healthcare

Network Abstract

Today’s internet is composed of numerous heterogeneous network systems. Each system has its own authentication,

authorization and identity management services. A typical business transaction involves a number of participating domains

which incurs the overhead of repeated logins and managing and exchanging heterogeneous identity information. Since each

system has its own requirements for establishing identity, the typical user accumulates multiple identities across these multiple

domains. Federation between different trust domains is a realistic approach that can be taken to solve this identity crisis and

facilitate information sharing between these heterogeneous domains. Now various standards and implementations have been

proposed by different organization to leverage this problem. In this paper we review and compare each of them and propose

our way as an extension to WS-Federation that addresses federated identity issues in Healthcare networks. Our solution

provides a way to dynamically map a user’s identities in different domains to form one virtual universal identity. We introduce

a Token Exchange Service to facilitate the exchange of security information, realize inter-domain user mappings and hide each

domain’s internal details. We utilize a Trust Authority to publish domain information and manage trust relationships among

domains.

1. Introduction Every one has an “identity” since they are born. Started from birth certificate, it comes as social security number, driver’s

license, passport, company nametag, payroll account, credit cards, etc. Now with the ubiquitous use of computer and Internet,

more and more services have been brought online which means a user is getting more and more “identities” from the online

services which he/she uses. Email account, company intranet account, library account, numerous credit card accounts, medical

insurance accounts, motor vehicle insurance account, various online store accounts and etc., not to mention numerous accounts

you are forced to register on some website when you just want to read a particular news article. The number of accounts has

exceeded the limit that a user can easily manage. People forget account name and password all the time and re-register again

and again. Even for people has superb memory and good organization, re-login to each site he/she visits is still taking too

much precious time which no one want to waste.

The structure of Internet which is composed of isolated network “islands” disconnected by security systems has posed serious

problem not only to individuals who use these online services but also those online service provider themselves. Now a typical

company/organization’s operation usually involves a number of other entities, such as a manufacturing company coordinating

with companies in its supply chain to streamline the manufacturing process; healthcare institution communicating with various

clinical departments, billing organizations, pharmacies and insurance companies to fulfill a normal transaction. To gain a

competitive edge, now companies are integrating each other’s services to provide streamlined customer experience, like when

you saw an interesting product on a news website, click through a link and you will be brought a online store that sells the

product; booking plane ticket on a website will also gives you the choices to make hotel reservations and reserve rental cars at

your destination. When companies access other companies’ services/resources on behalf of a client, it also faces the problem

of identity. The user’s identity in one organization is almost always different from which in the others or even not recognized

or trusted. Exchanging information inside an enterprise (trust domain) is straight forward while cross-domain transactions

need trust relationship establishment, security information exchange, stronger authentication and more complex authorization.

These security processes introduce a large amount of overhead. While security is indispensable, the idea of “Federation” has

been proposed to increase efficiency and reduce interference with the normal workflow.

Federation [1][2] is a set of system components (trust domains) participating in a confederation to coordinate sharing and

exchange of information while each component retain its autonomy. Each component (trust domain) decides what information

to be shared, which other components (domains) may participate in the sharing and in which ways. They also retain the

freedom to change its sharing interface.

Establishing a federation among trust domains minimizes security overhead through sharing resources and information.

Federated Identity is the key to establishing a federation. It provides someone with an identity across companies, domains and

applications, which is the key to provide secure information sharing infrastructure in a federation. After an identity is

established, it can be used with other applications, web sites/services, making it possible to create complex transactions and

applications without having to repetitively log into separate applications or services.

Federated Identity solves the identity crisis and streamlines the identity information flow between domain boundaries. But

there are problems: firstly, who should provide the federated identity --- trusted third party or each domain itself; secondly,

should we provide a single universal identity or preserve user’s identity in each domain and linking these identities together;

thirdly, how to verify and exchange identity related information without compromise user’s privacy. Also trust establishment

between different domains remains an open question. People are still using off-the-network ways to establishing a trust

relationship between domains.

The Burton Group has an analyst definition of identity federation, “The agreements, standards, and technologies that make

identity and entitlements portable across autonomous domains.” In this paper we are going to review existing federation

standards and technologies, compare and contrast their ways of providing federated identity. Then propose our security token

exchange and validation architecture as an extension to WS-Federation WS-Trust which provides federated identity; hides

security related interface, provides directory service to dynamically discovery interfaces, and facilitates trust establishment

and negotiation. Our solution minimizes the assumptions and required changes of existing systems to establish federation. The

architecture is flexible to accommodate future changes, reliable to have each domain remain normal functioning when

federation facilities are down, scalable to have each domain manage its own interfaces and system implementation details that

changes in a specific domain won’t affect other domains.

This paper is organized as follows: section 2 discusses the related works that have been done in the area of federated identity;

section 3 gives the overall design of our architecture; section 4 shows our experiment medical portal, pharmacy portal and a

third party news domain which implements our federation framework; section 5 discusses the possible future work and

concludes this paper.

2. Identity Federation Approaches Identity federation is an emerging technology that has attracted enormous attention from both industry and academia. There

are a number of standard organizations, companies and universities participating in forming standards and providing

federation solutions.

2.1 OASIS and SAML The Organization for the Advancement of Structured Information Standards (OASIS) is a large not-for-profit, global

consortium founded in 1993 that drives the development, convergence and adoption of e-Business standard. The Security

Assertions Mark-up Language (SAML) is an XML-based specification developed by OASIS that has been widely adopted.

SAML defines a common XML framework for exchanging authentication, authorization and attribute assertions between

entities. This open standard is one of the foundations of various other federation standards including Liberty Alliance ID-FF,

ID-WSF, and WS-Federation. SAML enables server applications in different enterprises to exchange assertions, issuing

assertions to a subject (person or computer), consuming assertions submitted by a subject or other server applications. Using

the open standard way of exchanging security information makes it possible to establish Federated Identity among

heterogeneous systems.

2.2 Microsoft, IBM and WS-Roadmap In April 2002, Microsoft and IBM jointly published a whitepaper outlining a roadmap for developing a set of Web service

security specifications which includes WS-Security, WS-Policy, WS-Trust, WS-Federation, WS-Privacy, WS-Authorization,

and WS-SecureConversation. WS-Security is the foundation of WS-Roadmap which offers a mechanism for attaching security

tokens and soap headers to messages, including tokens related to identity, message encryption, digital signature and etc.

WS-Policy describes the security capabilities and constrains on business endpoints and intermediaries. WS-Authorization

defines how access polices are defined and managed for web services. WS-Privacy describes how each of the web services and

requesters state their privacy preferences and privacy practices. WS-SecureConversation describes how web services and

requesters can authenticate each other and establishing security contexts, including establishing session keys, derived keys and

per-message keys.

The most relevant web services specification to federated identity are WS-Trust and WS-Federation. WS-Trust describes

various trust models which enables web services in different domains to interoperate. In addition, it specifies the security token

request and response schema. WS-Federation describes how to manage and broke trust relationship in a heterogeneous

environment including support for federated identities. Although these specifications look promising, they are in their very

early stage and many details are still missing.

2.3 Liberty Alliance The Liberty Alliance is a consortium of approximately 170 companies that develops federated identity management

specifications which include: Identity Federation Framework (ID-FF), Identity Web Services Framework (ID-WSF), Identity

Services Interface Specifications (ID-SIS). ID-FF enables identity federation and management and is designed to work in

various heterogeneous platforms and all kinds of devices. It specifies cross site account linking, simplified sign-on, anonymity

and simple session management. It also introduces the idea “circle of trust” which is basically a set of entities that have

business agreements and share the linked identities defined in ID-FF. ID-WSF is a layer that utilizes ID-FF to define a

framework for creating, discovering and consuming identity services. The main features of ID-WSF include permission based

attribute sharing, identity service discovery and SOAP binding of these protocols. ID-WSF enables entities to provide identity

based service which is personalized and more valuable to customers. ID-SIS is a set of specifications for interoperable web

services that are built upon ID-WSF. These specifications serves as web service templates that help companies to instantiate

ID-WSF and help ease interoperability issues. The planned ID-SIS service specifications include: personal profile identity

service, contact book, calendar, geo-location, presence and alerts. The liberty standards are fairly comprehensive and ever

evolving. But since they are industrial based standards, user’s privacy issues are not treated at the top priority in place of

implementation convenience. Also because Microsoft and IBM are not part of this organization, when WS-Trust and

WS-Federation are integrated with the next version of Windows Longhorn, the future of Liberty standards are still unclear.

2.4 .NET Passport .NET Passport initiative is a service provided by Microsoft which has a central identity provider (www.passport.com, IDP)

that every participating site trusts. Authentication requests at participating sites are all redirected to this central server. The IDP

collects user credential and issues a security token with universal identity to the participating site. Each site can verify the

security token and the universal identity, so federation occurs when cross organization request comes with the central IDP

security token. This is the simplest and most straightforward way to solve the federation problem. Although it works pretty

well, there are some fundamental limitations: 1. single centralized authentication server. This introduces the basic single point

failure problem that should be avoided by any dependable and secure system. And this single central authentication server is

not scalable. 2. Authentication is out of each domain’s control. Since the authentication server is operated by a 3rd party and the

sites are generally redirecting users there for authentication and accepts security token issued. Each domain has no control on

how user could be authenticated (user name and password, finger print, iris scan etc.), what information should be collected by

the authentication server for user account (name, address, phone number, email, etc.) 3. Trust relationship is a star structure.

The only information sharing is between the central authentication server and one web site. There is no security information

shared between sites.

2.5 Shibboleth Shibboleth is a project of Internet2/MACE that trying to produce an open source implementation that supports

inter-organizational sharing of web resources under access control. It emphasizes on access control techniques and also

addresses federated administration issues. The solution Shibboleth intended to provide is a secure and privacy-preserving way

of exchange user property information. The key concepts behind it are: federated administration which establishes trust

relations between university campuses and assigns a trust level to each other, each campus provide attribute assertions for the

users coming from them, access control based on these attributes assertions made by each campus, active management of

privacy provide a way for the use to configure which attribute information he/she would like to release to other campuses,

SAML standards based assertion exchange using open source java/C++ SAML implementation OpenSAML, a framework for

multiple, scalable trust and policy sets (clubs) which is similar to the “trust circle” idea in Liberty Alliance specifications, a

standard and flexible attribute vocabulary which make the attribute assertions understandable to each entity. It does not

provide Federated Identity management capability since it does not require service provide to have identity management or use

requester’s identity provided by its source identity provider. There is no need for federated identity since access control

decisions are made based on requester’s attributes. Also Shibboleth is more confined within the higher education community.

3. System Design

3.1 Overview and Key Ideas Since federating user’s identity across domain requires more confidence in the identity provided by the source domain, we

propose an identity establishing process with strong authentication and an identity management system with the ability to

evaluate the trust worthiness of a provided identity based on the authentication method used.

Before identity federation, domains participating in the federation have to establish trust relationship between each other. The

domains trusted and the degrees to which domains are trusted are defined at this trust establishing phase. What is the best way

to build and evaluate trust is still an open problem. We propose a semi automatic mechanism to establishing trust between

domains as a practical and efficient solution.

Identity federation in an abstract sense is providing a universal identity that could be recognized and used by all participating

domains without much effort. We propose a way to provide this benefit by mapping a user’s identities in heterogeneous

domains together to form a virtual universal identity. These mappings are done automatically at runtime so it is completely

transparent to the user and application. We will explain in detail how and where these mappings are done.

To provide identity mapping we must provide a way for the heterogeneous domains to let them communicate with each other

and exchange security information. We introduced a Token Exchange Service to facilitate this process by serving as a

directory and broker. TES provide a standard web service interface and using standard security information format to

exchange data. The way TES works – which is interactively exchanging user information at run time on an on-demand basis, is

a good way to protected user privacy.

Privacy protection is a serious problem when providing identity federation and inter-domain information exchange. There

must be ways to minimize user information leakage. We employed pseudonym as an option when maintaining user mappings.

These mappings can be based on real user identity or some random pseudonym to maintain user’s anonymity and avoid

identity tracking. Attribute exchange as we mentioned earlier is an on-demand process. To further protect user privacy we

could employ runtime privacy policy evaluation algorithm during this process.

To provide identity federation to web browsers, we have designed an inter-domain request interception and forwarding

mechanism to provide web single sign-on. Browser is being redirected between source, TES and target domains during the

process to exchange security information/token.

Our solution is based on the proposed architecture of WS-Trust and WS-Federation. We extended the Security Token Service

(STS) with 2 identity web services and 2 active pages to facilitate security information exchange and web single sing on. The

STS is also extended to be able to maintain user identity mapping and control incoming/outgoing inter-domain request. User

identities are automatically exchanged when the transaction traverses each domain by the STS at each domain with the help of

TES. This architecture does not have a central authentication server/IDP or universal identity. It preserves each domain’s own

authentication and authorization system which gives local authorities more control on what authentication/authorization

polices fits the local scenario. Also there is no single point failure since authentication is distributed. When the TES is down

each individual domain is still able to run with the cached federation information. Unlike other federation scheme, user’s

identity and related attributes information are not pushed all together to every federated domain. Every single user’s attributes

must be explicitly requested and each request will be evaluated against the user’s privacy rules to minimize user information

exposure. Attribute assertions of a user are exchanged to establish trust and create local token. User identity mapping is done at

each site locally. Trust relationship establishment polices are also defined by each domain itself with local polices files which

gives each domain more control on who to trust and to what degree. This makes it more likely to work in a real world

environment.

3.2 Workflow In a typical network system, a user/program (principal) first establishes its identity before requesting any resources that are

under access control. In our system the principal contacts the local authentication server, provides required information

(usually user name password, finger print, X509 certificate, etc), then the authentication server verifies these credentials. If the

provided credentials are valid, the authentication server returns a valid authentication token that contains the identity assertions.

The information of the principal’s identity contained in this token is verifiable (the token contains valid authentication server

signature which is recognized by all resources in the local trust domain. Whenever the principal request some resource in the

local trust domain, the authorization enforcement point will invoke the authorization engine with the resource request and user

identity token. Based on the identity, current context information and the local authorization policy, the authorization engine

will make a decision to grant or deny this request.

When the principal makes a inter-domain request, the service provider at the remote domain has to enforce security policies in

its own trust domain. The authorization process at the remote domain is very similar as what happens at the local trust domain.

To evaluate the authorization policy, the principal’s identity and attributes must be provided. At this point, identity federation

comes in.

As in WS-Federation, we classify identity federation into two profiles: Active Federation which refers to federation with

programs/applications, e.g. web services. These principals have more freedom. They can contact other services actively and

control the whole dataflow; Passive Federation refers to web browsers which has limited control of dataflow and can only

passively been redirected to contact other services.

For Active Federation: before the program request the resource at the remote trust domain, it contacts the TES for the URL of

remote trust domain’s identity federation interface (STS). It then sends a request to remote STS for a security token at remote

trust domain. To establish the trust (create a remote security token), the remote STS will reply with a challenge, the local

domain will answer the challenge. These challenge and response will be in extended SAML messages. Usually the remote STS

will ask for the requester’s identity in the local domain and other attributes that are needed for remote security token creation,

such as authentication methods used, expiration time, roles the requester plays in the local domain, etc. These challenge and

response messages will all be endorsed by each domain’s private key signature (or using WS-SecureConversation). The

application is aware and actively involved in the identity federation process.

In WS-Federation specification, the Passive Federation profile shows that the remote server must have “user interaction” to

determine the domain where the requesting user comes from. We consider this is not convenient and sometimes unrealistic

(the user may not be aware of the domain identification). We introduce a way to use local STS to intercept the remote request,

wrapping the request with the local domain identification, principal identity token, and other necessary information, forward

the request to TES, and TES will further forward the request to the remote trust domain’s STS URL based on the directory

information stored in TES. The remote STS will send the challenge back to TES which in turn forwards the request to the local

domain for response. Then the remote domain will create a security token based on the information provided in the response.

The web application may not be aware of the identity federation process. The local STS, TES and remote STS collaboratively

realize identity federation.

The graph below showed the whole process of security token exchange in active and passive federation. There are two

domains – the hospital trust domain and the pharmacy trust domain, and the Token Exchange Server (TES) involved. The

process of security token exchange via TES in passive federation is further described blow.

2. Wrapping Request with Local Token

5. Forward Attribute Request

3. Forwarding R

equest

4 Request and A

cquire Attributes to

Create Local Token

Pol

icy

Pol

icy

Pol

icy

Pol

icy

Policy

Pol

icy

Pol

icy

Pol

icy

Pol

icy

Policy

Pol

icy

Pol

icy

Pol

icy

Pol

icy

Policy

Security

Token

Service

Security

Token

Service

Token

Exchange

Service

Web Portal

Web Service

Web Portal

Request Directly with Policy Caching

Client

Browser

1. Intercepting

Request

2. Exchange Hospital Token for Pharmacy Token

Pharmacy Trust

Domain

Hospital Trust

Domain

3. Request with Pharmacy Token

6. Request with Pharmacy Token

1. Acquire Hospital

Token

PASSIVE FEDERATION

ACTIVE FEDERATION

Figure 1

1. A user in the hospital trust domain initiates a request for some resource in the pharmacy trust domain. The request is

intercepted by the local STS.

2. Local STS examines the request, wraps the request with hospital domain’s local security token and domain URL, then

forwards this request to the TES. The URL of the TES is looked up in a local policy file.

3. TES finds the URL of the pharmacy domain’s local STS (specifically, the outside request accepting service point) and

forwards the original request.

4. The pharmacy domain’s local STS gets the request and extracts the source URL. Then it decides whether to accept this

request according to a local policy file. The policy file is set up during the trust relation establishment phase. If it decides

to accept the hospital domain’s request, the pharmacy domain STS sends a challenge back to TES with the security token

from the request and a list of information (user name, authentication methods, etc) which are required to build a local

security token.

5. TES looks up for hospital domain’s token resolving service which is registered during the trust relation establishment

phase. TES gets the requested information from the service using the security token and forwards the information to

pharmacy’s local STS.

6. Pharmacy’s local STS examines the information and decides whether to a) accept this request and automatically create a

new account for this user b) accept this request and map the user to an existing account c) reject this request. In this

scenario the request is accepted. The local STS dynamically create a pharmacy’s local security token for this request.

7. The user in the hospital trust domain is finally redirected to the requested resource in the pharmacy trust domain. Since

the user has already got an identity security token in pharmacy trust domain, this request is granted.

The TES does not have to be there to finish the whole token exchange process. It can serve as a directory service that helps

each domain to find out where the specific token exchange related services are. Forwarding request back and forth is not

necessary when each domain already knows the specific service URLs. Two domains can communicate with each other

directly using SAML tokens as the standard language. This will dramatically increase the performance of inter-domain token

exchange.

4. Experimental System --- Federated Trust Healthcare Network The key ideas showed in the previous sections are implemented in 3 components in our experimental system. Token exchange

service, security token service and trust authority. In this section we will explain the detail of these components.

4.1 Identity Federation Policies In our system, the identity federation process is controlled by a set of policies files resides on various entities. We will explain

the details of each policy in this section.

4.1.1 Identity Federation Policy at Security Token Service Each local domain has a set of identity federation related policies controlling what information to share, who to trust, and how

to federate user identities? These information are stored in two policy files.

4.1.1.1 TES registration TES is the directory/broker that helps distribute each domain’s identity federation interface information and a trusted third

party endorsing and facilitating automatic trust establishment. Each domain’s local administrator has to explicitly register the

TES in this policy file to indicate this domain trusts information and services provided by this specific TES. “Domain” element

in this file corresponds to a particular TES. The information registered for each TES are: element “Name” as a human readable

string representation of the TES; element “Url” as the URL of the TES; element “WebAcceptingUrl” is the service interface

URL provided by TES to facilitate identity federation in the web environment that realize single sign on between trust domains;

element “TokenResolvingUrl” is another service interface URL that facilitate attribute assertions exchange between two

federated trust domain. See appendix for a detailed example.

4.1.1.2 Trusted domain registration, including User mapping and Trust Level mapping The trusted domain registration policy file is the main control policy file that decides who and how to trust a federated domain.

This also gives information about what information is needed to create a local security token. The “Domain” element

corresponds to a federated trust domain; element “Url” is the base URL of the remote trust domain which also servers as the

unique identifier of this trust domain; element “Allowed” is a Boolean value that indicates whether this domain is trusted or

not; (element “DefaultHandler” is for future use); element “IDMappingSet” controls how user identities are mapped between

this trusted domain and the local domain. This element contains a number of “IDMapping” elements which corresponds to a

particular identity mapping configuration. The “RemoteUserID” and “LocalUserID” contains a user’s identity at these two

domains and creates a mapping between them. Note that the identity can be wildcard/”*” which means all the users from a

particular domain. This section will be dynamically modified by identity federation program to manage identity mappings on

the fly; element “TrustLevelMappingSet” is very similar to “IDMappingSet” which controls how trust levels are mapped

between two trust domains. Trust level is a numerical representation of the trustworthiness of user’s authentication method.

Sub-elements “RemoteTrustLevel” and “LocalTrustLevel” are string representations of trust levels which map to each other.

Sub-element “LocalTTL” is a numerical value of how long the mapped trust level is valid in the newly created local security

token. Note the trust level can also be wildcard/”*” which means any trust level in a particular domain. This makes it very easy

to express policies as regardless of the trust level a user has in remote trust domain assign the trust level of “Password” to the

user’s local identity trust level. The figure below showed a typical trust level mapping between two domains. Trust level

mapping is just an example of attribute mappings between trust domains. There could be other mappings and the extension is

as easy as adding another mapping section in the policy file.

Trust LevelsTrust LevelsTrust LevelsTrust Levels

4444 FingerprintFingerprintFingerprintFingerprint

3333 SignatureSignatureSignatureSignature

2.52.52.52.5 RFRFRFRF----IDIDIDID

2222 eeee----TokenTokenTokenToken

1 1 1 1 ******* PasswordPasswordPasswordPassword

0000 AnonymousAnonymousAnonymousAnonymous???

FingerprintFingerprintFingerprintFingerprint

SignatureSignatureSignatureSignature

RFRFRFRF----IDIDIDID

eeee----TokenTokenTokenToken

PasswordPasswordPasswordPassword

AnonymousAnonymousAnonymousAnonymous

Trust LevelsTrust LevelsTrust LevelsTrust Levels

4444 FingerprintFingerprintFingerprintFingerprint

3333 SignatureSignatureSignatureSignature

2.52.52.52.5 RFRFRFRF----IDIDIDID

2222 eeee----TokenTokenTokenToken

1 1 1 1 ******* PasswordPasswordPasswordPassword

0000 AnonymousAnonymousAnonymousAnonymous??????

FingerprintFingerprintFingerprintFingerprint

SignatureSignatureSignatureSignature

RFRFRFRF----IDIDIDID

eeee----TokenTokenTokenToken

PasswordPasswordPasswordPassword

AnonymousAnonymousAnonymousAnonymous

Figure 2

4.1.2 Domain Registration at Token Exchange Service Each trust domain should also register itself at the TES to initiate the trust relationship between this domain and the TES. Also

each domain should provide the identity federation interface information at registration time to facilitate future token

exchange.

4.1.2.1 Domain Registration Similar to the TES registration at local trust domain, each domain registration at TES contains the human readable string name

of the domain in the “Name” element; the “Url” element as the starting URL of the domain and a unique identifier of the

domain; “WebAcceptingUrl” element contains the URL in the local domain that accepts remote trust domain web requests,

resolves identity and dispatches these requests; “TokenResolvingUrl” element contains the local domains security token

resolving and attribute service which is the main entry point for attribute assertion exchange.

4.1.2.2 Attribute Standard Names (could be replaced with SAML extension) When requesting attribute assertions each domain must know what to ask for and what is asked for. Attribute Standard Names

serves this purpose. There is a similar standard name set used in Shibboleth that defines the standard Object Identifier (OID) –

attribute names. We have adopted and extended this name base to incorporate our new attributes. Also extending this name

base with new attribute names is very easy. This policy file is a simple list of each standard attribute name. Element “Name” is

the unique string identifier of the name and element “Type” is the attribute’s data type. Now the types are the same as defined

in the W3C XML specification. But it is also very easy to extend.

4.2 Token Exchange Service TES provides two interfaces: one for web browser through an active web page and the other for applications through web

services. With these interfaces TES provides request forwarding, attribute resolving and directory lookup services.

4.2.1 Request forwarding One of the services provided by TES is to forward source trust domain’s web request to its destination domain. This web

request comes with the source domain’s identifying information (usually the base URL), the requester’s security token

containing identity information at source domain and the requested resources in the destination domain. The TES is

responsible to look up its domain registration information to find out the destination domain’s corresponding web federation

interface URL and forwards this information to that URL. Request forwarding is not a must have with every inter-domain

request. It is useful when two domains communicate for the first time in a session or don’t have any caching service that can

cache remote domains’ interface information.

4.2.2 Attribute Resolving Attribute resolving service is actually a wrapping service that works very similar to the request forwarding service. When this

web service is invoked by a trust domain to resolve another domain’s security token and asked for some particular attribute

information associated with that token. The TES looks up its domain registration information for the destination domain’s

token resolving service and invokes that service with original request and forwards the returned information to the original

requester. This service can also be bypassed to increase efficiency when previous attribute exchange between two domains has

already stored each domain’s token resolving service information into cache. While in the scenario that a particular domain

does not want its token resolving service to be public accessible (which is a security risk), this service can serve as a firewall

between the actual service and outside world.

4.2.3 Directory lookup The above two features requires TES actively involves in the whole identity federation process. Directory lookup service is

provided for domains that do not want TES involved in every step to increase efficiency. The identity federation interface of

each domain can be queried with a domain’s identity and other domains can use this information to start federation with this

domain.

4.3 Security Token Service Each trust domain has its own security token service that serves as the local authority that issues security token to its users.

This service is introduced in WS-Trust and WS-Federation. Their idea of STS not only issues tokens but also exchanges tokens.

But they do not specify how the trust is established and how the tokens’ could be read and attribute information retrieved. Also

there is no detailed information there for web single sign on support from STS. The extensions to support identity federation in

our scheme includes request forwarding service and token resolving service.

4.3.1 Request Forwarding Request Forwarding is the working horse that accepts out-domain requests from TES or directly from trusted source domain.

This service has responsibilities such as: retrieve source domain’s identifying information, security token and requested

destination resource; evaluate the request against local federation policies and decides whether to accept this request and

initiate identity federation process; if yes, start the local identity creation process by contacting TES/source domain’s token

resolving service with the security token and standard attribute name(s) to request for necessary attribute assertions to create a

local identity; after the source domain evaluated the attribute assertion request against its own federation and privacy policies

it will return the corresponding attributes; local STS uses these attribute assertions to create a local identity based on identity

federation policies; the original request is forwarded to the destination and access control enforcement at the destination will

evaluate access control rules based on the newly created federated identity.

4.3.2 Token Resolving Service Token resolving service is the interface to other trust domain’s STS where attribute assertion exchange occurs. This web

service accepts a local identity security token, an attribute standard name and returns the corresponding attribute assertion.

Since the security token is local, it can read the token and retrieve identity information from it. The TRS will first evaluate the

attribute request against local privacy policy to see whether disclosing this information is allowed, and possibly future

negotiation could happen here. If TRS decides to grant this request, it contacts local attribute service or directory service to get

the required attribute associated with the identity. Also according to privacy polices, TRS can mutate attribute information

right before returning to the requester to further help protect user privacy, such as return a pseudonym instead of real local

identity of a particular user.

4.4 Trust Authority Each domain has its Trust Authority publishing its trust statements. These statements include domain information, Trust Level

definitions and other possible domain properties. Domain administration in one trust domain examines the published trust

statements by other trust domains and decides whether to trust those domains or not. Business relationship and agreements are

also a factor. The screenshot below showed the trust administration interface in our experimental system. The local

administrator input the URL of the remote trust domain’s domain information XML file. It retrieves and shows the domain

information alongside with local information. It also retrieves other trust statements pointed from the domain information file,

in this example the trust level definitions are retrieved and showed along side with the trust level definition from local trust

authority. Domain administrator examines and compares these trust statements and creates trust level mappings which

modifies trusted domain registration file on local STS and effectively established trust relationship.

Figure 3

4.5 Portal and Services In this section we are going to show the different aspects of our experimental system that realized with our identity federation

system.

4.5.1 Authentication Service and Trust Levels In this experimental system, we provide various authentication methods which include user name/password, finger print, RFID,

e-Token, signature. Because each authentication method has its own unique properties such as false positive rate, false

negative rate, possibility of counterfeit, possibility of loss and etc. We abstract these properties and propose a high level

concept of trust level. Trust level is a numerical representation of a particular authentication method’s trust worthiness which

is assigned by domain administrator based on the properties of the authentication method. Trust levels are numerical which

makes it comparable and possibly computable (if we find meaningful arithmetic for computing trust level for combined

authentication methods – “multiply” seems a candidate).

4.5.2 Alert Service via Inter-Domain Active Federation Our system support alert which is a short message sent to a user when a particular event happens via a communication channel

chosen by the user himself. The types of alert the system supports are: email, telephone, MSN Messenger Alerts, SMS and etc.

Intra domain alert is when the event generating domain is the same as the domain where the alert’s target user comes from.

Because they are in the same domain, the service which generates the alert is trusted and can access the alert service directly.

Inter domain alert is when the event generating service’s domain is different from the domain where the target user resides.

The event generating service needs to have its own identity and trust from the alert target.

Using Federated Identity service between hospital domain and pharmacy domain, we extended our alert service to provide

inter-domain alerts when pharmacy fills a patient’s prescription. When this event occurs, the pharmacy alert service contacts

pharmacy STS to generate a local identity token for it, then it contacts hospital STS to request a hospital identity token with the

pharmacy identity token. Based on federation policies the hospital STS issues a hospital identity token for the pharmacy

service and then the pharmacy service contacts the alert service in hospital domain with the hospital identity token to issue an

alert.

4.5.3 Cross-Domain Single Sign-On via Passive Federation Single sign-on between two trust domains is realized in our experimental system with identity federation. There is a MSN

(mock) portal which has its own user name/password authentication system and issues simple XML based identity tokens.

After user logon, the personalized MSN page contains a dynamically generated link to our hospital portal. This link will have

the local STS first intercept the out-domain request. The request will make a stop at a request forwarding page at local STS.

This page wraps the request with the MSN local identity token, URLs of the MSN portal and the hospital portal, and then

forwards this request to TES. The receiving page at TES examines the destination of the request and looks up domain

registrations for the out-domain request receiving point in the STS of hospital domain. The request is then forwarded to this

receiving point just found. At hospital domain, the STS look up in local policy files for trust relationship with the requesting

domain. If they have identity federation set up, which is the case in our system, the hospital STS begins identity federation by

asking the TES attribute resolving service for the incoming user’s identity in the MSN domain. TES looks up the domain

registration directory and find the attribute resolving service in MSN domain and then dispatches the attribute request there.

MSN’s attribute resolving service, which is part of the STS, examines the local identity token coming with the attribute request

and evaluates the request against local privacy policy. If the request is granted the MSN attribute service will return the

attribute requested to TES and TES returns to hospital portal. Based on the returned user identity in MSN, the hospital STS

looks up user mappings for MSN domain in local policy files. If a user mapping is found for the incoming user’s identity, the

hospital STS start requesting for additional attributes which are prescribed in federation policy file as necessary to create a

local identity token. These attribute request will be the same as the identity attribute request we have just discussed. If the user

mapping does not exist, which is the case when a user accesses hospital resources for the first time, the hospital STS will show

an identity mapping creation windows that propose the user to map his MSN identity to a local identity. This window shows

the MSN domain and the user’s identity in MSN domain which is retrieved by the attribute request process just discussed, and

a dialog box for the use to input a local identity for the mapping. The local identity is authenticated here for the first time when

creating the mapping to ensure that the user who requests this mapping is really the user who owns this identity. After

authentication both the local identity and the identity mapping are created. Then the hospital STS forwards the request to the

destination resource. Since the request now has the local identity token in its context, the hospital portal recognizes it and

automatically logs him in.

5. Conclusion and Future Work In this paper we proposed an identity federation infrastructure that provides federated identity across autonomous domains.

Identity federation is a good way to alleviate identity crisis brought by numerous identity systems in heterogeneous

applications, networks and domains. It makes identity and related information available across domains which dramatically

reduces the overhead of inter-domain business transaction and provides better end user experience. We have implemented an

experimental healthcare system involves 3 autonomous domains which showed our design is flexible, maintainable and

powerful. User identity mapping and attribute mapping across domains is more flexible and realistic than establishing a central

identity provider. Token exchange service with web service interface is a practical way to exchange security information while

hiding the internal detail of each system. Trust authority is the starting point of providing fully automatic trust establishment.

Our next step would be providing fully automatic trust establishment through trust negotiation based on the trust authority

infrastructure. Improving the attribute exchange process to provide better user privacy protection by evaluating domain

policies at run time and minimize user information exposure while requesting a token exchange. In the future we will also

incorporate SAML and other security standards other than Microsoft and IBM’s WS-X. We will experiment integrating our

system with other federation systems available the test the extensibility and standard interface of our system..

6. Acknowledgement We gratefully acknowledge the multiple discussions and intellectual contributions of the other current members of our

research group (James Hu, James Van Dyke, Andrew Marshall, Brian Garback, Joseph Calandrino, Paul Bui) and the support

of our research sponsor, David Ladd at Microsoft Research.

7. References [1] Heimbigner, D., “Infrastructure for Federated Software Environments,” NIST Presentation, March 1994.

[2] Heimbigner, D., and McLeod, D., “A Federated Architecture for Information Management,” ACM Transaction on office

Information Systems, 3 July 1985.

[3] Putman, J. and Strong, S. A federated virtual enterprise (VE) of partners creating a federated VE of systems in

Proceedings of Computer Software and Applications Conference, 1998. COMPSAC '98

[4] Mezzetti, N. Towards a model for trust relationships in virtual enterprises in Proceeding of 14th International Workshop

on Database and Expert Systems Applications, 2003 , 1-5 Sept. 2003 Pages:420 – 424

[5] Au, R.; Looi, M.; Ashley, P. Automated cross-organizational trust establishment on extranets Information Technology for

Virtual Enterprises, 2001. ITVE 2001. Proceedings. Workshop on , 29-30 Jan. 2001 Pages:3 – 11

[6] Microsoft .NET Passport Service Guide Kit Version 2.5

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/passport25/start_full.asp

[7] Liberty Alliance Project http://www.projectliberty.org

[8] Security in a Web Services World: A Proposed Architecture and Roadmap: A Joint White Paper from IBM Corporation

and Microsoft Corporation April 7, 2002

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp

[9] Web Services Trust Language (WS-Trust) Version 1.1 May 2004

http://msdn.microsoft.com/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-trust.a

sp

[10] Federation of Identities in a Web Services World (whitepaper), July 2003, International Business Machines Corporation

and Microsoft Corporation

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-federation-strategy.asp

[11] WS-Federation Language (WS-Federation) Specification, Version 1.0, July 2003, International Business Machines

Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., and VeriSign, Inc.

http://msdn.microsoft.com/ws/2003/07/ws-federation/

[12] WS-Federation: Passive Requestor Profile Specification, Version 1.0, July 2003 Version 1.0, International Business

Machines Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., and VeriSign, Inc.

http://msdn.microsoft.com/ws/2003/07/ws-passive-profile/

[13] Federated Identity Management Interoperability, WS-Federation Passive Requestor Profile Interoperability Workshop,

Microsoft Corporation, May 2004

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsfedinterop.asp

[14] Security Assertions Markup Language (SAML) Specification, November 2002, Version 1.0

http://www.oasis-open.org/specs/#samlv1.0

[15] W. Winsborough, K. E. Seamons, and V. Jones. Automated Trust Negotiation. DARPA Information Survivability

Conference and Exposition, Hilton Head, SC, January 2000. http://citeseer.ist.psu.edu/293546.html

[16] Ting Yu and Marianne Winslett and Kent E. Seamons, Interoperable strategies in automated trust negotiation, ACM

Conference on Computer and Communications Security, 146-155, 2001,

http://citeseer.ist.psu.edu/yu01interoperable.html

[17] Bertino and Ferrari and Squicciarini, Trust-chi: An {XML} Framework for Trust Negotiations, IFIP-TC6 TC11

International Conference, Communications and Multimedia Security (CMS), LNCS

[18] Skogsrud, H. Benatallah, B. and Casati, F. Model-driven trust negotiation for Web services Univ. of New South Wales,

Sydney, NSW, Australia This paper appears in: Internet Computing, IEEE

8. Appendix

8.1 Policy Files 8.1.1 TES Registration at Local STS <?xml version="1.0" encoding="utf-8"?>

<TES>

<Domain>

<Name>MyTES</Name>

<Url>http://vsadev3.cs.virginia.edu/cs551project/TES</Url>

<WebAcceptingUrl>http://vsadev3.cs.virginia.edu/cs551project/TES/incoming.aspx</WebAcceptingUrl>

<TokenResolvingUrl>http://vsadev3.cs.virginia.edu/cs551project/TES/TESService.asmx</TokenResolvingUrl>

</Domain>

</TES>

8.1.2 Trusted Domain Registration at Local STS <?xml version="1.0" encoding="utf-8"?>

<LocalPolicy>

<Domain>

<Url>http://vsadev3.cs.virginia.edu/cs551project/msn</Url>

<Allowed>true</Allowed>

<DefaultHandler>http://vsadev3.cs.virginia.edu/cs551project/portal/MapUserPopUp.aspx</DefaultHandler>

<IDMappingSet>

</IDMappingSet>

<TrustLevelMappingSet>

<TrustLevelMapping>

<RemoteTrustLevel>*</RemoteTrustLevel>

<LocalTrustLevel>Password</LocalTrustLevel>

</TrustLevelMapping>

</TrustLevelMappingSet>

</Domain>

<Domain>

<Url>http://vsadev3.cs.virginia.edu/CS551Project/PharmacyTrustLevelSTS/TrustLevelSTS.ashx</Url>

<Allowed>true</Allowed>

<DefaultHandler>

</DefaultHandler>

<IDMappingSet>

<IDMapping>

<RemoteUserID>*</RemoteUserID>

<LocalUserID>pharmacy</LocalUserID>

</IDMapping>

</IDMappingSet>

<TrustLevelMappingSet>

<TrustLevelMapping>

<RemoteTrustLevel>*</RemoteTrustLevel>

<LocalTrustLevel>Password</LocalTrustLevel>

<LocalTTL>1000</LocalTTL>

</TrustLevelMapping>

</TrustLevelMappingSet>

</Domain>

</LocalPolicy>

8.1.3 Domain Registration at TES <?xml version="1.0" encoding="utf-8"?>

<DomainRegistration>

<Domain>

<Name>Medical Portal</Name>

<Url>http://vsadev3.cs.virginia.edu/cs551project/portal</Url>

<WebAcceptingUrl>http://vsadev3.cs.virginia.edu/cs551project/portal/incoming.aspx</WebAcceptingUrl>

<TokenResolvingUrl>http://vsadev3.cs.virginia.edu/cs551project/portal/TokenResolve.asmx</TokenResolvingUrl>

</Domain>

<Domain>

<Name>MSN</Name>

<Url>http://vsadev3.cs.virginia.edu/cs551project/msn</Url>

<WebAcceptingUrl>http://vsadev3.cs.virginia.edu/cs551project/msn/incoming.aspx</WebAcceptingUrl>

<TokenResolvingUrl>http://vsadev3.cs.virginia.edu/cs551project/msn/TokenResolve.asmx</TokenResolvingUrl>

</Domain>

</DomainRegistration>

8.1.4 Standard Attribute Names at TES <?xml version="1.0" encoding="utf-8" ?>

<TokenInfoItemSet xmlns="">

<TokenInfoItem>

<Name>User Name</Name>

<Type>string</Type>

</TokenInfoItem>

<TokenInfoItem>

<Name>Trust Level</Name>

<Type>string</Type>

</TokenInfoItem>

</TokenInfoItemSet>