Identity Federation in Federated Trust Healthcare Network

Size: px
Start display at page:

Download "Identity Federation in Federated Trust Healthcare Network"

Transcription

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

9

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>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> Trusted Domain Registration at Local STS <?xml version="1.0" encoding="utf-8"?> <LocalPolicy> <Domain> <Url>http://vsadev3.cs.virginia.edu/cs551project/msn</Url>

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

15 <TokenResolvingUrl>http://vsadev3.cs.virginia.edu/cs551project/msn/TokenResolve.asmx</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>

Federated Identity Management Solutions

Federated Identity Management Solutions Federated Identity Management Solutions Jyri Kallela Helsinki University of Technology jkallela@cc.hut.fi Abstract Federated identity management allows users to access multiple services based on a single

More information

Federated Identity Architectures

Federated Identity Architectures Federated Identity Architectures Uciel Fragoso-Rodriguez Instituto Tecnológico Autónomo de México, México {uciel@itam.mx} Maryline Laurent-Maknavicius CNRS Samovar UMR 5157, GET Institut National des Télécommunications,

More information

Federated Identity in the Enterprise

Federated Identity in the Enterprise www.css-security.com 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

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]@student.liu.se 1. Abstract Identity management systems

More information

Nationwide and Regional Health Information Networks and Federated Identity for Authentication and HIPAA Compliance

Nationwide and Regional Health Information Networks and Federated Identity for Authentication and HIPAA Compliance Nationwide and Regional Health Information Networks and Federated Identity for Authentication and HIPAA Compliance Christina Stephan, MD Co-Chair Liberty Alliance ehealth SIG National Library of Medicine

More information

The Primer: Nuts and Bolts of Federated Identity Management

The Primer: Nuts and Bolts of Federated Identity Management The Primer: Nuts and Bolts of Federated Identity Management Overview For any IT department, it is imperative to understand how your organization can securely manage and control users identities. With so

More information

On A-Select and Federated Identity Management Systems

On A-Select and Federated Identity Management Systems On A-Select and Federated Identity Management Systems Joost Reede August 4, 2007 Master s Thesis Information Systems Chair Computer Science Department University of Twente ii This thesis is supervised

More information

The Primer: Nuts and Bolts of Federated Identity Management

The Primer: Nuts and Bolts of Federated Identity Management The Primer: Nuts and Bolts of Federated Identity Management Executive Overview For any IT department, it is imperative to understand how your organization can securely manage and control users identities.

More information

Federated, Secure Trust Networks for Distributed Healthcare IT Services

Federated, Secure Trust Networks for Distributed Healthcare IT Services Federated, Secure Trust Networks for Distributed Healthcare IT Services Alfred C. Weaver, Samuel J. Dwyer III*, Andrew M. Snyder, James Van Dyke, James Hu, Xiaohui Chen, Timothy Mulholland, Andrew Marshall

More information

Identity Management im Liberty Alliance Project

Identity Management im Liberty Alliance Project Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Identity Management im Liberty Alliance Project Seminar: Datenkommunikation und verteilte

More information

NIST s Guide to Secure Web Services

NIST s Guide to Secure Web Services NIST s Guide to Secure Web Services Presented by Gaspar Modelo-Howard and Ratsameetip Wita Secure and Dependable Web Services National Institute of Standards and Technology. Special Publication 800-95:

More information

Identity opens the participation age. Dr. Rainer Eschrich. Program Manager Identity Management Sun Microsystems GmbH

Identity opens the participation age. Dr. Rainer Eschrich. Program Manager Identity Management Sun Microsystems GmbH Identity opens the participation age Open Web Single Sign- On und föderierte SSO Dr. Rainer Eschrich Program Manager Identity Management Sun Microsystems GmbH Agenda The Identity is the Network Driving

More information

An Oracle White Paper Dec 2013. Oracle Access Management Security Token Service

An Oracle White Paper Dec 2013. Oracle Access Management Security Token Service An Oracle White Paper Dec 2013 Oracle Access Management Security Token Service Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only,

