Identity Federation in Federated Trust Healthcare Network

Size: px
Start display at page:

Download "Identity Federation in Federated Trust Healthcare Network"


1 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. 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

2 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,

3 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 (, 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 3 rd 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, , 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.

4 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

5 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

6 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. Token Exchange Service Policy PASSIVE FEDERATION ACTIVE FEDERATION Security Token Service 5. Forward Attribute Request 2. Wrapping Request with Local Token 4 Request and Acquire Attributes to Create Local Token 3. Forwarding Request Security Token Service Policy 2. Exchange Hospital Token for Pharmacy Token Policy 1. Intercepting Request 1. Acquire Hospital Token 3. Request with Pharmacy Token Web Service Web Portal Client Browser 6. Request with Pharmacy Token Web Portal Hospital Trust Domain Request Directly with Policy Caching 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.

7 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 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 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 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

8 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??? 0??? Anonymous Anonymous Figure 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 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 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.


10 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 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.

11 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) 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: , 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 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

12 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 [2] Heimbigner, D., and McLeod, D., A Federated Architecture for Information Management, ACM Transaction on office Information Systems, 3 July [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, 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 Pages: [5] Au, R.; Looi, M.; Ashley, P. Automated cross-organizational trust establishment on extranets Information Technology for Virtual Enterprises, ITVE Proceedings. Workshop on, Jan Pages:3 11 [6] Microsoft.NET Passport Service Guide Kit Version 2.5 [7] Liberty Alliance Project [8] Security in a Web Services World: A Proposed Architecture and Roadmap: A Joint White Paper from IBM Corporation and Microsoft Corporation April 7, [9] Web Services Trust Language (WS-Trust) Version 1.1 May sp

13 [10] Federation of Identities in a Web Services World (whitepaper), July 2003, International Business Machines Corporation and Microsoft Corporation [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. [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. [13] Federated Identity Management Interoperability, WS-Federation Passive Requestor Profile Interoperability Workshop, Microsoft Corporation, May [14] Security Assertions Markup Language (SAML) Specification, November 2002, Version 1.0 [15] W. Winsborough, K. E. Seamons, and V. Jones. Automated Trust Negotiation. DARPA Information Survivability Conference and Exposition, Hilton Head, SC, January [16] Ting Yu and Marianne Winslett and Kent E. Seamons, Interoperable strategies in automated trust negotiation, ACM Conference on Computer and Communications Security, , 2001, [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 TES Registration at Local STS <?xml version="1.0" encoding="utf-8"?> <TES> <Domain> <Name>MyTES</Name> <Url></Url> <WebAcceptingUrl></WebAcceptingUrl> <TokenResolvingUrl></TokenResolvingUrl> </Domain> </TES> Trusted Domain Registration at Local STS <?xml version="1.0" encoding="utf-8"?> <LocalPolicy> <Domain> <Url></Url>

14 <Allowed>true</Allowed> <DefaultHandler></DefaultHandler> <IDMappingSet> </IDMappingSet> <TrustLevelMappingSet> <TrustLevelMapping> <RemoteTrustLevel>*</RemoteTrustLevel> <LocalTrustLevel>Password</LocalTrustLevel> </TrustLevelMapping> </TrustLevelMappingSet> </Domain> <Domain> <Url></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> Domain Registration at TES <?xml version="1.0" encoding="utf-8"?> <DomainRegistration> <Domain> <Name>Medical Portal</Name> <Url></Url> <WebAcceptingUrl></WebAcceptingUrl> <TokenResolvingUrl></TokenResolvingUrl> </Domain> <Domain> <Name>MSN</Name> <Url></Url> <WebAcceptingUrl></WebAcceptingUrl>

15 <TokenResolvingUrl></TokenResolvingUrl> </Domain> </DomainRegistration> 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>

User-centric Mobile Identity Management Services 1

User-centric Mobile Identity Management Services 1 User-centric Mobile Identity Management Services 1 Tewfiq El Maliki and Jean-Marc Seigneur Abstract. Digital identity is the ground necessary to guarantee that the Internet infrastructure is strong enough

More information

Evaluation of different Open Source Identity management Systems

Evaluation of different Open Source Identity management Systems Evaluation of different Open Source Identity management Systems Ghasan Bhatti, Syed Yasir Imtiaz Linkoping s universitetet, Sweden [ghabh683, syeim642] 1. Abstract Identity management systems

More information

Distributed Identity Management Model for Digital Ecosystems

Distributed Identity Management Model for Digital Ecosystems International Conference on Emerging Security Information, Systems and Technologies Distributed Identity Management Model for Digital Ecosystems Hristo Koshutanski Computer Science Department University

More information

Federated Identity in the Enterprise

Federated Identity in the Enterprise 425.216.0720 WHITE PAPER The proliferation of user accounts can lead to a lowering of the enterprise security posture as users record their account information in order to remember

More information

Federated Identity Management

Federated Identity Management Federated Identity Management David W Chadwick Computing Laboratory, University of Kent, Canterbury, CT2 7NF, UK Abstract. This paper addresses the topic of federated identity management.

More information

NEXUS The RSA Security Identity Management System

NEXUS The RSA Security Identity Management System THE NEXUS IDENTITY WHITE MANAGEMENT PAPER SYSTEM NEXUS The RSA Security Identity Management System A Technical Vision for Identity and Access Management WHITE PAPER The RSA Security Identity Management

More information

Domain 12: Guidance for Identity & Access Management V2.1

Domain 12: Guidance for Identity & Access Management V2.1 Domain 12: Guidance for Identity & Access Management V2.1 Prepared by the Cloud Security Alliance April 2010 Introduction The permanent and official location for this Cloud Security Alliance Domain 12

More information

Economics of Identity Management Systems - Towards an Economically Adaptive User-Centric IdMS. Mohammed H. Almeshekah

Economics of Identity Management Systems - Towards an Economically Adaptive User-Centric IdMS. Mohammed H. Almeshekah Economics of Identity Management Systems - Towards an Economically Adaptive User-Centric IdMS Mohammed H. Almeshekah Supervisor: Dr. Geraint Price Submitted as part of the requirements for the award of

More information

The Definitive Guide To. Identity Management. Archie Reed

The Definitive Guide To. Identity Management. Archie Reed The Definitive Guide To tm Identity Management Archie Reed Introduction Introduction By Sean Daily, Series Editor The book you are about to enjoy represents an entirely new modality of publishing and a

More information

Secure Credential Federation for Hybrid Cloud Environment with SAML Enabled Multifactor Authentication using Biometrics

Secure Credential Federation for Hybrid Cloud Environment with SAML Enabled Multifactor Authentication using Biometrics Secure Credential Federation for Hybrid Cloud Environment with SAML Enabled Multifactor Authentication using Biometrics B.Prasanalakshmi Assistant Professor Department of CSE Thirumalai Engineering College

More information

Guide to Secure Web Services

Guide to Secure Web Services Special Publication 800-95 (Draft) Guide to Secure Web Services Recommendations of the National Institute of Standards and Technology Anoop Singhal Theodore Winograd Karen Scarfone NIST Special Publication

More information

The Identity Crisis Security, Privacy and Usability Issues in Identity Management

The Identity Crisis Security, Privacy and Usability Issues in Identity Management Preprint Id: identity-crisis-body.tex 1355 2011-01-02 14:00:45Z jhh The Identity Crisis Security, Privacy and Usability Issues in Identity Management Gergely Alpár Jaap-Henk Hoepman Johanneke Siljee January

More information

Best Practices for Integrating Kerberos into Your Application

Best Practices for Integrating Kerberos into Your Application Best Practices for Integrating Kerberos into Your Application This paper describes best practices for application developers who wish to add support for the Kerberos Network Authentication System to their

More information

Introduction to Online Identity Management By Thomas J. Smedinghoff 1

Introduction to Online Identity Management By Thomas J. Smedinghoff 1 Introduction to Online Identity Management By Thomas J. Smedinghoff 1 1. Identity Management Basics... 3 (a) Identification... 4 (1) Scope and Accuracy... 5 (2) Issuance of Credential... 6 (b) Authentication...

More information

Situational Identity: a Person-centered Identity Management Approach

Situational Identity: a Person-centered Identity Management Approach Situational Identity: a Person-centered Identity Management Approach Tatyana Ryutov and Clifford Neuman Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001,

More information

A Delegation Framework for Federated Identity Management

A Delegation Framework for Federated Identity Management A Framework for Federated Identity Management Hidehito Gomi, Makoto Hatakeyama, Shigeru Hosono and Satoru Fujita NEC Internet Systems Research Laboratories 1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa

More information

Revised edition. OIO Web SSO Profile V2.0.9 (also known as OIOSAML 2.0.9) Includes errata and minor clarifications

Revised edition. OIO Web SSO Profile V2.0.9 (also known as OIOSAML 2.0.9) Includes errata and minor clarifications OIO Web SSO Profile V2.0.9 (also known as OIOSAML 2.0.9) Revised edition Includes errata and minor clarifications Danish Agency for Digitisation September 2012 Contents > 1 Introduction 8 1.1 Referenced

More information

User Centric Identity Management

User Centric Identity Management AusCERT Conference 005 User Centric Identity Management Audun Jøsang and Simon Pope CRC for Enterprise Distributed Systems Technology (DSTC Pty Ltd) The University of Queensland, 07, Australia {ajosang,

More information

Improving Privacy in Identity Management Systems for Health Care Scenarios

Improving Privacy in Identity Management Systems for Health Care Scenarios Improving Privacy in Identity Management Systems for Health Care Scenarios Rosa Sánchez-Guerrero, Florina Almenárez, Daniel Díaz-Sánchez, Andrés Marín and Patricia Arias Dept. Telematic Engineering, Carlos

More information

agility made possible

agility made possible WHITE PAPER Web Security Management Solution from CA Technologies February 2012 securing servicesbased IT architectures with CA SiteMinder Web Services Security agility made possible table of contents

More information

Usability and Privacy in Identity Management Architectures

Usability and Privacy in Identity Management Architectures Usability and Privacy in Identity Management Architectures Audun Jøsang Muhammed Al Zomai Suriadi Suriadi Queensland University of Technology P.O. Box 2434, Brisbane Qld 4001, Australia Email:

More information

Oracle Access Management

Oracle Access Management Oracle Access Management Complete, Integrated, Scalable Access Management Solution O R A C L E W H I T E P A P E R M A Y 2 0 1 5 Disclaimer The following is intended to outline our general product direction.

More information

Introduction to SOA with Web Services

Introduction to SOA with Web Services Chapter 1 Introduction to SOA with Web Services Complexity is a fact of life in information technology (IT). Dealing with the complexity while building new applications, replacing existing applications,

More information

Comparative analysis - Web-based Identity Management Systems

Comparative analysis - Web-based Identity Management Systems Comparative analysis - Web-based Identity Management Systems Oscar Manso, Morten Christiansen and Gert Mikkelsen THE ALEXANDRA INSTITUTE 15 December 2014 2/45 Contents 1. Introduction... 2 2. Current State

More information

Achieving Privacy in a Federated Identity Management System

Achieving Privacy in a Federated Identity Management System Achieving Privacy in a Federated Identity Management System Susan Landau 1, Hubert Le Van Gong 1, Robin Wilton 2 {,,} 1 Sun Microsystems

More information

Identity Management Systems A Comparison of Current Solutions

Identity Management Systems A Comparison of Current Solutions Identity Management Systems A Comparison of Current Solutions Annu Myllyniemi Helsinki University of Technology Abstract Nowadays, there is a vast amount of work going on in the

More information

Security Architecture for Cloud Computing Platform

Security Architecture for Cloud Computing Platform Security Architecture for Cloud Computing Platform SANJAYA DAHAL Master of Science Thesis Stockholm, Sweden 2012 TRITA-ICT-EX-2012:291 Abstract Cloud computing is an innovation of existing technology

More information

A Security Architecture for Object-Based Distributed Systems

A Security Architecture for Object-Based Distributed Systems A Security Architecture for Object-Based Distributed Systems Bogdan C. Popescu Vrije Universiteit Amsterdam, The Netherlands Maarten van Steen Vrije Universiteit Amsterdam, The Netherlands

More information

Notarized Federated Identity Management for Web Services

Notarized Federated Identity Management for Web Services Notarized Federated Identity Management for Web Services Michael T. Goodrich 1, Roberto Tamassia 2, and Danfeng Yao 2 1 Department of Computer Science, University of California Irvine, CA 92697 USA

More information

Understanding and Selecting Identity and Access Management for Cloud Services

Understanding and Selecting Identity and Access Management for Cloud Services Understanding and Selecting Identity and Access Management for Cloud Services Version 1.0 Released: June 14, 2013 Securosis, L.L.C. 515 E. Carefree Blvd. Suite #766 Phoenix, AZ 85085 T 602-412-3051

More information