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 Systeme WS2003/2004 Pimjai Wesnarat Matrikelnummer: 244628 Betreuung: Marko Schuba und Silke Holtmanns Ericsson

Table of Content ABSTRACT...1 1. INTRODUCTION...2 1.1 WHAT IS LIBERTY ALLIANCE?...2 1.2 BUSINESS BENEFITS OF FEDERATED IDENTITY...3 2. LIBERTY ARCHITECTURE OVERVIEW...4 3. LIBERTY IDENTITY FEDERATION FRAMEWORK (ID-FF)...5 3.1 IDENTITY FEDERATION PROCEDURE...6 3.2 SINGLE SIGN-ON PROCEDURE...6 3.3 FEATURES PROVIDED BY LIBERTY ID-FF...7 4. LIBERTY IDENTITY WEB SERVICES FRAMEWORK (ID-WSF)...11 4.1 LIBERTY ID-WSF CLIENT PROFILES SPECIFICATION...11 4.2 LIBERTY ID-WSF SECURITY MECHANISMS...11 4.3 LIBERTY ID-WSF DISCOVERY SERVICE...12 4.4 LIBERTY ID-WSF INTERACTION SERVICE...15 4.5 LIBERTY ID-WSF DATA SERVICE TEMPLATE...16 5. LIBERTY IDENTITY SERVICES INTERFACE SPECIFICATIONS (ID-SIS)...18 5.1 LIBERTY ID-SIS PERSONAL PROFILE SERVICE...18 5.2 LIBERTY ID-SIS EMPLOYEE PROFILE SERVICE...19 6. USER EXPERIENCE EXAMPLE...20 CONCLUSION...22 REFERENCES...23

Abstract Currently a person has to manage number of identities in order to use services in a network. Also the person has to sign on many times to access services. This is inconvenient and expose security risk. This paper discusses the Liberty Alliance specifications that are aimed to solve these problems. The Liberty Alliance project provides framework for a federated identity network. The framework enables single sign-on mechanism. A federated identity network is a network where all identities of a person that were scattered all over the network are linked into one. Single sign-on is when the person signs on only once to use many services available in a network without having to sign-on again. These federated identity network and single sign-on mechanism increase functionalities of services and business opportunities. The Liberty is separated into phases. Phase one is to link identities into one federated identity and single sign-on mechanism, phase two is related to providing mechanisms for web services that use the federated identity to provide personal services to user, and future phase will be the services that use the federated identity. 1

1. Introduction 1.1 What is Liberty Alliance? Nowadays each company has its own identity management system. If one company provides one service on a network and therefore has one account for identifying a user, let say a pair of username and password. In order to use all the services that a user needs he has to have as many accounts as the number of the services. When wanting to move from one service to another service, a user has to sign in again with another username and password, which is inconvenient. Also, managing many usernames and passwords is troublesome and often users forget their passwords. The solution to this situation is to have a single sign-on so that users have to sign-on only once and can use many services that are available in a network. This single sign-on can happen in a federated identity network environment. The Liberty Alliance is the project providing standards for creating and using federated identity network. The federated identity network is about linking all user accounts in a network together to become user identity over that network without requiring central information storage. With federated identity, a user will have to sign-on only once to use all the services available in a circle of trust. The Liberty also takes care of privacy and security of the user data over the network. Microsoft.NET passport is an example of single sign-on but is not a member of the Liberty. Once user has signed on with a Microsoft.NET passport, he can use many services such as email, auction, community, and getting personalized information from the websites without having to sign in again. But Microsoft.NET passport has user information stored centrally, therefore is not a federated network. The Liberty Alliance is formed in December 2001 with 16 members and has grown up to more than 160 members in early 2003. The Liberty s members consist of many leading companies in a large range of industry such as finance, wireless services, telecommunications, security, transportation, and infrastructure technology, as well as several universities, governments, and consumer advocate organizations. The Liberty Alliance is separated into phases. The first phase was released on July 2002 providing specification about linking accounts within a circle of trust using single sign-on mechanism. The second phase was released on November 12, 2003 providing the framework for services using the federated identity. The future phase will provide services that take advantages from functionality available in the Liberty Alliance. The later phase will be built upon the prior phase providing more functionality, so there is no need to redo the implementation. 2