More information

Internet Single Sign-On Systems

Internet Single Sign-On Systems Internet Single Sign-On Systems Radovan SEMANČÍK nlight, s.r.o. Súľovská 34, 812 05 Bratislava, Slovak Republic semancik@nlight.sk Abstract. This document describes the requirements and general principles

More information

Glossary of Key Terms

Glossary of Key Terms and s Branch Glossary of Key Terms The terms and definitions listed in this glossary are used throughout the s Package to define key terms in the context of. Access Control Access The processes by which

More information

Web Applications Access Control Single Sign On

Web Applications Access Control Single Sign On Web Applications Access Control Single Sign On Anitha Chepuru, Assocaite Professor IT Dept, G.Narayanamma Institute of Technology and Science (for women), Shaikpet, Hyderabad - 500008, Andhra Pradesh,

More information

Why Identity Management. Identity Management. What We Cover. Role of Digital Identity. Digital Identity. Digital Identity (or network identity)

Why Identity Management. Identity Management. What We Cover. Role of Digital Identity. Digital Identity. Digital Identity (or network identity) Why Identity Management Identity Management Claudiu Duma Identity crisis Privacy concerns Identity theft Terrorist threat Department of Computer and Information Science cladu@ida.liu.se What We Cover Digital

More information

AND SUN OPENSSO MICROSOFT GENEVA SERVER ENABLING UNPRECEDENTED COLLABORATION ACROSS HETEROGENEOUS IT ENVIRONMENTS. White Paper May 2009.

AND SUN OPENSSO MICROSOFT GENEVA SERVER ENABLING UNPRECEDENTED COLLABORATION ACROSS HETEROGENEOUS IT ENVIRONMENTS. White Paper May 2009. MICROSOFT GENEVA SERVER AND SUN OPENSSO ENABLING UNPRECEDENTED COLLABORATION ACROSS HETEROGENEOUS IT ENVIRONMENTS White Paper May 2009 Abstract Interoperability between applications in heterogeneous technology

More information

Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver

Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver SAP Product Management, SAP NetWeaver Identity Management

More information

Tenrox. Single Sign-On (SSO) Setup Guide. January, 2012. 2012 Tenrox. All rights reserved.

Tenrox. Single Sign-On (SSO) Setup Guide. January, 2012. 2012 Tenrox. All rights reserved. Tenrox Single Sign-On (SSO) Setup Guide January, 2012 2012 Tenrox. All rights reserved. About this Guide This guide provides a high-level technical overview of the Tenrox Single Sign-On (SSO) architecture,

More information

Web Services Security: OpenSSO and Access Management for SOA. Sang Shin Java Technology Evangelist Sun Microsystems, Inc. javapassion.

Web Services Security: OpenSSO and Access Management for SOA. Sang Shin Java Technology Evangelist Sun Microsystems, Inc. javapassion. Web Services Security: OpenSSO and Access Management for SOA Sang Shin Java Technology Evangelist Sun Microsystems, Inc. javapassion.com 1 Agenda Need for Identity-based Web services security Single Sign-On

More information

The Top 5 Federated Single Sign-On Scenarios

The Top 5 Federated Single Sign-On Scenarios The Top 5 Federated Single Sign-On Scenarios Table of Contents Executive Summary... 1 The Solution: Standards-Based Federation... 2 Service Provider Initiated SSO...3 Identity Provider Initiated SSO...3

More information

SCUR203 Why Do We Need Security Standards?

SCUR203 Why Do We Need Security Standards? SCUR203 Why Do We Need Security Standards? Cristina Buchholz Product Security, SAP Learning Objectives As a result of this workshop, you will be able to: Recognize the need for standardization Understand

More information

Flexible Identity Federation

Flexible Identity Federation Flexible Identity Federation Quick start guide version 1.0.1 Publication history Date Description Revision 2015.09.23 initial release 1.0.0 2015.12.11 minor updates 1.0.1 Copyright Orange Business Services

More information

