Identity management is a growing Web trend with. A SWIFT Take COVER FEATURE. Virtual identities and identifiers

Transcription

1 COVER FEATURE A SWIFT Take on Identity Management Gabriel López, Óscar Cánovas, and Antonio F. Gómez-Skarmeta, University of Murcia, Spain Joao Girao, NEC Laboratories Europe, Germany A proposed identity management framework provides privacy protection, by means of virtual identities, and cross-layer single sign-on for users who subscribe to multiple service and identity s. Identity management is a growing Web trend with the goal of simplifying account management from a user s perspective. In addition, idm seeks to seamlessly maintain the user s privacy while accessing different Web services. The Web is idm s greatest strength, promoting rapid proliferation of the technology, but also its greatest weakness, in that idm mechanisms are not widely used in telecommunication networks or for more traditional services such as IP telephony or television. A single framework is crucial to the successful integrated deployment of idm on a global scale. Recent research activities, such as those of the EU s Secure Widespread Identities for Telecommunications (SWIFT; and PrimeLife ( eu) projects, and efforts by the International Telecommunication Union (ITU) and the World Wide Web Consortium (W3C), aim at a more consistent view of idm across the various layers and domains. These approaches consider Web development but focus on network integration aspects. Ultimately, users should be able to profit from pervasive use of this technology when accessing the network or an application service. We propose an idm framework that offers cross-layer single sign-on (SSO) mechanisms for users who have some type of subscription with several service and identity s. It also protects privacy by preventing unauthorized parties from linking steps or actions with the same user identifiers, enforcing privacy rules at different s, and supporting the user s autonomy in disclosing attributes. The framework provides the functionality to merge existing user subscriptions and generate a more general virtual identity the union of one or more attributes from one or more identity s. Users can create several virtual identities using a subset of attributes for each identity to which they subscribe. The concept of virtual identity is the key to creating federations of resources and an SSO mechanism across different idm systems. Users can access multiple services by referencing their virtual identity via a virtual identifier (VID). The main challenge for developers is how this additional level of indirection affects idm system elements and the requirements on newly needed components. Virtual identities and identifiers Nowadays many users have numerous accounts with different service s (SPs) on the Internet that play 46 computer Published by the IEEE Computer Society /09/$ IEEE

2 the role of authentication s or attribute s. Each account typically contains authentication credentials such as a login/password or certificate as well as a set of user attributes such as entitlement, age, sex, and grade, and these depend on the kind of : whether it provides network access, content, and so on. credentials are private between the authentication and user and must never be revealed to third parties, but attribute s can share user attributes with several SPs. Our proposed framework lets users define profiles, known as virtual identities, that aggregate authentication credentials and attributes from different identity s. 1,2 Users reference each profile by means of a VID when accessing a target service. As Figure 1 shows, a virtual identity references one authentication ID (AuthN ID), the identifier by which an authentication recognizes a particular authentication subscription, and one or more attribute IDs (Attr IDs) held by different attribute s. For example, Alice might define a virtual identity that references her home network s AuthN ID (alice@home.com). At the same time, it can hold the attribute connection_type=premium held by that attribute and the attribute VID role=vipclient held by a different attribute with which Alice has another account. Several VIDs can reference one virtual identity. Each VID includes information about the identity the domain where the VID was defined and data to select the right virtual identity within that domain. For example, alice@.org may represent a VID from.org that points to the virtual identity defined by Alice. For privacy reasons, when a user requests access to some service, the system will replace the virtual identity pointer with an encrypted identifier or artifact, and will only disclose the ID to SPs. Framework elements Figure 2 shows the relationships among the framework s five basic elements: authentication s, attribute s, identity s, SPs, and users. These elements can be seen as roles that one or more parties play, depending on the business model. VID Virtual identity pointer Virtual identity AuthN ID Attr ID 1 Attr ID 2 Attribute Attribute Credentials Attributes Attributes Figure 1. Virtual identity content. A virtual identity references one authentication ID and one or more attributes held by different attribute s. User Attr ID VID AuthN ID Attribute Pseudonym AttrP-IA Identity Pseudonym AuthNP-IA Pseudonym SP-IA Figure 2. Relationships among framework elements. These elements can be seen as roles that one or more parties play, depending on the business model. To prevent different s from correlating VIDs AuthN IDs, and Attr IDs, the framework uses pseudonyms established between the various actors. Identity s As identity s can support different functions depending on the services they provide, we distinguish authentication s, attribute s, and identity s. s. These prove the identity of users. Therefore, users must have a previous subscription with a and share some kind of authentication credentials, including an AuthN ID, to enable authentication. The framework does not impose any requirements on the authentication method used. Attribute s. Users may also have a subscription with one or more attribute s to maintain attribute data. The information these s manage can be general-purpose or relate to specific services, and may be filtered by user-specified privacy policies. Identity s. Users can generate or modify some properties of their profiles using one or several identity s, which are responsible for managing user MAY

3 cover FEATURE Access with SWIFT SSO Access with SP session status SWIFT intiation User authenticates with authentication SWIFT SSO User creates SWIFT SSO token to access service SWIFT SSO token SP session status Initial access only with VID User invoices service User gets access to service Figure 3. Framework s. The s are associated with user operations and result from the different interactions among the elements. profiles, VIDs, and SSO mechanisms and s. They also deliver the information contained in the profiles and enforce the privacy rules that users specify for a given operation. Identity s can maintain different federation agreements with authentication and attribute s to determine which information is available to build virtual identities and the necessary requirements to obtain the data. Aggregators can either be trusted third parties, able to generate security assessments that any other entity in the system must recognize, or they may serve as proxies of security s generated by the participating s. In this article, we focus on the first trust model. s SPs protect the resources being shared across a federation. They use authentication s, attribute s, or identity s to verify the identifiers (including VIDs) that users present and to retrieve the attributes needed to make an authorization decision. Users A user is an entity who has at least one subscription with an authentication or attribute. In relation to that, the user has an identifier and a set of attributes associated with that identifier. For authentication reasons, the user must know some authentication credentials. VIDs provide users with three main advantages: privacy, SSO, and life-cycle management. Privacy. To prevent different s from correlating VIDs, AuthN IDs, and Attr IDs, the framework uses pseudonyms 3 established between the various actors. A pseudonym is a privacy-preserving identifier assigned by a framework element to identify a user to a given relying party for an extended period of time. Depending on its use, the pseudonym can be transient or permanent. Figure 2 depicts three pseudonyms. The authentication and identity initially establish AuthNP-IA when the user creates the virtual identity; it references the AuthN ID. The attribute and identity use AttrP-IA to exchange user attributes. The SP and identity use SP-IA when they need to exchange information, including authentication data, about the user. To protect privacy, the framework also conceals VIDs from SPs, ensuring that only users and identity s have knowledge of a specific VID. Further, users can specify which attributes to disclose to specific s. SSO. Once an authentication has authenticated a user, the user can access any protected resource if he or she has the appropriate attributes and the authentication context provides some level of assurance. 4 Toward that end, the authentication must generate an authentication based on the VID and deliver it to the user. This certifies that the user behind the VID was successfully authenticated. Users rely on this to generate different SWIFT SSO tokens to access SPs. Life-cycle management. Users can manage several details of their VIDs including related profiles, activation, and revocation. Framework s Our framework includes several s, shown in Figure 3, associated with user operations and resulting from the different interactions among the elements. Users send a SWIFT initiation to access a protected service when they are not yet authenticated. This specifies only the VID but uses an artifact that is only meaningful to the identity, instead of the virtual identity pointer. It also includes the ID. SPs contact the identity, which protects user privacy and provides SSO to the VID being used to access the service. After a VID has been initiated, the user obtains a SWIFT SSO, which verifies that the user controls a specific VID. This is the framework s core method for providing SSO as long as this is valid, users need not authenticate again. Once the user receives an SSO, the system should never reveal it to any entity. 48 computer

4 User Identity SWIFT initiation request SWIFT initiation request Redirect to identity request Redirect to authentication request for SP process between user and authentication for SP SWIFT SSO for User authentication HTTPS HTTPS HTTPS Figure 4. SP-initiated authentication for Web services. Once they have been authenticated, users create SWIFT SSO tokens to request access to specific services. Similar to the initiation, an SSO token includes an artifact and the associated domain. However, in this case the artifact not only references the virtual identity but also the fact that the user has been previously authenticated. The artifact also includes some information about the SP to identify the intended relying party as well as a reference to the SWIFT SSO, such as a hash value. Finally, once an SP authorizes the user to access the specified resource, it provides an SP session status to the user to prevent further verifications during the specified validity period. This depends on the SP and is not part of the framework. In Web environments, it is usually implemented by means of cookies. 5 Use Cases Three SWIFT use cases demonstrate the framework s functionality. The first two involve an authentication step to gain access to a service (Web and network) offered by a SWIFT-enabled SP. The third includes the SSO process and authorization steps based on user attributes. SP-initiated authentication for Web services Alice is browsing the Internet and wants to access a protected Web service but wishes to keep her privacy. As Figure 4 shows, when she tries to access the service, she must first select one of her VIDs. In doing so, she creates a SWIFT initiation that includes an artifact a protected pointer to her virtual identity and the ID. The SP receives the access request and uses a name resolution service to locate the identity. For example, it may use the Domain Name System (DNS) if the ID is a fully qualified domain name (FQDN). The system then redirects Alice to the to determine the authentication, where she will be redirected, based on the virtual identity managed by the, MAY

5 cover FEATURE User Identity SWIFT initiation domain request domain response domain Redirect to authentication request process between user and authentication query for User authentication for SP for SP SWIFT SSO SWIFT SSO EAP HTTPS SAML PEAP RADIUS/EAP Figure 5. SP-initiated authentication for network roaming. SP-initiated authentication for roaming users Suppose that Alice must be authenticated before obtaining a network connection. Because she does not have network connectivity, the only communication channel available is the one to the authentication for exto complete the authentication process. Only Alice and the observe the VID, and the does not see her authentication credentials. Once authenticated, the system then redirects Alice to the with an authentication for proving that she has been successfully authenticated. This also contains the pseudonym AuthNP-IA, which allows the to verify the association between the VID and AuthN ID without actually knowing the latter. The then redirects Alice to the SP. The redirect message transports the SSO, which she stored to generate future SSO tokens. It also includes the authentication for SP, which the SP uses to verify that she was successfully authenticated. The subject of this contains the pseudonym SP-IA. Once the SP grants access to Alice, it also provides her with a SP session status for example, an HTTP cookie for session maintenance. The SP knows that a trusted has authenticated Alice, but it does not know which one or her credentials. Moreover, the SP can use the pseudonym SP-IA to request more user attributes from the identity without knowing their exact origin. 50 computer

6 User Identity Access with SP session status SP session status Access with SWIFT SSO SWIFT SSO token SWIFT SSO token for SP Attribute request Attribute request Pseudonym AttrP-IA Access response SP session status Authorization process Attribute response Attributes Attribute response Attributes Attribute retrieval Figure 6. access and single sign on (SSO). ample an Extensible Protocol (EAP) channel through IEEE 802.1X. When Alice tries to access the network, as Figure 5 shows, she creates a SWIFT initiation based on a particular VID, as described above. The discovers the authentication that should be used to perform the authentication process and sends back a response to the SP that includes the authentication domain. The SP then sends an authentication request message to the authentication that includes anonymous@ domain as Alice s identity and the ID. The authentication performs the previously described authentication process. After a successful authentication, the authentication sends a query containing an authentication for to verify that Alice has been authenticated. The response message from the identity includes the SWIFT SSO, which the system forwards to her using the EAP channel, and the authentication for SP, which it forwards to the SP. Encryption mechanisms prevent disclosure of information contained in both s to the authentication. In this scenario, the SP sends an anonymous access request to the authentication, and Alice s private credentials, shared with the authentication, are hidden from both the and SP. Moreover, at the end of the process, she obtains a new SWIFT SSO that can be used later to gain access, without reauthentication, to other Web services, Voice over Internet Protocol (VoIP), and so on. access and SSO Now suppose that, once Alice has been authenticated, she holds the required information to access a new service without the need of a new authentication process. As Figure 6 shows, she can exploit the framework s SSO mechanisms in two ways. MAY

7 cover FEATURE Alice can share an active session with the SP by presenting the SP session status together with a service request message. The SP would then look up the user session in its internal database and determine that she has a valid session and thus there is no need to reauthenticate her. Alternatively, if Alice does not have a valid SP session status but does have a valid SWIFT SSO, she can generate a SWIFT SSO token specific to that SP. When the SP receives the token, it communicates with the identity to verify that Alice was properly authenticated and to obtain the pseudonym SP-IA. To ensure that the can verify Alice as the token s creator, the artifact references the SWIFT SSO. Once the SP has determined that it does not have to authenticate Alice again, it may initiate an authorization process and requests the identity to provide attributes held by other attribute s such as her age, entitlement, and so on to make the access control decision. When the queries the attribute for these attributes, the latter uses an attribute release policy, specified by Alice, to decide whether to reveal them. The SP accordingly sends her an access response message, perhaps with an updated SP session status to further access the service. Obtaining anonymous access to the SP, by means of a previously SWIFT SSO token, makes it difficult for third parties to correlate data because the artifact included in the token differs for each access request. Our framework provides cross-layer SSO, ranging from the network to high-level applications. The ITU Telecommunication Standardization Sector s Focus Group on Identity Management ( fgidm) defined a main gap in cross-layer SSO that is now bridged by the SWIFT SSO obtained during the network access process and then used to derive the SSO tokens enabling access to higher-level services. The use cases assume that the identity is the central trusted entity. On the one hand, it avoids the need for all involved service, authentication, and attribute s to establish trust relationships, thus avoiding contract deals usually assigned to the Security Assertion Markup Language (SAML). 3 On the other hand, the could be seen as a central point of failure. However, we envision scenarios based on a distributed trust model, where SPs could obtain authentication and attribute s directly from the identity s. In this case, the would act as a discovery and proxy service. Nevertheless, both models can be deployed using the proposed framework. We continue to develop these models, and future work calls for a detailed security and privacy analysis. Although our framework is generic, several existing technologies could be used to instantiate part of the proposed use cases: SAML 2.0 profiles and the Extensible Access Control Markup Language (XACML) 6 could be the basis for representing the SWIFT authentication and attribute s, and standard access control policies; proposals like XRI Data Interchange (XDI) 7 could be used to provide standard resource identifiers and data exchange formats for name resolution protocols; and projects such as Deploying Authorization Mechanisms for Federated s in the eduroam Architecture (DAMe) 8 are defining SSO for cross-layer authentication and authorization. Instantiation details such as transport protocols or security algorithms will depend on the specific scenario: network, Web, VoIP, and so on. SAML 2.0 also defines IdP proxy mechanisms. We have extended this to not only include authentication and attribute requests but also to consider the impact of VID management, privacy, security, and trust. Because our framework assumes different trust associations, we cannot determine a priori the recipient of authentication or attribute trusts. A client-side implementation of the framework is theoretically possible. For example, Windows CardSpace ( provides a client-side idm discovery mechanism. However, CardSpace would assume that the client takes the identity role and thus lacks flexibility because the role is bound to the device and cannot offer network personalization. Further, it does not fit well with our trust model because SPs can only choose to trust the authentication/ attribute or user. Acknowledgments This work was partially funded by SWIFT (FP7, Grant Number ). The authors also thank the Funding Program for Research Groups of Excellence (04552/GERM/06) established by Fundación Séneca. References 1. 3GPP TS : 3GPP Generic User Profile (GUP) Requirements; Architecture (Stage 2), release 8, 16 Dec. 2008, 3GPP; 2. A. Sarma et al., Virtual Identity Framework for Telecom Infrastructures, Wireless Personal Comm., June 2008, pp OASIS Security s Technical Committee, Security Assertion Markup Language (SAML) V2.0 Technical Overview, draft 2, 25 Mar. 2008; security/saml/post2.0/sstc-saml-tech-overview-2.0-cd-02. html. 52 computer

8 4. W.E. Burr et al., Electronic Guideline, special publication , 8 Dec. 2008, NIST; csrc.nist.gov/publications/drafts/ rev1/sp Rev1_Dec2008.pdf. 5. D. Kristol and L. Montulli, HTTP State Management Mechanism, IETF RFC 2965, Oct. 2000; rfc2965.txt. 6. extensible Access Control Markup Language (XACML) Version 2.0, 1 Feb. 2005, OASIS; xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf. 7. D. Reed and G. Strongin, The Dataweb: An Introduction to XDI, v2, white paper, 12 Apr. 2004, OASIS; www. oasis-open.org/committees/download.php/6434/wd-xdiintro-white-paper pdf. 8. Ó. Cánovas et al., Deploying Authorization Mechanisms for Federated s in EDUROAM Architecture (DAME), Internet Research, vol. 17, no. 5, 2007, pp Gabriel López is an assistant professor in the Department of Information and Communications Engineering at the University of Murcia, Spain. His research interests include network security, public-key infrastructure (PKI), and identity management. López received a PhD in computer science from the University of Murcia. Contact him at gabilm@um.es. Óscar Cánovas is an associate professor in the Department of Computer Engineering at the University of Murcia. His research interests include PKI, authorization management systems, and network access services. Canovas received a PhD in computer science from the University of Murcia. Contact him at ocanovas@um.es. Antonio F. Gómez-Skarmeta is an associate professor in the Department of Information and Communications Engineering at the University of Murcia. His research interests include distributed artificial intelligence and computer network security. Gómez-Skarmeta received a PhD in computer science from the University of Murcia. He is a member of IEEE. Contact him at skarmeta@um.es. Joao Girao is a senior researcher in the Ubiquitous Secure Computing group at NEC Laboratories Europe, Heidelberg, Germany, where he is responsible for technical coordination in the identity management area. His research interests include security for networks and services and identity management. Girao received a diploma in computer and telematics engineering from the University of Aveiro, Portugal. He is a member of the IEEE and the ACM. Contact him at joao.girao@nw.neclab.eu. MAY