1.2 Business Benefits of Federated Identity Business benefits from implementing Liberty Alliance specification falls into four categories:- Revenue Growth through Development of Strategic Offerings: When companies become members in a circle of trust, they can have a business plan together and offer customers more services. This brings revenue growth to the companies. Cost Avoidance, Cost Reduction, and Increased Operational Efficiencies: By having single sign-on feature, employees can access to all applications and information faster. Therefore decrease operational time. In the Liberty enabled environment, users have ability to manage their own identity information, therefore reduce cost for identity management. Stronger Security and Risk Management: The Liberty provides context sensitive authentication, gradient levels authentication and access control policies, these increase security to the companies. It is also easier to control employee accounts and terminate orphan accounts that can be used to attack the companies. Interoperability and Decreased Development Time: The Liberty is easy to implement because it is based on existing standard, therefore decrease development time. And because the Liberty is designed to be compatible with many platforms and devices, can be implanted with any programming language and can be run on any network infrastructure that supports HTTP protocol, these features make interoperation between many types of systems easy. Companies do not have to have the same platforms and technology in order to use the liberty alliance. They can just make a common decision at the beginning of the project and then implement it later on without having to synchronize their systems together. 3

2. Liberty Architecture Overview Liberty Alliance consists of three major components that are Identity Federation Framework (ID-FF), Identity Web Services Framework (ID-WSF) and Identity Services Interface Specifications (ID-SIS). The Liberty architecture is multi-level layered as shown in Figure 1. 1 4 3 2 Figure 1: Liberty Alliance Architecture Liberty ID-FF (Figure 1) is identity federation and management framework. It provides the ability to link accounts of a user together and manages them. The framework can also be used in combination with organization s existing identity management system. Liberty ID-WSF provides a framework for services that wish to use the federated identity network. Liberty ID-SIS contains services such as calendar service, contact book, and geo-location. Liberty alliance is based on existing open standards (indicated with number 2 in Figure 1), e.g. HTTP. XML, SOAP, to avoid developing a similar or duplicate one. Also, because the existing standards are already used widely, it is convenient for implementers to implement the Liberty over the existing standards. Standards used in Liberty are: - HTTP 1.0 or HTTP 1.1 protocol for message transportation, TLS 1.0 or SSL 3.0 for secures connection, X.509 v3 certificate or SAML for authentication, SOAP over HTTP for method invocation, and WML 1.0, 1.1, 1.2, or 1.3 for WAP browser. 4

3. Liberty Identity Federation Framework (ID-FF) The Liberty Identity Federation Framework (ID-FF) defines single sign-on mechanisms and how to federate accounts together. An identity consists of attributes and preferences which can be used to identify an individual. Attributes and preferences are information associated with an individual such as name, date of birth, music preference, sport preference, and employee status. On a network, for example an Internet, an individual usually has more than one account for the services across the network. By comprising all the accounts on a network in to one there becomes a network identity. When businesses make business relationship together, then a circle of trust is formed. The Liberty circle of trust means that businesses in the circle of trust have agreed upon operational agreements based on the Liberty standards and guidelines. Within a circle of trust customers can perform transactions across companies seamlessly with security and privacy. In a network environment, there are service providers (SP) that provide services to users and identity providers (IdP) that provide a specific type of service to users, that are managing identity information for users and provides user authentication to other services. A user can be associated with more then one circle of trust, for example one at work within company s circle of trust and one at home. Figure 2: Federated Network Identity and Circle of Trust After a circle of trust is established, a user will have ability whether to link his accounts together or not. This accounts linking is called identity federation. After 5

accounts are linked together and user has signed in, user can move between services that are linked together within a circle of trust without having to sign in again. This is called single sign-on. 3.1 Identity Federation Procedure When a user signed on with an identity provider, the identity provider will ask whether he wants to federate his account at the identity provider or not. If user says yes, then this account will be able to federate with other accounts. After that, user moves to another service provider and signs on at the service provider with his local account. The service provider notices that the user has already been authenticated with an identity provider within its circle of trust, therefore it asks the user whether he wants to federate his account at identity provider to his local account at the service provider or not. If user says yes, then the federation will occur. The service provider provides the service to the user as usual after the federation. 3.2 Single Sign-On Procedure After a user federated his identity provider with a service provider, the user comes to use the service. There are three cases of possibility:- 1) User start by signing on at the identity provider and later comes to visit the service provider. The service provider will notice that he has already signed on so it provides personalized information to user without asking him to sign on again. 2) User comes to the service provider without signing on at any identity provider and has no common domain cookie (explained later). The service provider will provide a list of identity providers to select from. User selects one identity provider from a list. Service provider provides sign-on page to user, three ways of presenting sign-on page are possible:- - Service provider redirect user to identity provider website to log in. After logging in user will be sent back to service provider website. - Service provider provides a dialog box or a pop-up box for user to log in. After logging in, the dialog box will close. The dialog box presents identity provider s website therefore the authentication is also done at identity provider s website. The dialog box is only a technique to make user feel like he does not leave the service provider s website. - Service provider provides a sign-on form as its website, but after pressing submit the information will go the identity provider website to authenticate it. This is not a secure way since user has to expose information to service provider. 3) User comes to the service provider without signing on at any identity provider but has a common domain cookie. With common domain cookie, service provider can indicates which identity provider is used by the user. Therefore it can directly select the identity provider and provide user a way to sign-on as three method described before. 6

