In the last years, we have experienced the emergence of federated approaches to resource sharing. In these federations, trust links are established among different autonomous organisations in order to grant users in any of them access to shared resources with a single identity, stated by the organisation the user belongs to. Important examples of these approaches are the establishment of academic federations worldwide and the concepts around Grid Computing.

In fact, many aspects of this federated approach have been addressed by several projects, as for instance Shibboleth [18] or Liberty Alliance [1]. However, other aspects generally related with integral identity management are still open, especially those related to user authorization. Indeed, authorization is a critical feature in this environment because when an organization offers its resources to the users belonging to other domains, it wants to be sure that only allowed users are able to perform the set of allowed actions over each resource.

This service level agreement among different organizations requires several efforts related to user mobility, exchange of security information, integration of heterogeneous proposals, etc. Concerning to user mobility, the TERENA Mobility Task Force [19] provided a forum for exchanging experiences and knowledge about the different roaming development activities in the European Union. As a result of this effort, this task force defined and tested an inter-NREN roaming architecture, called eduroam [20], based on AAA servers (RADIUS [16]) and the 802.1X [9] standard. Eduroam 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.

Depending on local policies at the visited institutions, eduroam participants may also have additional resources at their disposal. Therefore, it would be desirable to extend the eduroam architecture with authentication and authorization mechanisms in order to exchange additional information (credentials) about the users that might be used at service-level. The main objective of the DAMe project (Deploying Authorization Mechanisms for Federated Services in the EDUROAM Architecture) [6] is to define this unified authentication and authorization system for federated services hosted in the eduroam network, in order to allow the use of those user authorization credentials previously described. Those federated services can range from network access control to distributed services like Grid Computing.

Due to that eduroam already defines how the authentication process is managed inside a federation, the main DAMe challenge is to define how the authorization process will be included in this infrastructure. In order to get this, DAMe will make use of two proposals: the first one is the NAS-SAML infrastructure [11]. NAS-SAML is a network access control approach based on the AAA architecture and authorization attributes, and a flexible, scalable and manageable authorization system. The proposal is based on the SAML (Security Assertion Markup Language) [14] and the XACML (eXtensible Access Control Markup Language) [15] standards, which are used for expressing access control policies based on attributes, authorization statements, and authorization protocols; the second one is eduGAIN [10], which objective is to build an interoperable authentication and authorization infrastructure to interconnect different existing federations.

Analysis of the requirements

In order to integrate authorization mechanisms in eduroam, several considerations have to be taken into account: the first one is that we need a way to recover the authorization credentials from the user's home institution, for example, the user attributes or roles he had previously assigned; the second one is that an authorization decision module is required in order to decide whether specific user properties (defined by the home or remote institution), using the attributes he presents from his home institution, can be applied to the required resource, in this case, the network; finally, the third one is the need of a communication framework or protocol able to support the exchange of those authorization credentials both inside a federation and between different federations.

The first requirement implies the definition of an authority able to accept user attribute requests and to decide which attributes can be or not revealed to the petitioner institution. This authority will depend on the authentication and authorization infrastructure deployed in the home institution, for example, it could be the Identity Provider module defined by Shibboleth, the Authentication Service provided by PAPI, or the Attribute Authority defined by NAS-SAML.

The second requirement implies the integration of a Policy Decision Policy (PDP), which, making use of access control policies, takes the final decision about the user authorization process to access the network. NAS-SAML already provides the definition of this module and defines a first approach to the definition of access control policies by means of the XACML standard. These components fit very well with the requirements of this proposal and can be integrated as described below.

The third requirement is solved by the integration of the eduGAIN infrastructure in order to get in touch different institutions from the same or different federations. This infrastructure provide a framework for the exchanging of authentication, attributes and authorization decision messages using a standard language, such as SAML, and defining the required entities.

We have to take also into account that a way to link the authentication and attribute requests between two institutions is needed in order to speedup and simplify the authorization process. That is, once the user is authenticated in eduroam in his home institution, the remote one will ask for his attributes to the latter. It would be desirable to link these two processes in order to avoid a re-authentication process during the attribute request step. That could be solved by the definition of some kind of token, able to authenticate the user, obtained by the remote institution during the authentication phase and presented to the home one during the authorization phase.

Architectural overview