Allidm.com. SSO Introduction. Discovering IAM Solutions. Leading the IAM Training. @aidy_idm facebook/allidm

Allidm.com. SSO Introduction. Discovering IAM Solutions. Leading the IAM Training. @aidy_idm facebook/allidm Discovering IAM Solutions Leading the IAM Training @aidy_idm facebook/allidm SSO Introduction Disclaimer and Acknowledgments The contents here are created as a own personal endeavor and thus does not reflect

More information

Ameritas Single Sign-On (SSO) and Enterprise SAML Standard. Architectural Implementation, Patterns and Usage Guidelines

Ameritas Single Sign-On (SSO) and Enterprise SAML Standard. Architectural Implementation, Patterns and Usage Guidelines Ameritas Single Sign-On (SSO) and Enterprise SAML Standard Architectural Implementation, Patterns and Usage Guidelines 1 Background and Overview... 3 Scope... 3 Glossary of Terms... 4 Architecture Components...

More information

Introduction to SAML

Introduction to SAML Introduction to THE LEADER IN API AND CLOUD GATEWAY TECHNOLOGY Introduction to Introduction In today s world of rapidly expanding and growing software development; organizations, enterprises and governments

More information

CLAIMS-BASED IDENTITY FOR WINDOWS

CLAIMS-BASED IDENTITY FOR WINDOWS CLAIMS-BASED IDENTITY FOR WINDOWS TECHNOLOGIES AND SCENARIOS DAVID CHAPPELL FEBRUARY 2011 SPONSORED BY MICROSOFT CORPORATION CONTENTS Understanding Claims-Based Identity... 3 The Problem: Working with

More information

PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN

PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN PROVIDING SINGLE SIGN-ON TO AMAZON EC2 APPLICATIONS FROM AN ON-PREMISES WINDOWS DOMAIN CONNECTING TO THE CLOUD DAVID CHAPPELL DECEMBER 2009 SPONSORED BY AMAZON AND MICROSOFT CORPORATION CONTENTS The Challenge:

More information

Network Identity. 1. Introduction. Kai Kang Helsinki University of Technology Networking Laboratory kkang@cc.hut.fi

Network Identity. 1. Introduction. Kai Kang Helsinki University of Technology Networking Laboratory kkang@cc.hut.fi Network Identity Kai Kang Helsinki University of Technology Networking Laboratory kkang@cc.hut.fi Abstract: This paper is concerning on modern Network Identity issues, emphasizing on network identity management,

More information

Identity Federation Broker for Service Cloud

Identity Federation Broker for Service Cloud 2010 International Conference on Sciences Identity Federation Broker for Cloud He Yuan Huang 1, Bin Wang 1, Xiao Xi Liu 1, Jing Min Xu 1 1 IBM Research China {huanghey, wangbcrl, liuxx, xujingm}@cn.ibm.com

More information

White Paper Delivering Web Services Security: The Entrust Secure Transaction Platform

White Paper Delivering Web Services Security: The Entrust Secure Transaction Platform White Paper Delivering Web Services Security: September 2003 Copyright 2003 Entrust. All rights reserved. Entrust is a registered trademark of Entrust, Inc. in the United States and certain other countries.

More information

Implementation Guide SAP NetWeaver Identity Management Identity Provider

Implementation Guide SAP NetWeaver Identity Management Identity Provider Implementation Guide SAP NetWeaver Identity Management Identity Provider Target Audience Technology Consultants System Administrators PUBLIC Document version: 1.10 2011-07-18 Document History CAUTION Before

More information

Biometric Single Sign-on using SAML

Biometric Single Sign-on using SAML Biometric Single Sign-on using SAML Architecture & Design Strategies Ramesh Nagappan CISSP Ramesh.Nagappan@sun.com 1 Setting Expectations What you can take away! Understand the importance of Single Sign-On

More information

Secure Semantic Web Service Using SAML

Secure Semantic Web Service Using SAML Secure Semantic Web Service Using SAML JOO-YOUNG LEE and KI-YOUNG MOON Information Security Department Electronics and Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu, Daejeon KOREA

