Adding Authorisation to EduRoam David Chadwick
George Beitis
Gareth Owen
Computing Laboratory, University of Kent, Canterbury, Kent, CT2 7NZ United Kingdom
Abstract EduRoam allows universities to cooperate to authenticate users as they roam between the federated institutions. However, authentication is not always sufficient since the host institution does not know how to differentiate between different groups of roaming users in order to give them access to different network resources. We have designed and built a fine grained authorisation infrastructure which allows different groups of users to be given access to different network resources. The infrastructure uses JRadius to intercept radius server events and gain the appropriate authorisation using the PERMIS authorisation infrastructure. The Network Access Server (NAS) then grants access to the appropriate VLAN given the user's access permissions.
1 Introduction Staff and students of universities and educational institutions frequently visit other institutions for conferences, study, collaboration, etc. Conferences have previously required prior configuration of wireless Network Access Servers (NASs) so that delegates may access the Internet. EduRoam [8] hopes to solve this problem by allowing members of one institution to automatically authenticate on the network of another, by using their existing login credentials. EduRoam performs the task of inter-institutional authentication by using the RADIUS protocol [11]. EduRoam is a successful international collaboration of network operators and universities, which allows them to cooperate to authenticate their users as they freely roam between the federated institutions. A user is authenticated by using the RADIUS protocol, which is an established Internet standard protocol for authentication, authorisation and accounting. The RADIUS protocol is able to proxy requests which it is not able to satisfy at the local institution, to the user's remote home institution. When a user visits a foreign institution and attempts to authenticate with its RADIUS server (via 802.1X), the foreign server will proxy the request to either a central RADIUS server or the user's home institution so that the request may be satisfied. After a roaming user has been successfully authenticated by a host institution, he or she may be granted access to the institution’s network. However, authentication on its own is not always sufficient as the roaming institution cannot distinguish between visiting professors, students or research staff. Therefore, all visiting users must be granted the same access rights as any foreign visitor to the network, and this is most often in the form of restricted 'guest' access rights. Finer grained authorisation is needed in order to give different groups of visiting users access to different network resources and services. For example, it may be desired for a member of staff to be placed on a different network to students, providing him/her with increased security and quality of service along with greater access to network resources. This paper will describe the design and implementation of such a fine grained authorisation infrastructure for EduRoam by integrating the PERMIS authorisation infrastructure [7] with EduRoam. This rest of this paper is structured as follows: Section 2 gives a brief overview of the EduRoam
service, the PERMIS authorisation infrastructure, and related work. Section 3 describes in detail how we have integrated the two infrastructures together, including the use of DNS SRV [9] records to help the PERMIS gateway determine the exact location of the server holding the user’s authorisation attributes. Section 4 describes our experimental results. Section 5 describes future work that is still needed in order to roll out this combined infrastructure into an international service.
2 Literature Survey 2.1 EduRoam EduRoam (EDUcational ROAMing) is a RADIUS-based infrastructure that uses 802.1X security technology to allow for inter-institutional roaming. The aim of EduRoam is to allow educational users who are members of one institution to log on to the WLAN (Wireless LAN) when visiting another institution by using the same credentials (username and password) the user would have used if he were still at his home institution. EduRoam resource providers must deploy NASs that support IEEE 802.1X [3], a method for authenticating wireless clients' or users' credentials. When a client attempts to connect to a NAS, the NAS sends a RADIUS request packet to the designated RADIUS server and waits for either an Access-Accept, or Access-Reject packet. These packets can also transfer additional information through the use of attributes, which will be utilised later. EduRoam resource providers must assign a single user per NAS port and they must deploy a specific RADIUS attribute within the Access Request packets. This attribute is the Calling-Station-Id attribute which holds the supplicant’s (client’s) MAC address. All EduRoam user names must conform to RFC4282 [6] and so be in the form user@realm; for example:
[email protected]. The realm component must conclude with the EduRoam identity provider’s realm name, which must be a domain name in the global DNS that the identity provider administers, either directly or by delegation. The use of such user names allows authentication requests to be proxied to the appropriate institution. Figure 1 provides an example of a user from University B (user@UniversityB) attempting to authenticate at a NAS located on University A's campus. The NAS is a wireless access point which contains a RADIUS client. The RADIUS client connects to the EduRoam infrastructure to gain authentication for the connecting user.
Figure 1: EduRoam infrastructure
2.2 PERMIS PERMIS is a role based access control (RBAC) policy-based decision-making authorization infrastructure developed by the Information Systems Security Research Group (ISSRG) at the University of Kent. PERMIS is an implementation of the X.509 Privilege Management Infrastructure (PMI) [15] that uses the RBAC paradigm. The X.509 standard defines the core components of a PMI, these being Attribute Certificates that hold user’s attributes, Attribute Authorities that assign attributes to users, and Sources of Authority that are the roots of trust in the PMI. PERMIS enhances the X.509 PMI in a number of ways. Firstly it follows the ISO-10181-3 Access control framework [1] model and defines an XML based RBAC policy that specifies the rules that control the assignment of roles or attributes to users, and privileges to roles/attributes. PERMIS also fully separates authentication from authorisation, thereby allowing applications to use any authentication mechanism they wish, not just an X.509 PKI as specified in the X.509 standard. PERMIS also supports multiple privilege allocation subsystems that bind attributes to users, including X.509 Attribute Certificates, SAML [14] Attribute Assertions, and Shibboleth [12] Attribute Assertions. The PERMIS policy is made up from a group of sub policies which are: the Subject Policy (which specifies who the sets of users can be), the Role Hierarchy Policy (which specifies all the roles and attributes and their hierarchical relationships to each other), the SOA Policy (which specifies the roots of trust), the Role Assignment Policy (which specifies which SOA’s can assign which attributes/roles to which sets of users, as well as the delegations that are allowed), the Target Policy (which specifies the protected resources), the Action Policy (which specifies the supported actions and their parameters) and the Target Access Policy (which specifies which roles/attributes can perform which actions on which target under which constraints, subject to the return of optional obligations).
The ISO-10181-3 standard specifies an attribute based access control framework compromising: • An application dependent Access Control Enforcement Function (AEF) or Policy Enforcement Point (PEP), and • An application independent and policy driven Access Control Decision Function (ADF) or Policy Decision Point (PDP). The ADF/PDP makes access control decisions based on the current PERMIS policy and the attributes of the subject, the target, the requested action and the current environment (e.g. time of day). We have extended the ISO-10181-3 model to include a policy controlled Credential Validation Service (CVS), which the PEP calls prior to the PDP in order to retrieve the user’s authorisation credentials and validate them against the PERMIS policy, before passing the valid attributes/roles to the PDP. When a user (subject) accesses a resource via the application gateway, the PEP authenticates the user in an application specific way. It then asks the CVS to validate the user’s authorisation credentials. The PEP may pass the user’s credentials/attribute assertions to the CVS (the push model), or the CVS may access one or more Attribute Authorities and/or credential repositories to retrieve them itself (the pull model). PERMIS supports the push and pull of SAML attribute assertions from AAs, and X.509 ACs from LDAP and WebDAV repositories. Finally, the PEP passes the valid attributes to the PDP and asks if the user is allowed to perform the requested action on the particular target resource. If the authorisation decision is grant the PDP may return optional obligations to the PEP for the latter to enforce when it grants the user access to the target resource. If the decision is deny, the PEP will refuse access to the user. Figure 2 provides an overview of the PERMIS infrastructure for authorising a user to perform a particular task.
Figure 2: The PERMIS Privilege Management Infrastructure
2.3 IEEE 802.1Q The IEEE 802.1Q standard [4] has specified a way of allowing multiple bridged networks to share the same physical network without the information being carried by them leaking between the networks. It does this by defining a Virtual LAN or VLAN which allows individual VLANs to communicate with each another via the use of layer-3 routers. When packets enter the network switches are configured to insert a VLAN tag into all data frames arriving from equipment used by a specific user. After the frames are switched through the corporate network, the VLAN tag is stripped off before the frame is delivered to the destination (which must be in the same VLAN). In this way, traffic between different user groups, e.g. lecturers and students, cannot be leaked to or snooped from one to another
2.4 Related work Some institutions have already added a restricted type of authorisation to their EduRoam network. For example, the University of Kent looks up local users in its LDAP directory and assigns them to an appropriate Virtual LAN (VLAN) based on their attributes in the LDAP directory. However, this only works for local users and not remote users. Also since Kent’s LDAP is not accessible to remote institutions, so it cannot be used to authorise Kent users at remote institutions. Although several PMIs already exist for managing user attributes and the federated services that users may access, e.g. Shibboleth [12] and VOMS [13], currently EduRoam offers no integration with any of them, and is therefore unable to provide finer grained access control to users visiting remote institutions. The DAMe project [5] is attempting an integration with NAS-SAML [10], a network access specific PMI that uses SAML. The DAMe project aims to integrate EduRoam with their work primarily focusing on integrating single sign-on infrastructures such as EduRoam and Shibboleth, and on providing authorisation for access to network resources. For example, their work would allow a user to logon on to a foreign institution's network using EduRoam as now, but additional authorisation would take place for application level services. These application level services could for example be file servers and email servers. However, their work does not consider the use of Virtual LANs (VLAN). In this paper we specifically focus on authorising a user to access a particular VLAN by pulling user credentials from the home institution and using a local PERMIS policy to determine his/her access rights. This is applicable to many scenarios such as where universities share a campus or campuses and have a joint wireless network infrastructure.
3 Conceptual Model and Implementation The existing EduRoam infrastructure uses RADIUS servers to provide authentication. RADIUS provides the ability to pass attributes with the decision packets and these can be used to indicate which VLAN to put the user onto. So conceptually, after the user has been authenticated against his/her home institution, we can put a post-authentication hook into the local RADIUS server, in order to perform the authorisation task. This hook will need to pull the user’s roles/attributes from his home institution and will then perform policy based authorisation before adding the appropriate VLAN attribute to the decision packet. Conceptually therefore, authorisation in EduRoam needs to be able to perform the following tasks, assuming authentication has already been completed by the existing EduRoam infrastructure:
Find the location of the user’s home institution’s AA servers or repositories;
Query them for the user's roles/attributes i.e. authorisation credentials;
Validate the authorisation credentials using a locally specified credential validation policy;
Determine which VLAN the user is permitted to access by inputting the user’s valid attributes/roles to a PDP containing a locally specified access control policy;
Supply an attribute in the response to the RADIUS server indicating which VLAN the user should be placed on.
In our implementation of this infrastructure, we combine the PERMIS authorisation infrastructure with Freeradius, a popular RADIUS server, and JRadius, which is an add-on to Freeradius that allows the incorporation of a Java module for authentication/authorisation. As PERMIS is written in Java it integrates easily with JRadius. The combined infrastructure works as follows: the roaming user is authenticated by the linked Radius servers as now, but before the response is returned to the NAS of the local site, a call out from JRadius is made to a PERMIS context handler. The context handler uses the DNS to find the location of the user’s attribute authorities/repositories (see below) and then calls the PERMIS CVS in pull mode to fetch the user’s authorisation credentials. The CVS returns the user’s valid attributes/roles to the context handler, which then calls PERMIS’s PDP to make an access decision. The CVS and PDP are configured by the local site administrator with a PERMIS authorisation policy, which states which sites are trusted to issue which attributes/roles to which groups of users, and which attributes/roles are needed in order to be given access to which virtual LANs (VLANs). We use the EduPerson schema to define the user attributes that are to be used in the PERMIS policy. PERMIS pulls the user’s EduPerson attributes from his home institution, and then makes an authorisation decision based on them. The appropriate VLAN is returned to JRadius, which returns this to the NAS. The NAS now grants access to the user, and places all the user’s network traffic on this VLAN. This allows the local site to separate both local and roaming users into different user classes and to assign different VLANs to each class of user. Our model and implementation assumes that different levels of authorization are possible for both local and remote users, and that all users can be authorised in the same way. We assume that the users are always authenticated using an appropriate technology such as RADIUS, but the method of authentication is outside the model. However, in order to make the appropriate calls to the authorisation system, the authenticated name of the user is needed along with the realm of the user. The authorisation system will need to be granted access to the remote attribute authorities/repositories in order to pick up the user’s credentials. In order to locate the correct remote attribute authority/repository, DNS SRV records are used. The user’s realm is used to formulate a DNS lookup of the attribute authority/repository service at the user's home institution. The context handler makes a call to the DNS and the DNS returns the details of the attribute authority/repository server described in the SRV record (its DNS name and port etc.). The user’s roles/attributes need to be held and named in a standard format in the attribute authority/repository, and the precise format will depend upon the type of the attribute authority or repository. In the pilot implementation we used a WebDAV repository to hold X.509 attribute certificates signed by the user’s institution, as specified in [17], but an LDAP server or a SAML AA could be used instead. The attribute authority/repository should be protected by an appropriate privacy policy that will only release the user’s attributes to the authorised CVSs of the collaborating sites. For accessing our WebDAV repository, we assigned each authorised PERMIS CVS a digitally signed attribute certificate, containing the role of EduRoam gateway, and we protected the WebDAV Apache server with the PERMIS SAAM package [18]. The policy of the PERMIS SAAM PDP states that only clients with the EduRoam gateway attribute are allowed to access the user’s attributes. In order for our solution to be widely accepted and deployed, the various components must be
standards based, using existing widely deployed standards, and profiles for the use of the standards need to be agreed by the community of users. The complete list is as follows, with candidate standards in brackets: i)
a standard for the format and content of the authorisation attributes that need to be transferred (EduPerson schema);
ii)
a standard for the identity of the users whose attributes are to be transferred (LDAP DNs or Network Access Identifiers)
iii)
a standard for the protocol that is to be used to encode the above attributes into authorisation credentials and transfer them to the requesting institution (signed SAML assertions over SOAP/Http or X.509 ACs over LDAP or WebDAV)
iv)
an agreement on the type(s) of DNS SRV records to be used to hold details of attribute authorities/repositories (e.g. webdavcerts, samlaas)
No complete solution can currently be built from off the shelf products that support the complete set of standards and profiles and that are widely deployed. For example, whilst LDAP and Apache WebDAV servers are widely deployed they do not usually store X.509 ACs; SAML AAs are not yet widely deployed and the standards are not yet fully specified [e.g. 19]; DNS SRV records are not widely utilised; and whilst eduPerson schema [2] might be widely deployed, it contains a number of candidate attributes that could be used for EduRoam authorisation. We made the following decisions and choices about the standards and profiles to be used, in order to build a pilot service and show that our approach is feasible, although it should be noted that other choices are equally valid. Concerning the eduPerson schema, we chose to use the eduPersonAffiliation attribute which specifies the affiliation a person has with an institution. Permissible values are: faculty, student, staff, alum, member, affiliate, employee and library-walk-in. Multiple values of this attribute are permissible for users who have multiple roles, such as research students who are also part-time teaching staff. This will grant them maximum access rights as a roaming user. If it is desired to use only the primary affiliation of a user, then the eduPersonPrimaryAffiliation attribute could be used. This must be single valued and must specify the primary affiliation of the user. This would limit their access rights as a roaming user. Concerning the type of repository to use, we also chose to use an Apache WebDAV server to hold the users credentials due to its ubiquity, and the fact that we have easy access to open source tools for creating and managing X.509 ACs [20]. The user is identified in the repository by transforming the user’s id into a LDAP distinguished name (DN), using the dc naming scheme [16]. For example, the DN of
[email protected] will become uid=user, dc=institution, dc=ac, dc=uk. The context handler passes the DN of the user and the location (URL) of the repository, obtained from the DNS SRV record, to the authorisation system, and it pulls the credentials from the appropriate location in the repository. By using this naming scheme, it is easy to switch repository types (e.g. to LDAP or SAML) whilst keeping the same names for the users. Concerning the use of DNS SRV records, the exact value of the SRV service is something that will need to be agreed upon internationally and registered with IANA. In our pilot implementation we used the string “webdavcerts”. Other appropriate strings can be chosen to represent SAML and LDAP repositories. Figure 3 shows an example of the use of a DNS SRV record for the university myuni.ac.uk, which stores its WebDAV repository on the server sysx.myuni.ac.uk. The _webdavcerts SRV record points to this server. The WebDAV server holds a directory of its users, in which individual user attributes are stored in base64 encoded attribute certificates, that are digitally signed to ensure their authenticity when retrieved by the authorisation systems of the roaming sites. Finally, the context handler is configured with the VLANs that the local site supports, in order of importance, and the code will run through this list asking the PERMIS PDP if the user has
permission to access each one. Processing stops once a grant is returned, or after the list has been exhausted, in which case the user is denied access to the network. Each site is fully responsible for the PERMIS policy that is deployed, so it has full control over which users can access which VLANs under which conditions. Depending on the PERMIS policy, the context handler can also push to the PERMIS PDP other information such as the current time, the NAS being used, etc depending on how complicated the policy is and what information it uses to come to an authorization decision. Figure 4 shows a diagram of our pilot system and how the components interact for authentication and authorisation against a foreign institution. The left hand box represents the foreign institution in which a user is attempting to authenticate onto its WLAN. The right hand box illustrates the user's home institution. Firstly, authentication is performed using the existing EduRoam infrastructure and then authorisation is performed to determine the designated VLAN, which is then passed via a RADIUS attribute back to the NAS. At this point the user will be authenticated and authorised and be granted access to the relevant VLAN.
Figure 3: DNS SRV record pointing to WebDAV server holding signed user attributes
Figure 4: EduRoam integration with PERMIS
4 Experimental Results To evaluate such a scheme we performed a number of tests to evaluate the time of each process whilst logging a user into an EduRoam WLAN. A RADIUS server was set up with a JRadius hook running our context handler that uses the PERMIS API to determine which VLAN to place the user on. We performed two sets of experiments: authorisation against a local realm and another set against a remote realm. The system was run on a Linux system running Fedora Core 3, with an Athlon 2600XP CPU and 1GB RAM. All performance measures are of the execution of the handler when being called from the RadClient RADIUS client program, rather than a measure of the total time a user is authenticated and authorised onto a wireless network. The results give an indication for comparison between local and remote realms. As the handler is written in Java, the System.nanoTime() function is used to measure time taken to execute parts of it. The measurements recorded were:
Context Handler Execution total time
Time taken to parse the configuration file – although this could be cached but is not here.
Time taken to locate the user's WebDav repository using DNS SRV requests (only called for remote realms)
Time taken to perform authorisation
Time taken to update the RADIUS packets and pass them to Freeradius
4.1 Results Context
Time parsing Time
Time
Time
to
Hander
configuration
locating
performing
Update
execution time (ms)
WebDav
Authz (s)
packets (ms)
(s)
repository (ms)
2.03
4.49
0.0034
1.46
0.68
1.58
4.69
0.0027
1.22
0.35
1.35
8.62
0.0038
0.21
0.81
1.68
3.24
0.0027
1.33
0.46
Table 1: Local realm
Context Hander Time parsing Time
Time
Time
execution
locating
performing
Update
WebDav
Authz (s)
packets (ms)
(s)
time configuration (ms)
to
repository (ms) 3.96
30.219841
20.5
1.26
1.881734
3.10
13.719875
31.9
1.18
0.254007
2.67
5.244137
2.85
2.28
0.296503
2.81
4.954764
37.7
2.48
0.325221
2.74
4.506033
2.38
0.78
0.389452
Table 2: Remote realm
5 Conclusions and Future Work In this work we have presented our handler for integration of EduRoam with the PERMIS PMI. This allows institutions to provide finer grained control over who is using their network and what for. The handler performed satisfactorily in both local and remote realm scenarios, demonstrating that such authorisation is practical and applicable to EduRoam. Future work will include the adaptation of the context handler to integrate with other repositories such as a SAML Attribute Authority. At the time the current work was undertaken, PERMIS did not have the ability to query SAML AAs. This functionality was only added to PERMIS after the current work had been completed. In order for the solution to be widely accepted, the community will need to agree upon the various standards and profiles to be used. We made one set of choices, which were appropriate at the time to build a pilot implementation, but these are by no means the only choices that could have been made. We suggest that this standardisation effort might be appropriate work for a Terena Task Force. We would like to make the software available for a pilot operational service, in order to gain further experience of its usability and performance, and we are currently waiting for such an opportunity to
arise.
References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]
[18]
[19]
[20]
"ISO/IEC 10181-3: Security Frameworks for open systems: Access control framework," ITU-T 1996. "EduPerson Specification," Internet2 Middleware Architecutre Committee for Education 2003. IEEE Computer Society. "802.1X: Port based Network Access Control" 2004. IEEE Computer Society. "Virtual Bridged Local Area Networks," IEEE Std 802.1Q. 2005 "Deploying Authorization Mechanisms for Federated Services in the eduroam Architecure (DAMe)," DAMe Project, University of Murcia 2006. B. Aboba, M. Beadles, J. Arkko, and P. Eronen, "RFC 4282: The Network Access Identifier," IETF 2005. D. W. Chadwick and A. Otenko, "The PERMIS X.509 Role Based Privilege Management Infrastructure," Future Generation Computer Systems, vol. 19, pp. 277-289, 2003. L. Florio and K. Wierenga, "Eduroam: Providing Mobility for Roaming Users," presented at EUNIS 2005, 2005. A. Gulbrandsen, P. Vixie, and L. Esibox, "RFC2782: A DNS RR for specifying the location of services (DNS SRV)," IETF 2000. G. López, A. F. Gómez-Skarmeta, R. Marín, and Ó. Cánovas, "A network access control approach based on the AAA infrastructure and Authorization Attributes," Journal of Network and Computer Applications, 2005. C. Rigney, A. Rubens, W. Simpson, and S. Willens, "RFC2058: Remote Authentication Dial In User Service (RADIUS)," IETF 1997. Scott Cantor. “Shibboleth Architecture, Protocols and Profiles, Working Draft 10 September 2005, see http://shibboleth.internet2.edu/shibboleth-documents.html Alfieri, R., Cecchini, R., Ciaschini, V., Dell'Agnello, L., Frohner, A., Lorentey, K., Spataro, F., “From gridmap-file to VOMS: managing authorization in a Grid environment”. Future Generation Computer Systems. Vol. 21, no. 4, pp. 549-558. Apr. 2005 OASIS. “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0”, OASIS Standard, 15 March 2005 ISO 9594-8/ITU-T Rec. X.509 (2001) The Directory: Public-key and attribute certificate frameworks Kille, S et.al. “Using Domains in LDAP/X.500 Distinguished Names”, RFC 2247, Jan 1998 David W Chadwick, Sean Anthony. “Using WebDAV for Improved Certificate Revocation and Publication”. In LCNS 4582, “Public Key Infrastructure. Proc of 4th European PKI Workshop, June, 2007, Palma de Mallorca, Spain. pp 265-279 Wensheng Xu, David Chadwick, Sassa Otenko. “Development of a Flexible PERMIS Authorisation Module for Shibboleth and Apache Server”. Proceedings of 2nd EuroPKI Workshop, University of Kent, July 2005. LNCS Vol 3545, 2005, pp 162-179. DOI 10.1007/11533733_11 T. Scavo. SAML V2.0 Deployment Profiles for X.509 Subjects. OASIS Committee Draft, August 2007. Document ID sstc-saml2-profiles-deploy-x509-cd-02. http://wiki.oasisopen.org/security/SstcSaml2X509ProfilesDeploy See http://sec.cs.kent.ac.uk/permis/downloads/download.shtml
