Bootstrapping a global SSO from network access control mechanisms

Bootstrapping a global SSO from network access control mechanisms Manuel Sánchez1 , Gabriel López1 , Óscar Cánovas2 , Antonio F. Gómez-Skarmeta1 1

Department of Information and Communications Engineering 2 Department of Computer Engineering University of Murcia, Spain {msc,gabilm,skarmeta}@dif.um.es {ocanovas}@ditec.um.es

Abstract. This paper presents the details of a Single Sign On proposal which takes advantage of previously deployed authentication mechanisms. The main goal is to establish a link between authentication methods at different levels in order to provide a seamless global SSO. Specifically, the users will be authenticated once, during the network access control phase. Next, having authenticated to get on to the network using 802.1X, that authentication will automatically fetch the necessary signed tokens so that there would be no need to repeat the login at the application layer. Therefore, the application level authentication would be bootstrapped from the network access. As we will see, this involves the generation of SAML signed tokens that will be obtained by the users using a PEAP channel able to deliver the appropriate authentication credentials. Then, users will contact a federation-level validation service and there will no need to re-authenticate the user, only a query of the related user attributes will be necessary in some cases.

Keywords: SSO, authorization, SAML, federation

1 Introduction In the last years, we have experienced the emergence of federated approaches to resource sharing. In this approaches, trust links are established among different autonomous organizations in order to grant users in any of them access to shared resources with a single identity, stated by the organization the user belongs to. Important examples of these approaches are the establishment of academic federations worldwide, like eduroam, InCommon, HAKA or SWITCH. In those scenarios where users are moving among the different organizations pertaining to the federation, authorized users may also have additional resources at their disposal at the visited institutions. Despite many aspects of federations have been addressed by several projects, other issues generally related with integral identity management are still open. For example, in those scenarios where authentication mechanisms have been included for network access control purposes, it would be interesting to create a seamless link between the network-layer authentication mechanism and any additional authentication step that will be needed when users try to gain access to application-level resources. This would

2

Manuel Sánchez, Gabriel López, Óscar Cánovas, Antonio F. Gómez-Skarmeta

involve the extension of the network access mechanism in order to deliver additional information (some kind of security credentials) that might be used at service-level in order to avoid further user re-authentication. The work presented in this paper is one of the objectives defined by the DAMe project [1]. Once the eduroam infrastructure has been extended so that user mobility will be controlled by security assertions and policies expressed in standard and extensible languages, such as SAML [5] and XACML [4], the next phase is to provide a global Single Sign On (SSO) mechanism based on that extension. Eduroam constitutes an exceptional starting point in order to provide a mechanism for transmitting the user credentials that will be used by the application-level authorization systems in order to offer a full and integrated network access experience to the users. As we will see, we have defined two different steps in order to achieve the SSO. The first one is related to the delivery of a security token during the network access that will be later used to avoid unnecessary re-authentication. Then, once that token has been transmitted to the user, it will be necessary to define how an application-level service will be able to validate that information using a federation-level service. Specifically, we will follow some guidelines already stated by the technical community in order to provide global SSO. The rest of this paper is structured as follow. Section 2 provides an overview of the DAMe project and introduces the underlying roaming infrastructure. Section 3 describes eduGAIN, an authentication and authorization infrastructure that will be used in order to provide a common validation service. Section 4 points out the set of requirements derived from a SSO scenario and section 5 describes the proposed architecture. Then, section 6 contains a survey of other proposals that informed our work. Finally, we conclude the paper with our remarks and some future directions.

2 DAMe project: Adding authorization to eduroam The eduroam network [15] is an inter-institutional roaming service based on the 802.1X architecture [8] and a hierarchical RADIUS-based infrastructure. This initiative allows users of participating institutions to access the Internet at other participants using their home institution’s credentials, all this with a minimal administrative overhead. Nowadays, eduroam is a production service that is used in more than 350 institutions over 19 countries (European and Australian-Pacific) with a great success. Figure 1 depicts the typical scenario in eduroam. It shows a user from Institution A who moves to Institution B, both pertaining to the eduroam federation. In the new institution, the user wants to get access to the wireless network. In this situation, access control is carried out following the 802.1X standard. That is, the user associates with the wireless access point (AP), which contacts its local RADIUS server in order to authenticate the user. But when this server identifies that the user belongs to a different domain, for example based on the user identifier, the authentication request is forwarded through the RADIUS hierarchy to the server located in the user’s home institution. Then, the user is authenticated and the response is routed back to Institution B, where the AP enables the requested connection.