Figure 2 shows the main components of the proposed architecture. Here we can see how under the typical eduroam infrastructure, composed by the eduroam network and the RADIUS servers belonging to each institution, we have added the required components for the authorization phase. These components include a generic identity provider entity defined in the home institution, the NAS-SAML PDP component and access control policies, and the eduGAIN components to keep in touch both institutions. These entities are described below.

Figure 2: Implemented architecture

Home Institution

This one is the institution where the user belongs to. It is responsible for defining the user’s profile. Besides, when other institutions ask for information about some user, it must release only the appropriate attributes following a predefined policy.

Remote Institution

This one is the institution where the roaming user is trying to access to some resource, for example the network. The authentication will be forwarded to the home institution, but the authorization decision will be taken locally.

Access Point (AP)

It is the entity providing physical network access to users. The AP must support the 802.1X specification to perform the access control.

RADIUS server from Remote Institution

This server is the authentication element defined in the 802.1X specification. It receives authentication requests from the AP. If the user belongs to this organization the request will be processed locally. Otherwise, if he is a roaming user, the request will be forwarded to the appropriate RADIUS server. Moreover, as later described, the RADIUS server will be extended to support the authorization process.

RADIUS server from Home Institution

This authentication server receives authentication requests from the eduroam infrastructure. It will be extended to obtain an authentication assertion from the Identity Provider, through the eduGAIN infrastructure, after the user is authenticated. These requests come from roaming users who belong to this institution.

BE from Home Institution

The BE from home institution has two main tasks. The first one, during the authentication phase, is to acts as a common interface for the home RADIUS server to the Identity Provider. In this way, the BE will receive authentication queries from the RADIUS server and will forward them to the appropriate Identity Provider. Once received the response, the BE is in charge of generating a token that can be used as an authentication proof during the authorization phase. The format of this token is described in [21]. The second task is to receive the attribute query messages from remote institutions and to forward them to the appropriate attribute authority (in this case is also the Identity Provider). Those attribute queries include a handle (obtained from the token) as proof of identity. Standard eduGAIN BEs have to be extended in order to manage the authentication token.

BE from Remote Institution

This component of eduGAIN acts as the bridge between both institutions during the authorization phase. The remote RADIUS server, once the user is authenticated, will ask the local BE about the user attributes, defined in this home domain, in order to be able to take the right decision. This query will include a handle, obtained from the authentication token previously described. Once the BE has these attributes, it will ask the PDP entity in order to know the obligations or properties to be applied to the network connection, and will forward those properties to the RADIUS server. The BE has to be extended to support the communication with the RADIUS server and to manage the authentication token, as described below.

Policy Decision Point (PDP)

This module is responsible for taking the authorization decisions about users based on the Resource Access Policy. Basically, this policy defines which users properties or obligations are allowed to be applied over which resources. The PDP receives the requests from its local BE.

Identity Provider (IdP)

This module is responsible for providing information about the users belonging to the institution. This information can be related to both authentication and authorization processes. During the authentication phase, this module is in charge of generating authentication statements. During the authorization phase, it has to control which user attributes has to be revealed or not, using the handle to select the right user and, optionally, an attribute release policy, to decide which ones can be revealed, depending, for example, on the remote institutions or the requested service.

Protocols and profiles

Figure 3 shows the network authentication phase proposed by DAMe. When the user requests access to the eduroam network in a remote institution, the remote RADIUS server receives the Access-Request message, containing the user credentials. The remote RADIUS servers knows he is a foreign user, so, through the eduroam network, redirects the user to his home institution. The home RADIUS server, after authenticate the user, will invoke the Identity Provider in order to get an authentication statement. In order to define a common interface between the RADIUS server and the Identity Provider deployed by each institution, this invocation is made through the eduGAIN infrastructure by means of the SOAP protocol.

Figure 3: Network authentication