Figure 3 shows how a user, a service provider, and an identity provider communicate with each others for single sign-on on according to scenario 2. User Agent 1 2 5 Service Provider 3 4 Identity Provide r Figure 3: Single Sign-On via Redirection 1) User agent initiates a request to a service provider for a service. 2) The service provider redirects the user agent to an identity provider. 3) The user agent sends authentication information to the identity provider. 4) The identity provider authenticates the user and redirects the user agent back to the service provider. 5) The user agent sends the request to the service provider again with authentication information and therefore can now use the service. There are four specifications provided in ID-FF that are:- 1) Liberty ID-FF Bindings and Profiles Specification 2) Liberty ID-FF Protocols and Schema Specification 3) Liberty Metadata Description and Discovery Specification 4) Liberty Authentication Context Specification These specifications combined provide the following features to the Liberty:- 3.3 Features provided by Liberty ID-FF 3.3.1 Single Sign-On and Federation The first time user uses an identity provider to log in to a service provider, he must be given an option whether to federate an existing local identity onto the service provider with the identity provider identity or not. After federated the identity, the user can use the single sing-on feature of the Liberty. The basic steps for single sign-on would be like this: - first user agent connects to a service provider requesting for a service. The service provider then tells user to connect to an identity provider to authenticate himself and may also federate the identity from service provider with the identity from the identity provider. After authentication the user agent that is authenticated is sent back to the service provider with information about his authentication. The service provider now provides the service to user agent. 7

The basic steps can be made more specific by separating into three single sign-on profiles regarding to how the authentication information is sent between entities. A profile tells how, what, and when messages are sent between entities in a specific scenario. All the single sign-on profiles follow the same steps as explained above but the ways of sending authentication information are different. The three profiles are: - 1) Liberty Artifact Profile This profile uses SAML artifact to refer to authentication information. SAML (Security Assertion Markup Language) is an XML-based framework for exchanging authentication and authorization information. Authentication and authorization information come in the form of assertion about an entity. The SAML artifact is a reference to the SAML assertion that the service provider must dereference before getting the information of user s authentication. After the identity provider has authenticated the user, the identity provider redirects the user to the service provider by sending a HTTP 302 redirect or WML redirect or else and also send the SAML artifact along with the user to the service provider. For example in with HTTP 302 redirect, the following URL is sent to specify where to redirect to: - URL: http://<service provider URL>?<authentication attribute=value> The artifact is sent within the URL in the form of <authentication attribute=value>. The user agent gets the HTTP 302 with this URL, it then connect to the service provider with the given URL. The service provider extracts the artifact from the URL, de-refer it, and can now provide the service to the user agent. 2) Liberty Browser POST Profile This profile do not use artifact but instead it uses SAML <AuthnResponse> embedded within a form. After the identity provider has authenticated the user, it sends a form containing <AuthnResponse> back to the user. AuthnResponse contains information regarding user s authentication, for example assertion type, the identity provider s unique identifier and authentication context. When the user press a submit button. An embedded script executed the information contained in the form will be sent to the service provider. The service provider can then provide service to the user. 3) Liberty-Enabled Client and Proxy Profile A Liberty-Enabled Client is a client that knows how to process Liberty messages and knows about the identity provider the user wishes to use. A Liberty-Enabled Proxy is a HTTP proxy with the same ability with the liberty-enabled client. In this case, the service provider does not have to provide the list of identity providers to user agent because the agent already knows which one to be used. The communication between liberty-enabled client and the identity provider for authentication will go through the liberty messages via SOAP. SOAP (Simple Object Access Protocol) is an XML-based object invocation over HTTP protocol. SOAP is used in distributed systems to access services, objects, and server in platform-independent manner. 8