More information

HP Software as a Service. Federated SSO Guide

HP Software as a Service. Federated SSO Guide HP Software as a Service Federated SSO Guide Document Release Date: July 2014 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty statements accompanying

More information

A Federated Model for Secure Web-Based Videoconferencing

A Federated Model for Secure Web-Based Videoconferencing A Federated Model for Secure Web-Based Videoconferencing Douglas C. Sicker, Ameet Kulkarni, Anand Chavali, and Mudassir Fajandar Interdisciplinary Telecommunications Dept. and Dept. of Computer Science

More information

QualysGuard SAML 2.0 Single Sign-On. Technical Brief

QualysGuard SAML 2.0 Single Sign-On. Technical Brief QualysGuard SAML 2.0 Single Sign-On Technical Brief Introduction Qualys provides its customer the option to use SAML 2.0 Single Sign On (SSO) authentication with their QualysGuard subscription. When implemented,

More information

SAML Security Option White Paper

SAML Security Option White Paper Fujitsu mpollux SAML Security Option White Paper Fujitsu mpollux Version 2.1 February 2009 First Edition February 2009 The programs described in this document may only be used in accordance with the conditions

More information

WebLogic Server 7.0 Single Sign-On: An Overview

WebLogic Server 7.0 Single Sign-On: An Overview WebLogic Server 7.0 Single Sign-On: An Overview Today, a growing number of applications are being made available over the Web. These applications are typically comprised of different components, each of

More information

Identity Federation Management to make Operational and Business Efficiency through SSO

Identity Federation Management to make Operational and Business Efficiency through SSO 2012 International Conference on Industrial and Intelligent Information (ICIII 2012) IPCSIT vol.31 (2012) (2012) IACSIT Press, Singapore Identity Federation Management to make Operational and Business

More information

SAML Federated Identity at OASIS

SAML Federated Identity at OASIS International Telecommunication Union SAML Federated Identity at OASIS Hal Lockhart BEA Systems Geneva, 5 December 2006 SAML and the OASIS SSTC o SAML: Security Assertion Markup Language A framework for

More information

A Conceptual Technique for Modelling Security as a Service in Service Oriented Distributed Systems

A Conceptual Technique for Modelling Security as a Service in Service Oriented Distributed Systems Volume 1, Number 2, December 2014 JOURNAL OF COMPUTER SCIENCE AND SOFTWARE APPLICATION A Conceptual Technique for Modelling Security as a Service in Service Oriented Distributed Systems Satish Kumar*,

More information

Leveraging SAML for Federated Single Sign-on:

Leveraging SAML for Federated Single Sign-on: Leveraging SAML for Federated Single Sign-on: Seamless Integration with Web-based Applications whether cloudbased, private, on-premise, or behind a firewall Single Sign-on Layer v.3.2-006 PistolStar, Inc.

More information

OIO SAML Profile for Identity Tokens

OIO SAML Profile for Identity Tokens > OIO SAML Profile for Identity Tokens Version 1.0 IT- & Telestyrelsen October 2009 Content > Document History 3 Introduction 4 Related profiles 4 Profile Requirements 6 Requirements 6

More information

Research and Implementation of Single Sign-On Mechanism for ASP Pattern *

Research and Implementation of Single Sign-On Mechanism for ASP Pattern * Research and Implementation of Single Sign-On Mechanism for ASP Pattern * Bo Li, Sheng Ge, Tian-yu Wo, and Dian-fu Ma Computer Institute, BeiHang University, PO Box 9-32 Beijing 100083 Abstract Software

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

Securing Web Services With SAML

Securing Web Services With SAML Carl A. Foster CS-5260 Research Project Securing Web Services With SAML Contents 1.0 Introduction... 2 2.0 What is SAML?... 2 3.0 History of SAML... 3 4.0 The Anatomy of SAML 2.0... 3 4.0.1- Assertion

More information

Federation Proxy for Cross Domain Identity Federation

