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

Transcription

1 Title: A Client Middleware for Token-Based Unified Single Sign On to edugain Sascha Neinert Computing Centre University of Stuttgart, Allmandring 30a, Stuttgart, Germany sascha.neinert@rus.uni-stuttgart.de Keywords Single Sign On, Identity Federation, eduroam, edugain, Identity Token Abstract This document presents a solution that offers a unified Single Sign On to users of the eduroam roaming infrastructure and of the GÉANT2 confederated authentication and authorization infrastructure, edugain. This is achieved by dedicated client middleware and a newly developed token-based profile for edugain. Introduction With Single Sign On (SSO), a user can be authenticated once and then access all resources and services he is entitled to, within one security domain. In an Identity Federation, a user can additionally access resources and services within any other security domain that is part of the federation s trust fabric. The main principle of a federation is to distinguish between providers of services and providers of identities. Thereby, a user can have one single virtual identity at home, and use this to access resources and services at other locations. Users accounts and attributes are managed at their trusted home institutions, in one place, and they are authenticated by their home institutions. The Service Providers have established agreements with the Identity Providers, trust their authentication and attribute information and base their authorization decisions on them. These authorization decisions decide whether or not the specific user can access a certain resource or service. A number of solutions for federated SSO have been developed or are already deployed. There are those for accessing web resources and web services, often based on the XML standard Security Assertion Markup Language (SAML). Other systems are focused on authentication for network resources, the Kerberos protocol being one important example. The presented approach is part of a federated Single Sign On for network resources, web resources and other service types. The first phase is authentication for network access performed via the eduroam [1] RADIUS infrastructure; it is described in [2]. This bootstraps a second phase that uses the acquired authentication information for accessing web resources and services. This second phase is a new tokenbased profile for edugain, the GÉANT2 Authorization and Authentication Infrastructure [3]. In the next section an overview of the proposed architecture for unified Single Sign On (usso) will be given. This architecture is based on identity tokens, managed by a new piece of client middleware as well as a new token-based profile for edugain. Next, related approaches for extending SSO middleware systems beyond browser-only will be shown, and their relation to the proposed approach will be explained. Finally, the implementation of the proposed approach will be presented and the concluding section will sum up what has been achieved and what work remains to be done. Overview of the Architecture This architecture for unified Single Sign On brings together two currently independent (con-)federation infrastructures, eduroam and edugain. Both are different in regard to the employed technologies: with 802.1X and EAP over RADIUS used in eduroam, and SAML over HTTP used in edugain. They also differ in the services they offer: network access at any visited institution, and access to web resources at some service provider anywhere. However, there are also two links as shown in figure 1: the user with his mobile device being one, and the Identity Provider (IdP) the other (the IdP could be a RADIUS connected to some data store, or a Shibboleth IdP connected possibly to the same data store).

2 Figure 1: unified SSO Overview As access to the network is a prerequisite to access any other resource or service, it is consequentially the first step. The eduroam infrastructure, which provides wireless network access for academic users roaming within Europe and beyond, is extended by components that generate an identity token at the home institution of a user and passes this token to the user during the last steps of the network authentication process. This identity token is called edutoken. The edutoken describes the fact that the user has been authenticated by a trusted entity of the federation and is to be used as a credential when accessing resources and services within that federation. The token contains information on, who has been authenticated, when the authentication was carried out, which method was used and who issued it. The format of the edutoken is SAML, as this is the native language of edugain. This standard is built to express such information in a flexible yet clearly defined manner. The edutoken consists of a signed SAML 1.1 [4] assertion containing one authentication statement. Optionally, an additional attribute statement can also be included. Token Manager For the encrypted storage of tokens and for making them available to be used for authentication when accessing resources and services, a new piece of client middleware is needed. This is called Token Manager. It receives the token coming from the eduroam authentication and provides a secure token store. The cookie store of the browser is not used for security reasons as well as the limitations of the user interface for handling this store s contents. The Token Manager can validate the edutoken, check that it has been digitally signed by a trusted authentication authority and that the token has not been modified and has a valid signature. Additionally, the Token Manager provides a graphical user interface enabling the end-user to manage his identity tokens and display their contents. The most important feature of the Token Manager is its interface that allows the tokens to be requested for token-based authentication to edugain. Profile for Token-based Authentication The edutoken is to be used for authentication of the user when he accesses a resource or service. This, for example, could be a simple website or a complex Grid service. The resource or service would be protected and some authentication would be enforced. edugain supports multiple authentication and authorization infrastructures (AAI), Shibboleth being one example. A user trying to access the service would be redirected by the responsible Service Provider (SP) to another entity acting as an Identity Provider (IdP). In the case of edugain, this is a remote Bridging Element (r-be). Usually the r-be would contact a home Bridging Element, possibly of another federation using another type of middleware. This would then talk in that federation s protocol and language to the user s home IdP. Now, this r-be is extended to support a new profile for token-based authentication. Figure 2 shows the sequence of messages for this new profile.