It is also possible that more than one identity provider are involved in an authentication process. That is in the case that the service provider does not have a direct trust relationship to the identity provider that user was authenticated. An identity provider may issue the authentication request to the authenticating identity provider on behalf of the user agent and sends the result back to the user agent. Otherwise the identity provider may choose to introduce the service provider to the authenticating identity provider. If they decide to trust each others dynamically, then the service provider can issue the authentication request directly to the authenticating identity provider. 3.3.2 Name Registration During a federation, the identity provider generates an initial handle to be used as name identifier that both service provider and identity provider use to refer to the user when communicating with each others. After the federation, the service provider or identity provider may register a new identifier or change a name identifier for a user with each others at anytime. 3.3.3 Federation Termination (Defederation) User has the ability to terminate federations or defederate identities whenever he wants. The defederation can be initiated either by a service provider or identity provider. After defederated, the identities are no longer linked and therefore no more information exchange between defederated services about the user should occur. 3.3.4 Single Logout When logging out, either from a service provider or identity provider, the logging out must be notified to all services that were authenticated with the identity provider that was signed out. Therefore all the service should be signed out almost simultaneously. 3.3.5 Identity Provider Introduction In circle of trusts, there are more than one identity providers. Service providers need to be able to specify which identity provider the user is using. This can be done with common domain cookie. In general, a cookie is allowed to be read only by the website that wrote them. The DNS is used to decide which website can read the cookie. A circle of trust in the liberty alliance consists of many websites hosting on different domains. Therefore Common Domain Cookie is introduced. By using a common domain for all members in a circle of trust to write and read a cookie, that cookie will be accessible by all. This is done by redirecting user to the common domain to read/write cookie, and then redirect the user back to the original domain. 3.3.6 Name Identifier Mapping When a service provider wants to communicate with another service provider on information upon a user but they were not federated by the user, the service provider 9

that wants to start the communication may send a request to the identity provider requesting for a name identifier of the user. The identity provider has to check its security policies first and if it is possible it will send the name identifier of the user to the requesting service provider. The service provider can now use the given name identifier to communicate with another service provider for information of the user. Name identifier may be encrypted to protect user s privacy. 3.3.7 Name Identifier Encryption This feature enables name identifiers of users to be encrypted and decrypted for security purpose. 3.3.8 Provider Introduction Notification One identity provider may introduce another identity provider to a service provider. This feature enables an identity provider to notify and be notified when a new federation between a service provider and the identity provider that was introduced occurs. 3.3.9 Provider Relationship Termination When an identity provider that introduced a service provider to another identity provider has terminated its relationship with the introduced identity provider, the relationship termination is notified to all service providers that involved in the introduction. 10

4. Liberty Identity Web Services Framework (ID- WSF) Liberty Identity Web Services Framework (ID-WSF) is a SOAP-based layered architecture for creating, discovering, and consuming identity services. ID-WSF services include Discovery Service, Interaction Service, and Data Service Template. Other than the services Liberty ID-WSF also provides security mechanism for protecting user s privacy and security, SOAP binding used to send the Liberty messages, metadata used in the Liberty, and Liberty-enabled clients profiles. The following sections provide more detailed information on Liberty ID-WSF components: - 4.1 Liberty ID-WSF Client Profiles Specification A client in the Liberty is something that uses services from the network. It can be a physical device such as a mobile telephone or software such as web browser. A client is associated with a network identity and usually does not have a fixed IP address, may be behind firewall, and not a HTTP server. Due to the specification of ID-WSF, any party can act as a Web Service Consumer (WSC), an entity that uses the service, or Web Service Provider (WSP), an entity that provides the service to another entity. This includes the client as well. A client can act as a Web Service Consumer, Web Service Provider, or Discovery Service. Acting as such a service, a client may have to expose some information to another party in order to do the work. For example a client acting as a WSP has to expose its metadata and ProviderID to WSC to use to construct a request to them. This information makes the client traceable. Therefore, exposing such information should be avoided as much as possible to protect client s privacy. A way to do this is to use message level confidentiality protection with different key for different party. Although Liberty Alliance is aimed to run over HTTP-protocol, there are also some clients that do not run over HTTP protocol. These clients connect to servers that are not HTTP server, for example instant messaging, e-mail, and newsgroup client. Sometime these servers may need to act as a WSC for some reason. In that case, non- HTTP-client must also be able to process Liberty messages. 4.2 Liberty ID-WSF Security Mechanisms Because the Liberty is about trusting in each others within the circle of trust, security and privacy is something very important to concern. When requesting for a service, a message has to be sent through out the network from the sender to the receiver. Threats are possible between the way from the sender to the receiver. For example, someone stoles the message and try to open it. To be prevented from these threats two mechanisms are provided. The first one it called Peer Entity Authentication. This mechanism makes sure that the sender and/or the receiver are really the real sender and/or receiver. This can be done by X.509 certificate. X.509 certificate is based on public/private key 11