Federation Proxy for Cross Domain Identity Federation Proxy for Cross Domain Identity Makoto Hatakeyama NEC Corporation, Common Platform Software Res. Lab. 1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa 211-8666, Japan +81-44-431-7663 m-hatake@ax.jp.nec.com

More information

IT@Intel. Improving Security and Productivity through Federation and Single Sign-on

IT@Intel. Improving Security and Productivity through Federation and Single Sign-on White Paper Intel Information Technology Computer Manufacturing Security Improving Security and Productivity through Federation and Single Sign-on Intel IT has developed a strategy and process for providing

More information

CS 356 Lecture 28 Internet Authentication. Spring 2013

CS 356 Lecture 28 Internet Authentication. Spring 2013 CS 356 Lecture 28 Internet Authentication Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists

More information

Chapter 12 GRID SECURITY ARCHITECTURE: Requirements,fundamentals, standards, and models

Chapter 12 GRID SECURITY ARCHITECTURE: Requirements,fundamentals, standards, and models Author manuscript, published in Security in Distributed, Grid, Mobile, and Pervasive Computing, Auerbach Publications, pp. 255-288, April, 2007 https://www.nics.uma.es Security in Distributed, Grid, and

More information

Title: A Client Middleware for Token-Based Unified Single Sign On to edugain

Title: A Client Middleware for Token-Based Unified Single Sign On to edugain Title: A Client Middleware for Token-Based Unified Single Sign On to edugain Sascha Neinert Computing Centre University of Stuttgart, Allmandring 30a, 70550 Stuttgart, Germany e-mail: sascha.neinert@rus.uni-stuttgart.de

More information

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies

Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies Guideline Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies Product(s): IBM Cognos 8 BI Area of Interest: Security Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 2 Copyright

More information

This Working Paper provides an introduction to the web services security standards.

This Working Paper provides an introduction to the web services security standards. International Civil Aviation Organization ATNICG WG/8-WP/12 AERONAUTICAL TELECOMMUNICATION NETWORK IMPLEMENTATION COORDINATION GROUP EIGHTH WORKING GROUP MEETING (ATNICG WG/8) Christchurch New Zealand

More information

Software Requirement Specification Web Services Security

Software Requirement Specification Web Services Security Software Requirement Specification Web Services Security Federation Manager 7.5 Version 0.3 (Draft) Please send comments to: dev@opensso.dev.java.net This document is subject to the following license:

More information

OPENIAM ACCESS MANAGER. Web Access Management made Easy

OPENIAM ACCESS MANAGER. Web Access Management made Easy OPENIAM ACCESS MANAGER Web Access Management made Easy TABLE OF CONTENTS Introduction... 3 OpenIAM Access Manager Overview... 4 Access Gateway... 4 Authentication... 5 Authorization... 5 Role Based Access

More information

T-Check in Technologies for Interoperability: Web Services and Security Single Sign-On

T-Check in Technologies for Interoperability: Web Services and Security Single Sign-On T-Check in Technologies for Interoperability: Web Services and Security Single Sign-On Lutz Wrage Soumya Simanta Grace A. Lewis Saul Jaspan December 2007 TECHNICAL NOTE CMU/SEI-2008-TN-026 Integration

More information

New Generation of Liberty. for Enterprise. Fulup Ar Foll, Sun Microsystems Fulup@sun.com

New Generation of Liberty. for Enterprise. Fulup Ar Foll, Sun Microsystems Fulup@sun.com New Generation of Liberty TEG Federated Progress Architecture Update for Enterprise Fulup Ar Foll, Sun Microsystems fulup@sun.com 1 Identity Framework Problematic User Seamless (nothing is too simple)

More information

Introduction to Identity Management. Sam Lee, Outblaze Ltd.

Introduction to Identity Management. Sam Lee, Outblaze Ltd. Introduction to Identity Management Sam Lee, Outblaze Ltd. Agenda Background Identity Management Single Sign-On Federation Future s Identity management Conclusions 2 Background Why identity management?