Bootstrapping a global SSO from network access control mechanisms

3

Fig. 1. eduroam infrastructure

However, eduroam only takes into account the identity in order to carry out the access control process. In this way, it is not possible to offer different services or restrict the access to some resources based on the user profile, defined for example by means of some attributes in the home institution. Therefore, the main objective of DAMe [1] is the definition of a unified authentication and authorization system for federated services hosted in the eduroam network. Those federated services can range from network access control to other high level distributed services such as Grid Computing or web services. Due to wide deployment of eduroam, it should not be convenient to modify the eduroam infrastructure in such a way that the resulting system could be incompatible with the initial one. Therefore, DAMe defines several steps that can be applied to eduroam gradually, in order to obtain the new functionality. Besides, backward compatibility must be maintained to allow some institutions to keep on using the initial eduroam system, providing only authentication. The first goal of DAMe is to extend the eduroam infrastructure using NASSAML [10] to provide a fine grained authorization system. In this way, user mobility can be controlled by security assertions and policies expressed in standard and extensible languages, such as SAML [5] and XACML [4]. The result of this work is described in [14]. The next step consists of taking advantage of confederation mechanisms such as those defined by eduGAIN [9], which is described in more detail in the next section. In this way, federations based on different technologies such as NAS-SAML and Shibboleth [13] can cooperate building a confederation. The idea is that eduGAIN can act as intermediary infrastructure between these federations, carrying and translating the different messages and attributes. The following step is to provide Single Sign-On (SSO) from a global point of view. That is, global authentication will be bootstrapped during the network access control phase, providing the necessary security information so that there would be no need to repeat the authentication phase at the application layer. Therefore, once institutions

4

Manuel Sánchez, Gabriel López, Óscar Cánovas, Antonio F. Gómez-Skarmeta

have deployed the complete infrastructure developed in DAMe, users will access to high level resources and applications after the initial network authentication. This paper introduces the details of that SSO system.

3 eduGAIN The main goal of eduGAIN [9] is to build an interoperable authentication and authorization infrastructure to interconnect different existing federations. In this way, eduGAIN is responsible for finding the federation where a roaming user belongs to, translate the messages between the federation internal protocols and eduGAIN and vice versa, and guarantee the trust among the participating institutions.

Fig. 2. eduGAIN infrastructure

The main goal is achieved defining a set of common services, where it is included the MetaData Service (MDS), and a confederation-aware element called Bridging Element (BE) responsible for connecting the different federations to eduGAIN. In eduGAIN, metadata related to federations are published by means of a MDS. These metadata include information for locating the authentication and authorization points of the federation. In this way, the home federation of a roaming user is located by the BE obtaining the information published in the MDS. Then, the appropriate authentication and authorization requests are translated and routed by the remote BE toward the user’s home institution. As we will see in this paper, this scheme is also valid in order to communicate different institutions pertaining to the same federation, as [6] describes for Universal Single Sign On purposes. The specific way the authentication and authorization processes are carried out in eduGAIN are defined by different profiles. Currently, a profile compatible with Shibboleth, called Web SSO, and another one that does not require human intervention, called Automated Client, are defined. Moreover, additional profiles are being developed, as for instance a DAMe profile based on NAS-SAML and DIAMETER.

Bootstrapping a global SSO from network access control mechanisms

5

4 Single Sign-On scenario The proposal presented in this paper follows the guidelines defined by the uSSO framework [6]. It is centered in a multidomain scenario where different authorization systems are defined to access to the resources. These are the main requirements considered for the SSO: – The user has the appropriate credentials in its home institution (HI). – HI belongs to a federation where its issued credentials are valid. – When the user tries to access to a resource (R) in another institution (RI), the decision about the access is taken by an Authorization Service at the RI. – The authentication and authorization information about users is exchanged between institutions through a mechanism provided by the confederation. – There is a confederation-aware component called "Local Federation Adaptor" (LFA) which decides if an authentication request can be handled locally or must be sent to another institution. The functionality related to This LFA is commonly performed by the eduGAIN BE. Considering eduroam, once the user is associated to a wireless access point or is connected to a wired switch in the remote institution, he is requested for authentication information. When provided, those credentials are forwarded to the user home institution to be authenticated. But now, to enable the SSO, an authentication service is responsible for authenticating the user instead of the RADIUS server. Besides, this service should return to the user some kind of statement that can be used later to achieve the SSO. At this point, the user is allowed to access to the network. Lately, he might want to access to a protected resource in this institution or in another one belonging to the same federation. Then the user’s credentials are sent to the resource in order to be validated to gain access. Depending on the type of resource, additional steps for obtaining user attributes would be needed. This generic pattern presented here is detailed using specific technologies in the next section, where we present the architecture for SSO and the interaction among the different elements.