architecture. There are two types of authentications possible, which are one way authentication and two way authentication. In one way authentication the sender encrypts the message with the receiver s public key and the receiver has to use his private key, which only he knows, to decrypt it. This shows that the receiver is really himself. In two way authentication, both sender and receiver have to authenticate themselves. The sender signs the message with his private key and the receiver s public key, and then the receiver decrypts the message with his private key and the sender s public key. This can confirm that both the sender and the receiver are the real ones. Another one is called Message Authentication. This mechanism makes sure of the confidentiality and integrity of the message rather than those who send and receive it. This can be done by having the sender encrypts the message with a symmetric key and sends that key and the message to the receiver. Symmetric key means the same key is used for both encryption and decryption. When the receiver receives the message he extracts the key from the message. The receiver has to make sure that the key received is really provided by the sender before he decrypts the message with that key. This can be done by X.509 certificate or SAML assertion. There are many cases that message sender and the entity that requires the service are different entities. An entity might act as a proxy asking for the service for another entity. In this case, whether to provide the service to the sender or not depends on the policies and the service provider. Such policies are called Access Control Policies. This policies control the authorization of resources. Access control policies are rules on providing access to resources. The entity that enforces the policies is called Policy Enforcement Point (PEP). In most case PEP is implemented at identity-based service because the service represents user s resources. The entity that made the decision regarding the policies is called Policy Decision Point (PDP) and does not has to be the same entity with PEP, that is, PEP can let another entity made the decision whether it should provide the service to some entity or not. In order to make the decision, more information regarding the authentication may be required. For example, authenticating with only username and password may not be enough for using money transfer service. This information is called Authentication Context. Sometimes user may want to receive a service anonymously, this can be done by encrypting user s name identifier. Name identifier can use to indicate a user, encrypting it provide anonymity and privacy to user. 4.3 Liberty ID-WSF Discovery Service Discovery Service (DS) is used for finding resources of an identity. A resource is either data of an identity or service acting for the benefit of an identity, e.g. user profile or digital wallet. An entity that wants to find a resource asks the discovery service about the resource it wants to know and the discovery service will answer with the location of the resource asked. In most case the discovery service is the same entity with the identity provider. The location of the discovery service is usually sent to the service provider by the identity provider during the login of the user. The user has his identity services such as personal profile service and digital wallet service 12

hosted at the discovery service at his identity provider. Personal information of the user is usually not provided by the identity provider. Therefore when a service provider wants more information about a user, e.g. user s date of birth, it asks the discovery service (at the identity provider) for the location of the service needed, e.g. location of personal profile service for asking about user s date of birth. Figure 4 shows the use of discovery service User Agent 1 6 Service Provider 5 4 3 2 Digital Wallet Service Discovery Service/Identity Provider Figure 4: Discovery Service Example 1. A user agent sends a request to a service provider asking for a service. 2. The service provider needs more information about the financial in user s digital wallet but it does not know where the digital wallet of the user is. Therefore it acts as a web service consumer asking for the location of the digital wallet service from a discovery service. 3. The discovery service, hosted with the same entity with identity provider, sends back the location of the digital wallet service. 4. The service provider now knows the location of the digital wallet service therefore sends a request asking for information about user s financial to the digital wallet service. 5. The digital wallet service sends the user s financial information back to the service provider. 6. The service provider now can provide the service to the user agent. A service instance is a physical instance of a service hosted at some provider and is identifiable by a URI. A service instance may serve many resources and a resource may be associated with many service instances, therefore the relationship between the two is many-to-many relationship, e.g. an instance of profile service provider serves many profiles. The relationship between a resource and a service instance is defined as resource offering. 13