More information

Authentication and Single Sign On

Authentication and Single Sign On Contents 1. Introduction 2. Fronter Authentication 2.1 Passwords in Fronter 2.2 Secure Sockets Layer 2.3 Fronter remote authentication 3. External authentication through remote LDAP 3.1 Regular LDAP authentication

More information

Agenda. How to configure

Agenda. How to configure dlaw@esri.com Agenda Strongly Recommend: Knowledge of ArcGIS Server and Portal for ArcGIS Security in the context of ArcGIS Server/Portal for ArcGIS Access Authentication Authorization: securing web services

More information

IMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS

IMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS APPLICATION NOTE IMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS SAML 2.0 combines encryption and digital signature verification across resources for a more

More information

Biometric Single Sign-on using SAML Architecture & Design Strategies

Biometric Single Sign-on using SAML Architecture & Design Strategies Biometric Single Sign-on using SAML Architecture & Design Strategies Ramesh Nagappan Java Technology Architect Sun Microsystems Ramesh.Nagappan@sun.com 1 Setting Expectations What you can take away! Understand

More information

IGI Portal architecture and interaction with a CA- online

IGI Portal architecture and interaction with a CA- online IGI Portal architecture and interaction with a CA- online Abstract In the framework of the Italian Grid Infrastructure, we are designing a web portal for the grid and cloud services provisioning. In following

More information

Research on the Model of Enterprise Application Integration with Web Services

Research on the Model of Enterprise Application Integration with Web Services Research on the Model of Enterprise Integration with Web Services XIN JIN School of Information, Central University of Finance& Economics, Beijing, 100081 China Abstract: - In order to improve business

More information

Internet Single Sign-On Systems

Internet Single Sign-On Systems Research Report Author: Radovan Semančík Date: May 2005 Version: 1.0 Abstract: This document describes the requirements and general principles of Internet Single Sign-On systems. The general model of Internet

More information

OpenHRE Security Architecture. (DRAFT v0.5)

OpenHRE Security Architecture. (DRAFT v0.5) OpenHRE Security Architecture (DRAFT v0.5) Table of Contents Introduction -----------------------------------------------------------------------------------------------------------------------2 Assumptions----------------------------------------------------------------------------------------------------------------------2

More information

USING FEDERATED AUTHENTICATION WITH M-FILES

USING FEDERATED AUTHENTICATION WITH M-FILES M-FILES CORPORATION USING FEDERATED AUTHENTICATION WITH M-FILES VERSION 1.0 Abstract This article provides an overview of federated identity management and an introduction on using federated authentication

More information

Web Services Security with SOAP Security Proxies

Web Services Security with SOAP Security Proxies Web Services Security with Security Proxies Gerald Brose, PhD Technical Product Manager Xtradyne Technologies AG OMG Web Services Workshop USA 22 April 2003, Philadelphia Web Services Security Risks! Exposure

More information

WEB SERVICES SECURITY

WEB SERVICES SECURITY WEB SERVICES SECURITY February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in part without

More information

White paper December 2008. Addressing single sign-on inside, outside, and between organizations

White paper December 2008. Addressing single sign-on inside, outside, and between organizations White paper December 2008 Addressing single sign-on inside, outside, and between organizations Page 2 Contents 2 Overview 4 IBM Tivoli Unified Single Sign-On: Comprehensively addressing SSO 5 IBM Tivoli

More information

A secure and auditable Federated Identity and Access Management Infrastructure. Serge Bertini Director, Security Canada

A secure and auditable Federated Identity and Access Management Infrastructure. Serge Bertini Director, Security Canada A secure and auditable Federated Identity and Access Management Infrastructure Serge Bertini Director, Security Canada The Role of the Identity While Perimeters dissolve Applications become more distributed

More information

TIB 2.0 Administration Functions Overview