3 Figure 2: Profile for Authentication with the edutoken The user initially tries to access a resource or service at the SP. Then, as usual, a redirection occurs from the SP, optionally via a Where Are You From (WAYF) service, to the entity responsible for authentication in this case the extended r-be. This r-be sends a request for the token to the client. The request comes in the form of a signed JavaApplet, which is an active component to be executed within the user s browser. It requests the edutoken from the Token Manager via its interface. The available token is then send back in a reply to the r-be using the normal HTTP POST method. Any input of the user is not required during this process. The r-be then validates the edutoken to ensure that it has not been modified and that it comes from a trusted source within the (con-)federation. Next, a new assertion is generated in a format that the SP understands, which in the case of a Shibboleth SP is also SAML, though with specific restrictions concerning its age and audience. This assertion is sent to the SP. Upon successful authentication, the user is granted access. It is important to note that during this process, the user does not need to provide any credentials such as username and password just the token. Also, there is no need to contact the IdP of the home federation to request authentication. Related Work A number of related approaches exist that introduce a new piece of client middleware into the usual browseronly environments, each for different reasons. Three of these approaches are described as follows: SAML Enhanced Client SAML (Security Assertion Markup Language) is an OASIS standard that defines a format to express authentication and authorization information, the associated protocols and a number of profiles. The Enhanced Client or Proxy (ECP) Profile [5] specifies an entity that, in contrast to the more common Web SSO profile, has information about the Identity Provider (IdP) to be used. It could possibly be implemented as a browser plug-in. This obsoletes the discovery of the IdP, and thus requires less user interaction and the login process would appear more seamless to the end-user. The entity also supports a reversed HTTP binding for SOAP (PAOS). Thereby, a client that only can issue HTTP requests can use those to transport SOAP responses. The ECP capabilities are advertised in the HTTP header to a Service Provider (SP). PAOS is then used to initiate an AuthenticationRequest from the SP to the client. This then performs authentication at the IdP and responds with an AuthenticationResponse to the SP. One use case for an enhanced proxy would be a WAP gateway. The ECP profile would be an interesting alternative to the currently used profile if it was support by some of the more widely deployed software packages for federated AAI. It could be usso-enabled if modifications for receiving and processing the edutoken as a method of authentication were implemented. Liberty Advanced Client The Liberty Alliance [6] is a consortium of more than 100 commercial and also non-commercial members that developed several industrial standards for Identity Federation and identity-based web services. The Liberty

4 Advanced Client specification [7] is currently at draft status. It defines mechanisms by which so-called smart clients can consume and also provide web services whilst operating in disconnected mode. As these clients are active entities, they also have a ProviderID, although there are reasons for this ID not being unique. The client can be used for hoarding credentials, which are relatively long-lived assertions that were requested from an IdP. The client can advertise its capabilities using SAML 2.0 ECP and, during communication with some SP, use the available assertions for authentication. Benefits of such a client are: Firstly, the IdP need not be contacted - it may not be available or for reasons of privacy. Secondly, the assertions could be used as credentials for local applications e.g., a mail client. Finally, those assertions can be self-asserted ones if third party asserted identities are not required. Akogrimo IDToken Akogrimo (Access to Knowledge through the Grid in a Mobile Word) is an EC FP6 research project that developed combined services access across different layers [8] [9]. Its identity management infrastructure includes A4C (Authentication, Authorization, Accounting, Auditing, Charging) servers at the visited domains that are federated with SAML authorities at the home domains. During the network authentication phase, an IDToken is sent from the SAML authority to the user and stored on his mobile terminal. The IDToken is dynamic; besides a SAML Artifact it contains a serial number and a random number. Both are updated before each use of the IDToken and then it is digitally signed with the user s private key, to prevent replay attacks. The client middleware also provides a graphical user interface for selecting one of several identities, which can be registered in one or several Virtual Organizations. This approach provides cross-layer Single Sign On for network as well as Grid services in combination with multiple digital identities of one user. Such support for identities and attributes from multiple locations would be a valuable extension to the current usso prototype. This is also an example that clearly shows that basing the management of the identity tokens is not best situated within the browser if, for example, other transport protocols than HTTP are used or if other resources than only web-based ones are to be accessed. Implementation Details The proposed architecture has been implemented as a prototype and has been deployed in a test environment. All related middleware components are shown in figure 3. Each dashed box represents one hardware device and each solid box one software component. The arrows show which components communicates with each other. Figure 3: Middleware for usso In the following, all components are described. A more detailed description about the testbed and the performed validations is in [10]. Client Components The XSupplicant is the 802.1X supplicant of the Open1X project [11]. Version has been modified and extended by the University of Murcia to receive the edutoken inside an EAP TLV during the network authentication phase. The DameTokenManager is a stand-alone Java application for managing the edutoken(s). It provides a graphical user interface and allows the end-user to manage his token store. In the current implementation edutokens are stored as encrypted files, using the AES 128 algorithm. The token manager receives edutokens from the