Once the home BE receives the authentication response, if success, it will generate an authentication token, which will be used latter during the authorization phase. BE forwards the response (including the new token) to the RADIUS server, which will send an Access-Accept message to the remote RADIUS server. The information needed for network authorization phase is a handle (usually the user's subject) can be forward to the remote institution in the Access-Accept message. It is important to note that in Figure 3, a PEAP connection is established between the RADIUS server and the end user (dotted line), and that the authentication token is forwarded directly to the user. This step is optional and is used to provide SSO mechanisms to high level services as described in [].

Once the user is authenticated, before to send the EAP-success message to the end user, the RADIUS server can launch the authorization phase. Once received the handle, the RADIUS server will ask the network properties or obligation about the user connection to be applied. These properties are defined based on the user attributes. The RADIUS server delegates the process to obtain the user attributes and to check the properties to be applied to the remote BE, which will act as follow.

Figure 4: network authorization

The RADIUS server invokes this process to the BE component by means of a LDAP connection. It is important to note that the LDAP protocol has been selected in order to minimize the modification of the RADIUS servers in the eduroam hierarchy, due to it is an already implement component of the most RADIUS server implementations.

The BE, using the handle provided in the last message, sends an SAML AttributeQuery message (as described in eduGAIN) including the handle, to the home BE. The location of this element could be obtained either from the handle or the MDS (MetaData Service) module defined by eduGAIN. The home BE will forward the query to the corresponding attribute authority, in this case the Identity Provider.

The Identity Provider, using the handle, selects the user attributes and, optionally, could use an attribute release policy, to check the set of ones that could be revealed to the remote institutes. It generates a SAML AttributeStatement sentence including the selected attributes, which is forwarded to the remote BE. The BE, using the NAS-SAML PDP entity, will send an authorization decision query in order to know the set of properties that have to be applied to the user network connection. Once selected those properties, they are forwarded to the RADIUS server by means of the LDAP protocol, which will be the responsible for enforcing them into the AP.

References

[1] J. Beatty and al. Liberty Protocols and Schema Specification Version 1.1. Liberty Alliance Project. January 2003

[2] P. Calhoun, G.Zorn, D. Spence, and D. Mitton. DIAMETER Network Access Server Application, August 2005. RFC 4005.

[3] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. DIAMETER base protocol, September 2003. RFC 3588.

[4] O. Cánovas, G. López, and A.F. Gómez-Skarmeta. A credential conversion service for SAML-based scenarios. First European PKI Workshop, volume 3093 of Lecture Notes in Computer Science, pages 297–305. Springer, 2004.

[5] S. Carmody. RADIUS profile of SAML. Revision 2. http://stc.cis.brown.edu/~stc/Projects/Projects-using-Shib/eduRoam/Radius-SAML-Profile-v1.html. October 2006.

[6] DAMe project. http://dame.inf.um.es. November 2006.

[7] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, and D. Spence. Generic AAA Architecture, August 2000. RFC 2903.

[8] D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, and R. Chandramouli. Proposed nist standard for role-based access control. ACM Transaction on Information and System Security, 4(3), 2001.

[9] LAN MAN Standards Committee of the IEEE Computer Society. IEEE Draft P802.1X/D11: Standard for Port based Network Access Control, March 2001.

[10] D. R. López, A. Solberg, and M. Stanica. "eduGAIN Profiles and Implementation Guidelines", December 2006. GN2 JRA5. Geant 2.

[11] G. López, O. Cánovas, and A. F. Gómez. Use of xacml policies for a network access control service. 4th International Workshop for Applied PKI, IWAP 05, pages 111-122. IOS Press, 2005.

[12] G. López, O. Cánovas, A. F. Gómez, J. D. Jiménez, 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.

[13] G. López, O. Cánovas, A.F. Gómez-Skarmeta, S. Otenko, and D. Chadwick. A heterogeneos network access service based on Permis and SAML. 2nd European PKI Workshop, volume 3545 of Lecture Notes in Computer Science, pages 55-72. Springer, 2005.

[14] OASIS. Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1. OASIS Standard. September 2003.

[15] OASIS. eXtensible Access Control Markup Language (XACML) Version 2.0. OASIS Standard. February 2005

[16] A. Rubens C. Rigney, S. Willens and W.Simpson. Remote Authentication Dial In User Service (RADIUS), June 2000. RFC 2865.

[17] M. Sánchez, G. López, O. Cánovas, and A.F. Gómez-Skarmeta. Grid Authorization Based on Existing AAA Architectures, 2006. Fourth International Workshop on Security In Information Systems WOSIS-2006.

[18] T. Scavo and S. Cantor. Shibboleth Architecture. Technical Overview. Working Draft 02. June 2005

[19] Trans-European Research and Education Networking Association (TERENA). http://www.terena.nl.

[20] K. Wierenga and L. Florio. Eduroam: past, present and future. TERENA Networking Conference 2005.

[21] University of Murcia. DAMe conversions. From Shibboleth and PAPI authentication to eduGAIN SSO token. June 2007. http://dame.inf.um.es/