<ResourceOffering> - <ResourceID>http://profile-provider.com/profiles/1234 - <ServiceInstance> - <ServiceType>profile - <ProviderID>http://profile-provider.com/ - </ResourceOffering> Figure 5: Structure of a Resource Offering Resource offerings are hosted with a discovery service. The ResourceID is a URI indicating the location of the service instance. ServiceType is the type of the service instance. Please note that the real service type is a URI that defines the type of the service, e.g. urn:liberty:disco:2003-08 for discovery service and urn:liberty:id-sispp:2003-08 for personal profile service. The service type in Figure 5 is only assumed for understandability. ProviderID is the URI of the provider of the service instance. A discovery service is simply a repository of resource offerings. Each resource offering registered with a discovery service will have an entryid that is unique in that discovery service. Discovery service has two operations: - DiscoveryLookup and DiscoveryUpdate. Discovery Service - <entryid> <ResourceOffering><ResourceID><ServiceType> </ResourceOffering> - <entryid> <ResourceOffering><ResourceID><ServiceType> </ResourceOffering > - <entryid> <ResourceOffering><ResourceID><ServiceType> </ResourceOffering > -.. Figure 6: Structure of a Discovery Service DiscoveryLookup operation is the operation in which queries can be made in order to find resources. A requester made a <Query> containing RequestedServiceType to a discovery service. The discovery service will find the resource offering matching the service type given. Then a <QueryResponse> together with a set of resource offerings with their entryids will be returned as a result. Multiple resource offerings for one requested type is possible because a user many have more than one service instance of one type. For example a user has two personal profiles, one hosted with his company and another hosted with a free personal profile service. A query can also come without any requested service type. This means that all resource offering available is requested. The result of this kind of query is according to the security policies. 14

3. Request to the given ResourceID extracted from <QueryResponse> Service Provider Profile Service 1. <Query> with RequestedServiceType 2. <QueryResponse> with ResourceOffering(s) Discovery Service Figure 7: Discovery Service Lookup The DiscoveryLookup can provide some security by returning an encrypted ResourceID instead of normal ResourceID. The encryption may occur because of the policy the discover service has. The decision whether to encrypt the ResourceID or not is depends on the discovery service, not the service instance that hosts the resource. The DiscoveryLookup can also support proxy resource offering for a given service type. A proxy resource offering is a resource offering that proxy all registered resource offerings with the same service type. Only one proxy resource offering is allowed for one service type. The result returned for a query of the type given in a proxy resource offering is depending on the identities of the requester and the provider of proxy resource offering. If the identity of the requester is not the same with the proxy resource offering provider, then a proxy resource offering will be returned. But if the identities of both are the same, the resource offering of the specified service type will be returned and also the proxy resource offering. DiscoveryUpdate is the operation used for inserting a new resource offering to and removing an existing resource offering from a discovery service. The update operation can be issued by <Modify> element. There are two types of Modify elements: - Insert and Remove. No Update is specified therefore an update operation must be performed by removing the existing entry and inserting a new one. When an entry comes with proxyforservicetype attribute, it is specified that this resource offering is a proxy. After modifying an entry, a ModifyResponse is returned with the status of the modification whether it succeeded or not. 4.4 Liberty ID-WSF Interaction Service Sometimes an identity service may need to contact resource owner for some more information such as getting permission for a specific data. An interaction service is used by identity services for contacting resource owners. There are three ways that a web service provider can contact the resource owner:- 1) The resource owner is browsing a service provider. The service provider, acting as a web service consumer requesting for a service as an identity provider, redirects the resource owner that is visiting it to an identity provider, which is acting as web service provider. 15