5 Single Sign-On proposal for DAMe Since the interaction among these elements must follow the pattern defined in the previous section, it is necessary to define two different processes. On one hand, we need to authenticate the user in order to access to the network and to receive the SSO credentials or token. On the other hand, protected resources have to use the token to validate the user’s identity. 5.1 SSO architecture The architecture for this proposal, which is shown in Figure 3, starts with the elements needed to authenticate the user using eduroam, that is, the access point with 802.1X

6

Manuel Sánchez, Gabriel López, Óscar Cánovas, Antonio F. Gómez-Skarmeta

support and the hierarchy of RADIUS servers. Moreover, according to the previous section, it is necessary to include a new service to authenticate the user and generate the SSO token. In this proposal, this element is a SAML authority called AuthN Authority, that receives a SAML AuthN Request and responds with a SAML AuthN Statement. Besides, this statement is the SSO token that will be used later for accessing the protected resources. These elements constitute the core of the user authentication phase, but new elements must be defined to allow institutions based on different authorization infrastructures to create a global SSO scenario. This cooperation can be achieved using a confederation management infrastructure such as eduGAIN. In this way, the Bridging Elements (BE) from eduGAIN will be responsible for translating the requests and responses from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa. Besides, the BE is responsible for finding the corresponding BE from the user home institution by means of queries to the MetaData Service (MDS). Finally, in relation to the authorization decision based on user’s attributes, two NAS-SAML entities are introduced. The first one, called Attribute Authority, is responsible for providing user attributes and the second one, called Policy Decision Point (PDP), is responsible for taking the authorization decisions.

Fig. 3. DAMe SSO architecture

5.2 Network authentication Once described the architectural elements, the next step is to define the specific protocols implementing the profile depicted in previous sections. First, the system authenticates the user by means of some authentication method, for example PEAP [12] as we will see, and then generates some security data which is returned to him. In DAMe, this first phase is based on the eduroam authentication through the RADIUS hierarchy (dotted lines in Figure 3), but it is enhanced with the delivery of security data to the user. Specifically, as Figure 4 details, when the user tries to access to the network in the remote institution, the remote RADIUS server forwards the authentication request to the RADIUS server located in the home institution. Then, this server asks the

Bootstrapping a global SSO from network access control mechanisms

7

AuthN Authority using an AuthN Request message, that contains the user credentials, and receives an AuthN Statement. This statement, which is the data the user receives to enable SSO, is a SAML sentence which contains information about the user’s identity, his credentials and the kind of authentication being performed. To protect the user privacy in the SSO, this statement does not contain his subject, but a handle generated by the AuthN Authority. Besides, to validate the handle later, the authority stores the matching handle-subject. Finally, the remote RADIUS server returns the statement to the user through a TLS tunnel created by the authentication method. The creation of that tunnel is detailed in the next section.

Fig. 4. Initial authentication

As Figure 4 shows in the grey area, this phase includes some messages that are not directly related to the SSO mechanism. They constitute the network access control authorization in a roaming scenario, which is a previous result of the DAMe project. More specifically, the remote RADIUS server makes use of a DIAMETER infrastructure between the two institutions to requests the user’s attributes. Finally, an authorization decision is taken consulting the PDP. 5.3 Token delivery The TLS tunnel mentioned before is part of the PEAPv2 [12] authentication method. The reason to use PEAPv2 to authenticate the user is the need for a protected channel to deliver the SSO statement. Figure 5 shows the sequence of messages needed to

8

Manuel Sánchez, Gabriel López, Óscar Cánovas, Antonio F. Gómez-Skarmeta

