Access Management: The Key to a Portal - The Experience of the Subject Portals Project
Portals are widely suggested as important tools to facilitate the hard task of finding and accessing useful information for learning, teaching and research [1]. In this context, the Resource Discovery Network (RDN) [2] is enrolled in the Subject Portals Project (SPP) [3] with the aim of developing and deploying subject-based portals to provide the UK's HE and FE communities with integrated access to distributed resources within the JISC Information Environment (IE) [4].
The project is being developed in a distributed environment at the RDN hubs: BIOME, the bio-medical sciences hub; EEVL, the engineering, maths and computer sciences hub; HUMBUL, the humanities hub; PSIgate, the physical sciences hub; and SOSIG, the social sciences hub. The project deliverables will allow each hub to customise a portal for its domain-specific needs. The SPP will provide single access points with common functionality (e.g. access management, user-profiling, cross-searching) supported by a portal framework. This core functionality will provide users with streamlined access to subject-specific datasets.
Access Management (AM) has a key role within the portal as users have to be authenticated via multiple authentication mechanisms against different AM Systems (AMS) and scenarios (e.g. Athens). Thus users logging in from anywhere will be able to have personalised services and obtain authorisation to access protected remote resources.
The AM functionality for SPP involves the deployment of a local AMS and the implementation of authentication, authorisation and logic to manage users, groups, roles, access control, etc. This functionality also needs to deal with several AMSs in a complex environment.
Access Management Systems
Any AMS involves both authentication and authorisation [5]. Authentication is crucial as it provides the initial proof of who the user claims to be, which forms the basis of agreeing the required permission to access protected resources. Authentication is achieved when the users successfully produce their credentials. Authorisation is granted according to the AMS' knowledge about the users if they successfully authenticate. Within a portal environment authentication is also crucial to enable personalisation of services based on user-profiles. Figure 1 shows the entities and relationships involved in an AMS.
An AMS has to manage the agreements previously established between the institutions and resource providers in order to grant authorisation in an individual (or group/role) basis. This involves complex registration schemes based on manual registration and/or account bulk uploading. Additionally, the user namespace has to be shared between the institution and the AMS in order to identify the users, authenticate them and authorise access to the protected resources.
Within the JISC IE, Athens [6] is the approved third-party AMS, ensuring a national service to protect resources. Enabling the Athens AMS within the SPP provides seamless access to these resources for students, teachers and other staff affiliated to UK HE and FE institutions. However, the RDN hubs implementing the SPP outcomes have traditionally served an audience wider than the UK education community, including industry and non-UK users. In addition, the SPP wishes to ensure the potential for users to access resources not within the JISC IE where the resources may be protected by AMSs other than Athens. Thus the SPP takes into account that not all users are Athens users and that it is immaterial to such users where the resources they seek are placed or how they are protected. In such a complex environment SPP has to deal with several AMSs. Moreover, once the SPP made the decision to offer personalisation for every user, and accepting that there is no common AMS for all users, it was clear that a local AMS had to be offered as well.
Multiple AMS Scopes and Mechanisms
A portal could face AMSs ranging from Local (e.g. MyHumbul [7]) to National (e.g. Athens). It is indeed possible that portals will also have to contend with International AMSs. Figure 2 shows an overview of the AMS scopes the SPP may be facing.
Figure 2: AMS Scopes
The broader context in which the SPP operates is the Resource Discovery Network. Therefore a Local Authentication System (LAS) has been deployed within the RDN context. This system is intended to enable users to move seamlessly from one SPP implementation to another.
Athens is the JISC National Authentication System (NAS) provider for the academic community [8]. Its position is currently under tender and the results of the tender process will not be known until April 2003. In light of the risk that Athens might not be providing a third-party AMS beyond the end of the project in July 2003, the SPP took a flexible approach to the development of compatibility with AM standards. It is worth noting that Athens itself has recently devoted significant resources to adopting open standards (e.g. SOAP, X.509 Certificates and Shibboleth) [9].
In any case, the portal has to know which are the user's preferred AMS, NAS, LAS or other and therefore the portal potentially has to negotiate with different mechanisms dependent on differing technologies.
What is secure today may not be tomorrow. Thus across time, by advances in technology (e.g. increasing processing power) and in response to risks (e.g. security flaws found), security technology evolves. It is already the case that AMS mechanisms are moving from the traditional Username/Passwords to Single Sign-On (SSO) and Digital Certificates [10] and this may be predicted to develop further, as shown in Figure 3.
Figure 3: AMS Mechanisms
Username/passwords are the traditional mechanism to obtain authentication. However, there may exist a different AMS at each resource provider, resulting in a multiplication of usernames and passwords a user has to manage. In providing a single point of access, a portal could in theory assist the user by storing details of these various accounts within user-profiles and playing the role of a security broker between user and resource providers when required. However, not only is such a system difficult to manage, it also suffers from significant security risks, whether within the systems storing the user credentials or in the communication of those credentials to a remote resource provider.
Increasingly, tickets are being used to overcome username/password mechanism weaknesses. Single Sign-On- enabled services use this mechanism implemented as web browser cookies following closed protocols such as Athens or open protocols such as kerberos [11] (e.g. Microsoft Passport [12]), where users login once and have seamless access to a limited set of protected resources. While cookies are widely used across the web, they have several weaknesses and users may disable them on browsers making the AMS useless.
X.509 Certificates/ACLs (Access Control Lists) are starting to become mainstream as they offer a secure AMS mechanism. They need a Public Key Infrastructure (PKI) for the environment where they are applied (e.g. JISC IE), providing a scalable secure scheme for cascading authentication [13]. However, they are not easy to implement [14] and despite the main browsers being compatible with such certificates, there are still technical and cultural difficulties in understanding and using them (e.g. on what media to store them and the generation of yet another ID).
To sum up, SPP has to implement complex AM functionality to deal with several AMSs, both local and remote, where each AMS manages different sets of users and resources. Currently, JISC is running several projects to gather knowledge about the use of different AMS mechanisms, including PKIs [15] and SPP should also be aware of them.
Access Management Functionality
SPP is supported by a portal framework, middleware placed between the user and the resources. This middleware is independent of users and data storage software, as shown in Figure 4.
Figure 4: Portal Framework
The portal framework functionality consists of access management, user-profiling, cross-searching, alerting, newsfeeds and additional services [16]. Typically, users want to access the Portal from anywhere (e.g. library, home, internet café) via their preferred web browser and have seamless access to resources. The resources are collections typically stored in remote databases. These collections are metadata, which may or may not offer access (e.g. links) to the digital objects being described. An additional service may be required to provide the mapping between the metadata and the resource providers in order to give access to the digital objects.
Instead of reinventing the wheel by developing a new portal framework from scratch, SPP is putting its effort into adapting a well-established portal framework belonging to the Open Source community. SPP is using the Jetspeed portal framework from the Apache Jakarta Project [17] as it provides a stable Java portal framework actively involved in the standardisation of the Java Portlet API (Application Programming Interface) by the Java Community [18]. The Jetspeed portal framework is shipped with default AM functionality packages (e.g. DBMS (Database Management System)). However, these packages do not solve the SPP needs, as they do not target the AMSs that SPP has to work with, notably Athens. SPP has put a great deal of effort into developing the functionality to be as independent as possible from the portal framework. Therefore SPP is also investigating the possibility of running it in any Java-based portal framework (e.g. uPortal).
The existence of multiple AMSs with different scopes adds complexity to the AM functionality implementation which has to cover the mechanisms involved in the respective AMS. For instance, Athens uses a closed protocol within its AMS. Thus the functionality developed by SPP has to use the Athens Application Programming Interface (API). If the mechanisms used by the AMS change, (e.g. upgrade from username/password to X.509 certificates), the functionality also has to be changed. Consequently SPP is developing its own AM functionality package and plugging it into the portal framework.
AM standards should be followed closely in order to have the portal framework as independent of the AMS as possible. As the portal has to work with multiple AMS mechanisms, these packages have to be integrated in the portal framework in a dynamic way. Faced with these challenges, SPP is developing the AM functionality as implementations of the Java Authentication and Authorisation Service (JAAS) [19]. Login modules can be developed by external AMS providers and added to the portal framework. Therefore they can be loaded in run-time according to user preferences when they approach the portal, as shown in Figure 5.
Figure 5: AM Plug-in with JAAS Login Modules
Users always have the option not to login, remaining anonymous users. In such a situation the portal offers the user a similar session to authenticated users, but without the advantages of personalised services and without authorised access to protected resources.
Discussion
From a high-level of abstraction, SPP behaves as a virtual protected resource, where the users have to authenticate not only to profit from personalised services, but also to gain authorisation in order to access protected resources from typical resource providers.
The AM functionality consists of an AM plug-in integrated directly with the portal framework with several login modules. These modules are targeting Athens as the NAS and LDAP/SSL as the LAS. This approach proved to be reasonable as it is flexible to work with multiple AMSs and, in our experience, the development of a new Login Module may be undertaken with a few days' work.
Initially, the NAS was based on the Athens client API (now being deprecated) where the username/password pair was taken by the portal. The use of this username/password mechanism suffered from high vulnerabilities, as the Athens credentials had to be taken by the portal as a "trusted AMS broker" and travel across the network to Athens. Unfortunately, this mechanism could easily be abused either at the local portal site or on the network.
Currently, NAS is based on AthensSSO. Despite the initial difficulties of integrating AthensSSO with the portal framework due to the lack of information from the Athens AMS as to whether users approaching the portal were already within an AthensSSO session, these difficulties were eventually overcome. Through collaboration between Athens and SPP, the Athens protocol was upgraded. The new information provided by the protocol is important to SPP in order to maintain the users in a consistent look-and-feel when they are redirected to the Athens Authentication Point within the Athens-protected domain and redirected back to the portal. An early interceptor takes control of the initial user request and verifies if the user is already within an AthensSSO session. If positive and the NAS is the preferred AMS, then a portal session is automatically presented. Otherwise, the user is asked to present their credentials to the NAS or the LAS and, if successful, a portal session is presented.
In terms of the future, SPP is also actively working with X.509 Digital Certificates in order to provide much more robust security and prepare the portal framework for the expected future JISC AMS [20].
Authors' note
Figure 1: This picture was adapted from David Boyd's presentation at the Managing Access to Resources on the Grid Workshop: http://umbriel.dcs.gla.ac.uk/NeSC/general/esi/events/140/ which in turn was adapted from an original slide by John Paschoud, London School of Economics.
References
- For further reading on portals see:
Dovey, Matthew. JISC Technology Watch Report: Java Portals, Joint Information Systems Committee, December 2001. http://www.jisc.ac.uk/techwatch/reports/tsw_01-03.pdf
Fraser, Michael. Institutional Portal Discussion Paper, Oxford University Computing Services, December 2002
Miller, Paul. "The Concept of the Portal", Ariadne, December 2001. http://www.ariadne.ac.uk/issue30/portal/
Pinto, Francisco et al. "Interoperable Portal for the Historic Environment". Proceedings of the European Conference on Research and Advanced Technology for Digital Libraries (Interoperability on Digital Libraries - Delos Workshop 2001), September 2001 http://www.cs.ukc.ac.uk/pubs/2001/1262/index.html
Pirri, Marco et al. "Design of a Federation Service for Digital Libraries: The Case of Historical Archives in the PORTA EUROPA Portal (PEP) Pilot Project", Proceedings of the International Conference on Dublin Core and Metadata for e-Commerce 2002, October 2002 http://www.bncf.net/dc2002/program/ft/introd.pdf
Wege, Christian. "Portal Server Technology", IEEE Internet Computing, 6(3):73-77, May/June 2002.
http://www.isse.gmu.edu/faculty/ofut/classes/821/papers/Portal_Server.pdf - For more information on the Resource Discovery Network, see http://www.rdn.ac.uk
- See the project web site http://www.portal.ac.uk/spp/ and also
Clark, Judith. "Subject Portals", Ariadne, October 2002. http://www.ariadne.ac.uk/issue29/clark/ and
Stuckes, Julie. "Subject Portals Project Overview", Vine, March 2002. http://www.portal.ac.uk/documents/Vine_JS_032002.doc - Powell, Andy and Lyon, Liz. The DNER Technical Architecture: scoping the information environment, UKOLN, May 2001.
http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/dner-arch.html - For additional information on authentication and authorisation issues in portal environments, see Atluri, Vijayalakshmi and Gal, Avigdor. "An Authorization Model for Information Portals", ACM Transactions on Information and System Security 5(2):62-93, February 2002. http://doi.acm.org/10.1145/504909.504912
and Lynch, Clifford. A White Paper on Authentication and Access Management Issues in Cross-organizational Use of Networked Information Resources, CNI, April 1998. http://www.cni.org/projects/authentication/authentication-wp.html - Athens http://www.athensams.net/
- The Humbul Humanities Hub http://www.humbul.ac.uk
- Robiette, Alan and Holmes, Nick. Access Management Service for UK Higher and Further Education, Joint Information Systems Committee, August 2002 http://www.jisc.ac.uk/index.cfm?name=funding_4_02
- For further information on these services: http://www.athensams.net/development/
- For a discussion of these issues see Atluri (op cit) and Robiette, Alan. Middleware for the JISC Information Environment - Proposals for Discussion, Joint Information Systems Committee, April 2002.
http://www.jisc.ac.uk/index.cfm?name=jcie_middleware - Kerberos: The Network Authentication Protocol http://web.mit.edu/kerberos/www/
- Microsoft .net Passport http://www.passport.net/
- Adams, Carlisle et al. "Which PKI (Public Key Infrastructure) is the right one?", Proceedings of the 7th ACM Conference on Computer and Communications Security, December 2000.
http://doi.acm.org/10.1145/352600.352615 ;
Lynch (op cit); and Robiette, Middleware for the JISC Information Environment - Proposals for Discussion (op cit). - As Adams et al discuss (op cit).
- See JISC's Authentication, Authorisation and Accounting (AAA) Programme http://www.jisc.ac.uk/index.cfm?name=programme_aaa
- Stuckes (op cit).
- The Apache Jakarta Project http://jakarta.apache.org/jetspeed/
- JSR 168 - Portlet Specification http://www.jcp.org/en/jsr/detail?id=168
- The JavaTM Authentication and Authorization Service (JAAS) http://java.sun.com/products/jaas/
- Robiette, Alan. The Future of Authentication for JISC Services, JISC, April 2002
http://www.jisc.ac.uk/index.cfm?name=jcie_authentication
Author Details
Dr. Francisco Pinto
|