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
Policy
Policy
process of security token exchange via TES in passive federation is further described blow.
Token
Exchange
Service
4
R
ttr
tw
ith
A
d
W
ra
pp
in
g
R
eq
ue
s
5.
Fo
rw
ar
ACTIVE FEDERATION
ar
rw
Fo
3.
Lo
ca
ib
ut
e
R
lT
ok
e
n
eq
ue
s
t
to
es
ut
ib
ttr
A en
re k
ui To
cq al
A c
st
d Lo
ue
a n te
eq
st rea
R
ue C
ng
eq
di
PASSIVE FEDERATION
Policy
Policy
Policy
Policy
H
Security
Token
Service
2.
Security
Token
Service
2. Exchange Hospital Token for Pharmacy Token
1. Intercepting
Request
3. Request with Pharmacy Token
1. Acquire Hospital
Token
Web Service
Web Portal
Client
Browser
6. Request with Pharmacy Token
Web Portal
Request Directly with Policy Caching
Hospital Trust
Domain
Pharmacy Trust
Domain
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 Levels
4
Fingerprint
Fingerprint
3
Signature
Signature
2.5
RF-ID
RF-ID
2
e-Token
e-Token
1 *******
Password
Password
Anonymous
Anonymous
0
???
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>