authenticate the user using this method. It has the special feature that after an initial handshake creates a protected tunnel between the peer and the authenticator. Then, this tunnel is used to exchange the authentication information in a secure way. Therefore the SSO mechanism can take advantage of this tunnel and use it to deliver the statement to the user in a secure way. Specifically, elements are transmitted through the tunnel by means of Type Length Value (TLV) objects. Besides, there is a special TLV, named vendor specific, which can be used to carry non standard elements. In this way, the authenticator can add the security data inside a vendor specific TLV to the last message sent to the peer before closing the tunnel.

Fig. 5. PEAP authentication method and vendor specific TLV

5.4 Resource access using SSO The second phase starts when the user tries to gain access to a protected resource after receiving the SSO token. Due to this data is used as a proof of user’s authentication, it is not necessary to ask the user again for his credentials. In this way, once the user has received the SSO data, he can access to whatever service that supports this SSO mechanism. The specific process is shown in Figure 6, where the user tries to access to some protected service in the remote institution and the service rejects the user connection because it is unauthorized. Then, the user sends the data received in the previous phase to the protected service. Alternatively, the user could add that data directly to the access

Bootstrapping a global SSO from network access control mechanisms

9

request. At this point, the service recovers and validates that information. Optionally, the resource might impose a fine grain user authorization based on more information besides the identity. In order to do this, the service sends an Attribute Query to the BE, which includes the handle from the SSO statement to identify the user. Now the BE queries the eduGAIN MDS service to know how to find the BE belonging to the user’s home institution, and then sends the query to it. When the home institution BE receives the query, it is forwarded to the Attribute Authority. This entity firstly validates the handle consulting the AuthN Authority by means of an AuthN Query. To validate the handle, the AuthN Authority check if it has a matching between this handle and a user subject, returning in that case the subject to the Attribute Authority. Then, this entity recovers the user’s attributes and returns them to the remote institution, but including in the statement the handle instead of the subject to maintain the user privacy. When the protected service receives the attributes through the BE, it finalizes the authorization process consulting the Policy Decision Point (PDP) to take the decision.

Fig. 6. Authentication using the token

Finally, once we have presented the architecture and the protocols for including SSO in the eduroam network, some other SSO mechanisms that informed our work are included in the next section.

10

Manuel Sánchez, Gabriel López, Óscar Cánovas, Antonio F. Gómez-Skarmeta

6 Related work One of the first SSO mechanisms was Kerberos [11]. This system is based on the use of a centralized Key Distribution Center (KDC), which is composed by an Authentication Server (AS) and a Ticket Granting Server (TGS). The KDC maintains a shared secret with each server and user in the system to authenticate them. The system works as follow: Firstly the user authenticates to the AS and receives a ticket encrypted with the TGS key and a TGS session key. Secondly, using the session key to authenticate to the TGS, the user sends the encrypted ticket and the id of the server that is willing to access to the TGS. Then, the TGS returns to the user a new token encrypted with the server key and a session key for the server. Finally, using this information, the user can authenticate and access to the server. Later, if the user wants to access to a new server, he can use the first ticket to request to the TGS a new ticket for the new server. But it has several drawbacks such as that the TGS becomes a bottleneck, and it must trust all the servers and vice versa. Besides, Kerberos requires synchronized clocks. Therefore, although there are proposals trying to make the protocol scalable for inter-networking, it is only usefully for single networks. Nowadays there are several SSO mechanisms, mainly for web environments, such as Shibboleth and Microsoft Passport. Shibboleth [13] is a web authorization infrastructure based on the use of SAML and web redirections to determine if a user can access to a resource through its web browser. This process is based on the user’s information that is maintained in his home institution. This mechanism enables the definition of identity federations, in such a way that the user always authenticates to his home institution, and then the needed information is sent where it is necessary to authorize him. Shibboleth defines the Service Provider (SP) and the Identity Provider (IdP). The former is the institution providing resources and the latter is the institution managing user’s identities. In this way, when the user accesses to some protected resource from a SP, he asks the IdP where the user belongs to for information about him. If the user has previously authenticated, the IdP returns the needed information, but elsewhere the user is redirected to the IdP to be authenticated. In this way, web SSO is provided. The main difference from Shibboleth with the proposal presented in this paper is that this mechanism do not include the initial network access authentication. Therefore, the user has to authenticate twice whereas we are taking advantage of a mandatory network access control system in order to distribute valid credentials for SSO. However, some efforts are being made by Internet2 [2] to develop a universal SSO mechanism similar to our proposal [3], where the network access authentication via RADIUS returns information to contact with user’s IdP. Microsoft Passport [7] offers a SSO service for websites that do not have any relationship among them. They only have to trust the entity providing the SSO service. In this way, when a user accesses to a protected website, he is redirected to the passport server to be authenticated. Then, if the authentication is successful, the user is redirected to the initial website. Besides the user’s Internet browser receives two encrypted cookies, one from the website and another one from the passport server. This mechanism, like the previous one, do not take into account any previous authentication.