TIB 2.0 Administration Functions Overview TIB 2.0 Administration Functions Overview Table of Contents 1. INTRODUCTION 4 1.1. Purpose/Background 4 1.2. Definitions, Acronyms and Abbreviations 4 2. OVERVIEW 5 2.1. Overall Process Map 5 3. ADMINISTRATOR

More information

Developing a business model for Identity Management. Dr. Hellmuth Broda, VP Business Development, First Ondemand Spokesperson, Liberty Alliance

Developing a business model for Identity Management. Dr. Hellmuth Broda, VP Business Development, First Ondemand Spokesperson, Liberty Alliance Developing a business model for Identity Management Dr. Hellmuth Broda, VP Business Development, First Ondemand Spokesperson, Liberty Alliance Life With An Identity Mess A typical intensive IT user has

More information

Getting Started with Single Sign-On

Getting Started with Single Sign-On Getting Started with Single Sign-On I. Introduction Your institution is considering or has already purchased Collaboratory from Treetop Commons, LLC. One benefit provided to member institutions is Single

More information

Service Virtualization: Managing Change in a Service-Oriented Architecture

Service Virtualization: Managing Change in a Service-Oriented Architecture Service Virtualization: Managing Change in a Service-Oriented Architecture Abstract Load balancers, name servers (for example, Domain Name System [DNS]), and stock brokerage services are examples of virtual

More information

Single Sign-on. Overview. Using SSO with the Cisco WebEx and Cisco WebEx Meeting. Overview, page 1

Single Sign-on. Overview. Using SSO with the Cisco WebEx and Cisco WebEx Meeting. Overview, page 1 Overview, page 1 Using SSO with the Cisco WebEx and Cisco WebEx Meeting Applications, page 1 Requirements, page 2 Configuration of in Cisco WebEx Messenger Administration Tool, page 3 Sample Installation

More information

FTP-Stream Integrating Active Directory Federation Services

FTP-Stream Integrating Active Directory Federation Services FTP-Stream Integrating Active Directory Federation Services 1 Overview Active Directory Federation Services (ADFS) is a standards-based service that allows the secure sharing of identity information between

More information

Configuration Guide. SafeNet Authentication Service AD FS Agent

Configuration Guide. SafeNet Authentication Service AD FS Agent SafeNet Authentication Service AD FS Agent Configuration Guide Technical Manual Template Release 1.0, PN: 000-000000-000, Rev. A, March 2013, Copyright 2013 SafeNet, Inc. All rights reserved. 1 Document

More information

Extending DigiD to the Private Sector (DigiD-2)

Extending DigiD to the Private Sector (DigiD-2) TECHNISCHE UNIVERSITEIT EINDHOVEN Department of Mathematics and Computer Science MASTER S THESIS Extending DigiD to the Private Sector (DigiD-2) By Giorgi Moniava Supervisors: Eric Verheul (RU, PwC) L.A.M.

More information

This chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections:

This chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections: CHAPTER 1 SAML Single Sign-On This chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections: Junos Pulse Secure Access

More information

Integration Guide. SafeNet Authentication Service. Using SAS as an Identity Provider for Tableau Server

Integration Guide. SafeNet Authentication Service. Using SAS as an Identity Provider for Tableau Server SafeNet Authentication Service Integration Guide Technical Manual Template Release 1.0, PN: 000-000000-000, Rev. A, March 2013, Copyright 2013 SafeNet, Inc. All rights reserved. 1 Document Information

More information

SharePoint 2013 Logical Architecture

SharePoint 2013 Logical Architecture SharePoint 2013 Logical Architecture This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

More information

SAML-Based SSO Solution

SAML-Based SSO Solution About SAML SSO Solution, page 1 SAML-Based SSO Features, page 2 Basic Elements of a SAML SSO Solution, page 2 SAML SSO Web Browsers, page 3 Cisco Unified Communications Applications that Support SAML SSO,

More information

Integration Guide. SafeNet Authentication Service. Using SAS as an Identity Provider for Salesforce