2) The resource owner is browsing a service provider. The service provider presents the question to the user for the identity provider. The service provider acts as an interaction service for the identity provider. 3) In this case, the resource owner is not browsing any service at all but the identity service need to communicate with the resource owner for some reason. For example, when an invoice comes and need to be authorized. The identity provider checks from a Discovery Service to find an Interaction Service available for the resource owner to pose some questions to the resource owner. The first case is done with the Redirect Request protocol and the last two cases are done with Interaction Service. Redirect Request protocol is a protocol used to redirect a user from a web service consumer to a web service provider. The web service provider will present user questions regarding the information it needs. After receiving the answers, it will redirect the user back to the web service consumer. Now the web service provider will have enough information to provide service to web service consumer. Interaction Service (IS) is used when an entity want to interacting with the users, e.g. asking question or permission. It is in the middle between user and an entity that want to ask question to the user. What interaction service do is receive the question from the entity, presents the question to the user, get the answer, and forward the answer back to the entity. Interaction service knows about user s preference such as language and device user is using in the interaction, therefore it can format the questions to user in the way that fit best with user s preference. In case two above, the service provider will provide interaction service to the identity provider. The identity provider sends a request to IS provider containing questions and some preferences relevant to displaying a form such as language preferred. IS provider then try its best to present the questions to the user. The user enters the answers to IS provider. IS provider then send the answers back to the web service provider. An IS can also be discovered from a Discovery Service, e.g. in case three above. The IS that is registered with a discovery service is believed that it can contact user at any time. E.g. By using instant messaging or WAP Push. Since interaction service acts as a medium between an identity provider and a user, it is needed and the interaction service is trusted from both. Because there is no way to proof that the user is really is the user or the answers come from the actual user. 4.5 Liberty ID-WSF Data Service Template Data Service is the template for the service that will provide data to other entities. An entity can ask for data from a data service or modify data hosted at the data service. This specification specifies the template that a data service that will be implemented over the Liberty ID-WSF framework should follow. A data service in this template is a web service that stores user s data and provides the ability to update it. This specification is aimed to enable the ability to querying and modifying data attributes of a user from a data service. This specification has three main parts that are: - data model, protocol, and a check list for the service that will implement this specification. 16

The data model provide template for defining common attributes and type definitions in XML. The XML schema defines the data and the data structure for communication between different entities. Normally the data structure is in tree hierarchy with one root node. Once the data attribute has been published in a specification, it can not be changed. The message interface defines protocols for exchanging data. There are two types of protocol that are querying data protocol and modifying data protocol. The messages of these protocols will be sent within SOAP body. In querying data protocol, two types of queries are available. The first one is to query upon current data and the second one is to query upon the changed data only. These two kinds of queries can be in the same message. After querying some data, some response must be returned. The query response can have three things in it: the requested data according to the query, a status code, and a time stamp. Access control policies must be checked before returning a data to the requester. The modifying data protocol is used to add new data, change the values of the data, or remove the data. In the <Modify> element that is used to request to modify a data, first it must select the data that it wants to modify. Then it can add new data, modify the value of the data, or remove the data depends on the element presented after <Modify> element. After modifying data, a response must be sent with the status of the modification whether it successes or not. 17

5. Liberty Identity Services Interface Specifications (ID-SIS) Liberty Identity Services Interface (ID-SIS) specifies the actual services that will be used by users, such as profile service, calendar service, contact book service, weather report services, etc. The Liberty ID-SIS is build upon the Liberty Web Services Framework using the service provided by ID-WSF. This part of the Liberty is now on going. Currently there are only two services available, which are Personal Profile Service (ID-SIS-PP) and Employee Profile Service (ID-SIS-EP). 5.1 Liberty ID-SIS Personal Profile Service Personal Profile Service is an identity service serves as user personal profile. That is, it holds personal information of the user. A profile is structured as a container containing attributes. Attributes express user data. Container can be hierarchy that is an element containing in a container can be either an actual attribute or another container. Therefore, several levels of containers are possible. Figure 8 shows personal profile data structure:- Figure 8: Top Level Personal Profile Structure The Liberty ID-SIS-PP may seem like data storage, but in fact it is a process that handles data query and responses back the result. Its function is similar to a database management system that is giving a keyword it will return back data matched the keyword given. ID-SIS-PP is designed to be general, which by mean of having only general attributes that can be used in any context such as legal name, gender, date of birth, etc, so that it can be used in any activity. A user can have more then one profile, 18

for example one work profile and one private profile. These two profiles can be with the same or different identity providers and may have the same attributes but not the same value. These two profiles can also be synchronized with each others but do not have to. Besides there are many situations that synchronization is not needed. The user with more than one profile can choose which profile to be used in which activity. This function helps user to control over his data distribution. Privacy of user data is also a major concern. Access control policies are used to protect user data privacy. Some attributes are strictly controlled as it can be used as formal identification, e.g. date of birth, full legal name, etc. Data format in the specification is defined with XML but the actual data does not have to be stored in XML. The data can be stored in database or else and be formatted as XML only when needed to be used in the Liberty ID-SIS-PP service. 5.2 Liberty ID-SIS Employee Profile Service Employee Profile Service is very similar to Personal Profile Service. The only main difference is the attributes presented in the profile. Because Employee Profile Service is aimed to be used by companies to save their employee information, the attributes presented in Employee Profile are related to jobs function, for example EmployeeID, EmployeeStatus, JobStartDate, etc. 19