Bootstrapping a global SSO from network access control mechanisms

11

7 Conclusions and future work As we have presented in this paper, there are several scenarios in federations where authentication is required in order to protect shared resources, ranging from network access to distributed web resources or grid computing platforms. Despite one of the main benefits from federations is the harmonization of procedures, information schemas, and protocols, we identified the design of a unified SSO mechanism as an interesting research activity. One of the main features of this SSO proposal is the seamless link of authentication processes performed at different levels. Since eduroam constitutes an exceptional federated service for supporting user mobility, we demonstrate that the delivery of signed tokens during the network access phase provides the desired functionality in order to bootstrap the SSO system. Moreover, the definition of PEAP-based protocols does not impose the use of new authentication methods (from the organization point of view) but provides the required distribution channel. Additionally, the choice of eduGAIN as the authentication infrastructure for validation purposes guarantees the interoperability among different type of resources located at different organizations. As a statement of direction, we are implementing the PEAP supplicant and defining also the required middleware for managing the different security tokens obtained by the users.

8 Acknowledgements This work has been partially funded by Daidalos FP6-IP-506997 and DAMe.

References 1. DAMe Project. http://dame.inf.um.es. 2. Internet 2 Home Page. http://www.internet2.edu. 3. S. Carmody. Radius profile of SAML. Revision 2, October 2006. http: //stc.cis.brown.edu/~stc/Projects/Projects-using-Shib/ eduRoam/Radius-SAML-Profile-v1.html. 4. A. Anderson et al. EXtensible Access Control Markup Language (XACML) Version 1.0, February 2003. OASIS Standard. 5. Maler Eve, Mishra Prateek, and Philpott Rob. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)v1.1, September 2003. OASIS Standard. 6. B. Kerver, M. Stanica, J. Rauschenbach, and K. Wierenga. Deliverable DJ5.3.1: Documentation on GÉANT2 Universal Single Sign-On (uSSO) Requirements, February 2007. GN2 JRA5. Geant 2. 7. D.P. Kormann and A.D. Rubin. Risks of the passport single signon protocol. Computer Networks, volume 33:51 – 58, 2000. 8. LAN MAN Standards Committee of the IEEE Computer Society. IEEE Draft P802.1X/D11: Standard for Port based Network Access Control, March 2001. 9. D.R. López, J. Macias, M. Molina, J. Rauschenbach, A. Solberg, and M. Stanica. Deliverable DJ5.2.3.1: Best Practice Guide - AAI Cookbook - First Edition, September 2006. GN2 JRA5. Geant 2.

12

Manuel Sánchez, Gabriel López, Óscar Cánovas, Antonio F. Gómez-Skarmeta

10. G. López, O. Cánovas, A. F. Gómez, J. D. Jimenez, and R. Marín. A network access control approach based on the aaa architecture and authorzation attributes. Journal of Network and Computer Applications JNCA, 2006. To be published. 11. B. Clifford Newman and Theodore Ts’o. Kerberos: An authentication service for computer networks. IEEE Communications, volume 32:33 – 38, September 1994. 12. A. Palekar, D. Simon, J. Salowey, H. Zhou, G. Zorn, and S. Josefsson. Protected EAP Protocol (PEAP) Version 2, October 2004. Internet Draft. 13. T. Scavo and S. Cantor. Shibboleth Architecture. Technical Overview, June 2005. Working Draft 02. 14. M. Sánchez, G. López, O. Cánovas, and A.F. Gómez-Skarmeta. A proposal for extending the eduroam infrastructure with authorization mechanisms, 2007. Submitted to 5th International Workshop on Security in Information Systems. 15. Klaas Wierenga and Licia Florio. Eduroam: past, present and future. In TERENA Networking Conference, 2005.