5 modified XSupplicant and provides an interface allowing them to be requested when needed for authentication. This component is the link between the network authentication and the authentication for services. Firefox 2.0 is the browser used in this deployment for accessing any web resource. Sun s Java Runtime Environment is required for executing Java Applets within the browser. In the current deployment tests were performed using JRE 1.5. The DameTokenFetcher is a signed Java Applet. When the website that contains it is accessed, it is executed within the browser. It can request the edutoken from the DameTokenManager and send it using an HTTP POST to the DameTokenServlet. Server Components An unmodified Shibboleth 1.3 Service Provider was used for the performed tests. It is deployed on an Apache 2.0 HTTP Server. The apache web server enforces authentication via Shibboleth. The metadata of the Shibboleth SP contains an IDPSSODescriptor with the DameTokenServlet s URN, URL of the SSO Service and certificate information. The DameTokenServlet is a Java Servlet running on an Apache Tomcat 5.5. It is a modified and extended remote Bridging Element of the edugain infrastructure. The r-be currently modified is the one that connects to the Shibboleth [12] middleware. It can receive and validate edutokens, and send SAML assertions as from a Shibboleth Identity Provider towards the Shibboleth SP. The current implementation is based on edugain 0.6 that uses the opensaml libraries 1.2 and 2. Conclusion The presented approach links the authentication for network access, starting at OSI layer 2, to the authentication for services above OSI layer 4 and thereby enables a cross-layer, unified Single Sign On. Authentication for obtaining network access is performed via the infrastructure of eduroam, the European roaming confederation. A unified Single Sign On state is established that is valid for any resources within edugain, the European AAI that forms a confederation of existing national federations based on Shibboleth and other middleware. A homogenous IT infrastructure is not a requirement for the usso using the presented approach. Thanks to the use of the standardized Security Assertion Markup Language, bridging between several heterogeneous middlewares is markedly simplified. The developed components seamlessly interoperate with middleware for federated AAI, which is currently widely deployed and productively used within European academic environments and conforms to their requirements (defined in [13]). Unified Single Sign On is a feature that is mostly beneficial to the end-users. They use the specific authentication method only once, and are then signed on to the (con-)federation. This is more convenient and efficient but also more secure sensitive information has to be transmitted only once. Based on the idea of federated authentication and authorization, one virtual identity can suffice to access any resource within the federation, be that a local website or wireless network access in another country. In a user-centric approach as the presented one, the end-user can actively intervene in the process of authentication and the management of his virtual identity. The presented architecture and implementation will be further extended and refined in the future. Possibilities for interoperation with related approaches are expected to emerge. The validation for practical deployment as well as the application of this approach to recent service and Grid infrastructures is ongoing. Acknowledgements The results published in this paper were developed within the DAMe project [14], a sub project of the GÉANT2 joint research activity 5 that is co-funded by the European Commission within the Sixth R&D Framework Programme (FP6). The DAMe project is developed together with the University of Murcia (Spain), DFN (Germany), and RedIRIS (Spain). The author would like to thank all the partners involved in that project. References [1] eduroam Website, [2] Ó. Cánovas et al.: Deploying Authorization Mechanisms for Federated Services in eduroam (DAMe), Terena Networking Conference 2007, May 2007 [3] D. Lopez et al.: GÉANT2 Authorisation and Authentication Infrastructure (AAI) Architecture second edition, GÉANT2 Deliverable DJ5.2.2,2, April 2007 [4] E. Maler et al.: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1, OASIS Standard, September 2003 [5] J. Hughes et al.: Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, March 2005 [6] Liberty Alliance Project Website,

6 [7] C. P. Cahill et al.: Liberty ID-WSF Advanced Client Technologies Overview. Version , Liberty Alliance Project, August 2007 [8] J. Jähnert et al.: The Mobile Grid Reference Architecture, Akogrimo Deliverable D3.1.3, October 2006 [9] F. Solsvik et al.: Final Integrated Services Design and Implementation Report, Akogrimo Deliverable D4.2.3, December 2006 [10] Ó. Cánovas, M. Sánchez, G. López, R. del Campo, S. Neinert: usso Architecture, GÉANT2 Deliverable DJ5.3.2, to appear [11] Open1X.org Website, [12] Shibboleth Website, Internet2, [13] B. Kerver et al.: Documentation on GÉANT2 unified Single Sign-On (usso) Requirements, GÉANT2 Deliverable DJ5.3.1, February [14] DAMe Project Website, Vitae Sascha Neinert studied computer science at the University of Stuttgart, Germany where he received the degree Dipl.-Inf. (Sep/2004). He worked as a software engineer for a medium sized software company in a number of projects targeting the automotive industry. He started working for the Communication Systems group of the University of Stuttgart computer centre 'RUS' in Nov/2006. He was involved in the Nexus project where he developed a location-based application for small mobile devices. Currently he is working on the EU project DAMe in the GÉANT2 context on the topics attribute-based network authorization, cross-layer unified Single Sign On and federated Identity Management.