6. User Experience Example Joe signed on at his identity provider and then goes to a community service wanting to find new friends. Joe has never federated his identity at the community website with his identity provider before. He decides to have both identities federated. Community Service 5, 7 6, 8 Joe s User Agent 2, 4 1, 3 Identity Provider/ Discovery Service Figure 9: User Experience Example - Login 1. Joe s user agent issues a sign in request <AuthnRequest> to his identity provider. 2. The identity provider authenticates Joe and asks him weather he wants his identity to be able to federate or not. 3. Joe says ok, he wants this identity to be able to federate. 4. The identity provider sends <AuthnResponse> back to Joe. 5. Joe goes to community website and sign in using his local identity. 6. The community service notice that Joe has been authenticated with an identity provider within its circle of trust. It asks Joe if he wants to federate his identity at the community service with the identity at the identity provider or not. 7. Joe says ok, the federation occurs. 8. The community service provides the service to Joe as usual. Later Joe moves to an online book store service which he already has his identity federated with this service. He found an interesting book and he wants to buy. Joe 1, 7 Book Store/ 2 Interaction service 6, 10 3 5, 9 4, 8 Identity Provider/ Discovery Service Personal Profile Service Figure 10: User Experience Example Using the Service 1. Joe sends request on buying book to Book store with HTTP Request and <AuthnResponse> from previous 2. Book store needs more information on Joe s real name and address. It needs to ask Joe s personal profile service but it does not know where it is. Therefore it 20

send a <Query> asking for the <ResourceID> of personal profile service to the discovery service at Joe s identity provider. 3. Discovery Service answers back <QueryResponse> with ResourceID of personal profile service. 4. Book Store sends <Query> asking for Joe s real name and address to personal profile service at the URI extracted from <QueryResponse> and also tells that Joe is visiting it and it is ready to present question to Joe. (It s going to act as an interaction service.) 5. Personal profile service needs Joe s permission to reveal Joe s real name and address to the book store. It sends < InteractionRequest> containing question asking for permission to the book store that. 6. Book store presents the question to Joe. 7. Joe answers the question. 8. Book store sends back the <InteractionResponse> with the answer of the question to personal profile service 9. Now that personal profile service has Joe s permission it sends <QueryResponse> with Joe s real name and address back to the book store 10. The book store now can continue selling book to Joe After buying the book Joe log out from the book store and goes to work. Book Store 5 2 Identity Provider 6 1 3 4 Joe Community Service Figure 11: User Experience Example Logout 1. Joe press sign out button at the book store website 2. The book store issues <LogoutRequest> to Joe s identity provider. 3. Joe s identity provider send <LogoutRequest> to other services that was authenticated by it in the same session with the book store. There is only one service that is community service. 4. Community service process Joe s log out and send <LogoutResponse> back to Joe s identity provider saying that it has successfully logged Joe out. 5. Joe s identity provider sends <LogoutResponse> back to the bookstore saying that it has successfully logged Joe out. 6. The book store has logged Joe out and displays a web page showing that Joe has logged out successfully. 21

Conclusion The Liberty Alliance project provides specification of identities federation of users within a circle of trust, single sign-on mechanism, basic services needed for using federated identity, and services that use federated identity framework. The Liberty is separated into phases. With the Liberty phase one, a user can has his identities federated over a network and can use the single sign-on mechanism. With the Liberty phase two, a service can discover about services, be discovered, interact with users, and querying upon data of users. The Liberty Alliance is based on existing standards and does not bounded with any specific devices, operating systems, or network infrastructures, therefore easy to implement. Security and privacy are in major concern. Encryption, authentication, and access control policies are used to protect user s privacy and security. With Liberty Alliance enabled systems, user experiences become easier and more convenient and also lead to many business benefits for companies who implemented it. 22

References Liberty Alliance Specifications, http://www.projectliberty.org/specs/index.html Liberty Alliance White Papers, http://www.projectliberty.org/resources/whitepapers/index.html Liberty Alliance Frequently Asked Questions, http://www.projectliberty.org/about/faq.html Microsoft.NET Passport, http://www.passport.net/ 23