Integration Guide. SafeNet Authentication Service. Using SAS as an Identity Provider for Salesforce SafeNet Authentication Service Integration Guide Technical Manual Template Release 1.0, PN: 000-000000-000, Rev. A, March 2013, Copyright 2013 SafeNet, Inc. All rights reserved. 1 Document Information

More information

New Single Sign-on Options for IBM Lotus Notes & Domino. 2012 IBM Corporation

New Single Sign-on Options for IBM Lotus Notes & Domino. 2012 IBM Corporation New Single Sign-on Options for IBM Lotus Notes & Domino 2012 IBM Corporation IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole

More information

Trusting XBRL: Using the Liberty Web Services Framework to Secure and Authenticate XBRL Documents

Trusting XBRL: Using the Liberty Web Services Framework to Secure and Authenticate XBRL Documents Trusting XBRL: Using the Liberty Web Services Framework to Secure and Authenticate XBRL Documents Farrukh Najmi and Eve Maler farrukh.najmi@sun.com, eve.maler@sun.com Sun Microsystems, Inc. Goals for today's

More information

SAP NetWeaver Single Sign-On. Product Management SAP NetWeaver Identity Management & Security June 2011

SAP NetWeaver Single Sign-On. Product Management SAP NetWeaver Identity Management & Security June 2011 NetWeaver Single Sign-On Product Management NetWeaver Identity Management & Security June 2011 Agenda NetWeaver Single Sign-On: Solution overview Key benefits of single sign-on Solution positioning Identity

More information

Department of Industry and Science

Department of Industry and Science Services Catalogue Department of Industry and Science Contents 1 Introduction 2 VANguard Services 2 About the VANguard Services Catalogue 2 Contact Details 2 2 VANguard Services 3 User Authentication Service

More information

The increasing popularity of mobile devices is rapidly changing how and where we

The increasing popularity of mobile devices is rapidly changing how and where we Mobile Security BACKGROUND The increasing popularity of mobile devices is rapidly changing how and where we consume business related content. Mobile workforce expectations are forcing organizations to

More information

GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK

GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK Antti Pyykkö, Mikko Malinen, Oskari Miettinen GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK TJTSE54 Assignment 29.4.2008 Jyväskylä University Department of Computer Science

More information

INTRODUCING GENEVA AN OVERVIEW OF THE GENEVA SERVER, CARDSPACE GENEVA, AND THE GENEVA FRAMEWORK DAVID CHAPPELL OCTOBER 2008

INTRODUCING GENEVA AN OVERVIEW OF THE GENEVA SERVER, CARDSPACE GENEVA, AND THE GENEVA FRAMEWORK DAVID CHAPPELL OCTOBER 2008 INTRODUCING GENEVA AN OVERVIEW OF THE GENEVA SERVER, CARDSPACE GENEVA, AND THE GENEVA FRAMEWORK DAVID CHAPPELL OCTOBER 2008 SPONSORED BY MICROSOFT CORPORATION CONTENTS Understanding Claims-Based Identity...

More information

Security Digital Certificate Manager

Security Digital Certificate Manager System i Security Digital Certificate Manager Version 5 Release 4 System i Security Digital Certificate Manager Version 5 Release 4 Note Before using this information and the product it supports, be sure

More information

Digital Identity and Identity Management Technologies.

Digital Identity and Identity Management Technologies. I. Agudo, Digital Identity and Identity Management Technologies, UPGRADE - The European Journal of the Informatics Professional, vol. 2010, pp. 6-12, 2010. NICS Lab. Publications: https://www.nics.uma.es/publications

More information

Authentication Methods

Authentication Methods Authentication Methods Overview In addition to the OU Campus-managed authentication system, OU Campus supports LDAP, CAS, and Shibboleth authentication methods. LDAP users can be configured through the

More information

Liberty Alliance Project Setting the Standard for Federated Network Identity

Liberty Alliance Project Setting the Standard for Federated Network Identity Liberty Alliance Project Setting the Standard for Network Identity Privacy, Identity Management and Services using Liberty technologies in Mobile Environment. Identity Management Rise of electronic networks:

More information