Skip to content Skip to navigation Skip to collection information

Connexions

You are here: Home » Content » Research in a Connected World » Resource Sharing: Trust and Security

Navigation

Lenses

What is a lens?

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

This content is ...

In these lenses

  • eScience, eResearch and Computational Problem Solving

    This collection is included inLens: eScience, eResearch and Computational Problem Solving
    By: Jan E. Odegard

    Click the "eScience, eResearch and Computational Problem Solving" link to see all content selected in this lens.

Recently Viewed

This feature requires Javascript to be enabled.
 

Resource Sharing: Trust and Security

Module by: richard sinnott. E-mail the authorEdited By: Alex Voss

Summary: This chapter discusses the need for trust and security in resource sharing. It discusses concepts such as authentication, authorisation and single sign on mechanisms.

Key Concepts

  • Single sign-on access to distributed resources
  • Certification Authority (CA) and its problems
  • Shibboleth technologies
  • Portlets for finer grained security of portals – SCAMP, CCP and SPAM-GP ACP

Introduction

Many researchers require environments providing seamless access to and usage of a heterogeneous variety of distributed resources: on-line journals, data repositories and archives, software, large scale high-performance computing facilities (HPC) or indeed support for collaborations between distributed research teams themselves. The internet-age is truly upon us and there are few disciplines where radical IT-driven change in the way research is undertaken has not been felt. The vision of e-Science and the Grid, as part of e-Research, has been to support seamless and transparent access to such heterogeneous resources. Solutions within the e-Science model should support user/research-oriented environments offering seamless single sign-on to a range of research-specific distributed resources. For many disciplines however, trust and security are paramount and many existing models of single-sign on security are inadequate. Instead controlled trust-driven environments are required where sites can remain autonomous and in strict control of their resources through their own discretionary local access and usage policies. In this paper we outline how the UK Access Management Federation, augmented with advanced authorization solutions, supports this model. This UK example can serve as a more general exemplar for other national contexts.

Single Sign-on and a Centralized Certification Authority

It is a fact that security is essential for much, if not all, inter-organizational collaborative research. Many disciplines place a higher emphasis on security of resources, e.g. the clinical health domain, but even those disciplines where security is not a primary focus, e.g. the particle physics domain, would be seriously affected by downtime or compromise of HPC facilities that they use.

From a security perspective, the vision of e-Science and the Grid has been to provide single sign-on access to distributed resources, i.e. where a user is able to access multiple resources without the need for multiple, individual authentications (username/password challenges for example). This has been largely tackled in the UK through establishment of a centralized Certification Authority (CA – www.grid-support.ac.uk/ca). Through recognizing and trusting a CA in associating the identity of a researcher with a particular digital certificate (typically through a local institutional Registration Authority charged with ensuring that the user presents in person their passport or matriculation card as evidence of their identity), single sign-on authentication can be supported. Thus researchers use their X509 certificate (or more often a proxy credential created from that X509 certificate) with a common username given by the distinguished name (DN) associated with that credential and a single (strong) password. Through sites trusting the CA that issued the certificate, the end user is able to access a wide range of resources that recognize that credential without the need for multiple usernames and passwords across those sites. In short, the approach is based upon a model of public key infrastructure (PKI) supporting user authentication.

Relying solely upon X509-based PKI models for Grid security suffers from numerous problems. Firstly, users must acquire and manage their own X509 digital certificates often having to convert them to different Grid-oriented formats using specialized software, often far removed from their own domain of expertise. Secondly, X509-based PKI security as used to access resources such as the UK e-Science National Grid Service (NGS – www.ngs.ac.uk) is based on associating a local account on an NGS cluster for a user identified by their DN, to “do stuff” without limiting (authorizing) what this stuff actually is! For security considerations, this is obviously a major issue for many domains. Thirdly, a centralized CA model has issues with supporting longer term identity management. Thus if an individual leaves the organization they are associated with, they probably will still be in possession of their X509 digital certificate. A better model is to support decentralized authentication. In the UK this has been supported through adoption and roll-out of the Internet2 Shibboleth technologies to support devolved (federated) access management (www.ukfederation.org.uk).

Shibboleth: Decentralized Authentication

The core of Shibboleth is a trust relationship between institutions within a federation, where each institute in the federation is expected (trusted) to authenticate their users properly. The architecture of Shibboleth defines several entities which are necessary to achieve this seamless integration of separate collaborating institutional authentication systems. The main components of Shibboleth consist of Identity Providers (IdPs); a Where-Are-You-From (WAYF) service, and one or more Service Providers (SP). The IdP is typically the users’ home institution and is responsible for authenticating the end users at their institution. Each institution will have their own local systems for authenticating their users, e.g. LDAP or other mechanisms. The WAYF service is generally run by the federation that the institutions are subscribed to. It typically presents a dropdown list to the user that contains all the participating institutions (or projects) that are subscribed to within the federation. Users choose their home institution from this list and are then redirected to the home institution (IdP). The SP provides services or resources for the federation that the end user wishes to access.

A typical scenario of this process is shown in Figure 1, where a user types in the URL of the service or Grid portal (SP) they wish to access.

Figure 1: Shibboleth-oriented Federated Access
Image showing interactions between different components of Shibboleth

In this model, if the SP is protected by Shibboleth, the user will be redirected to the WAYF service where they select their home institution. Once redirected to their IdP they will provide the username and password they would normally use for authentication at their home institution. Once successfully authenticated, the user will be automatically redirected to the SP they are trying to access. At the same time, the security attributes (privileges) of this user will also be passed to the SP in a secure manner for further authorization from either the IdP or one or more known attribute authorities (AA). What attributes will be released by an institutional IdP or AA and what attributes will be accepted by a given SP needs to be configurable however and targeted towards the needs of particular virtual organizations. It is important that all of this is transparent to the end users (who simply log-in to their home site).

Key to this model is trust and security. Sites need to be sure that collaborating sites have adopted appropriate security policies for authentication for example and that they have appropriate rigor in management of strength of user passwords and ideally, support a unified institutional account management. It is also the case that for some virtual organizations, some sites may be recognized (trusted) whilst others may not. A given SP might only be available to members of a particular virtual organization for example, and only researchers at the sites involved in the collaboration should be able to access and use the SP resources. Similarly, given institutions need to be able to define which attributes they wish to send to which SPs. A naïve model would be that all attributes for a given user from a given site would be sent through to a given SP. However an improved model would support a targeted (reduced) subset of attributes that are released based upon what that service requires to make an access control decision. The Open Middleware Infrastructure Initiative (OMII-UK) funded the Security Portlets simplifying Access and Management of Grid Portals project (SPAM-GP), which developed tools that support precisely such requirements.

Scoping of Trust and Protecting of Resources: Finer Grained Security of Portals

Figure 1 illustrates how a given Grid portal can be accessed through Shibboleth. However, it is essential for many domains that access to such resources is restricted further. Simply knowing that someone has authenticated at the University of Glasgow will typically not be sufficient for access control to clinical data sets that might be available through the portal for example. To support this finer-grained scoping of trust and associated authorisation, the SPAM-GP project implemented a variety of JSR168 compliant portlets that a portal administrator could apply to support finer-grained security of their portals and the portal content, e.g. portlets that give access to remote VO-specific resources, in a Shibboleth-environment.

The first such portlet developed was the SCAMP (Scoped Attribute Management Portlet). This portlet allows restricted and syntactically correct manipulation of the Attribute Acceptance Policy (AAP) of a Shibboleth SP to streamline the subset of IdPs from whom a portal will accept user attributes. Thus if a collaboration only involves a subset of organizations in the UK federation, then SCAMP allows to limit access to the portal to that subset of sites. To achieve this, the portlet parses the federation metadata for the list of all the IdPs within the federation, and stores the values of the ‘scope’ entry for each IdP.

When the SP is provided with a scoped attribute, the suffix will by definition be one of these scoped values. The list of IdP scopes in the federation is provided to the user/portal administrator in the form of a drop down list, one per user attribute, where the institutions from whom attributes are to be recognized/accepted from may be selected. The first time the portlet runs, the policy will set all attributes to ‘scoped’ but with no scope defined, so the default behaviour will be to accept attributes from no institutions – a default common with most security infrastructures, i.e. deny all. Subsequently collaborating sites can be iteratively added to build a VO at the attribute level by the portal manager. Once defined, these changes can then be added to the AAP file. This policy information will then subsequently be available for the next browser session referencing that resource, i.e. only allowing access to the resources from known and trusted sites with expected attributes.

A Content Configuration Portal (CCP) was developed to allow the dynamic configuration of contents of a portal based upon presented user privileges that are presented from Shibboleth. Intuitively, CCP allows users to access and use client portlets that are associated with their given privilege sets as defined by a portal administrator. An example of application of the CCP in the neurological domain is shown in Figure 2 where the portlet on the right is for researchers with a brainIT-investigator role and the portlet on the left for researchers with a brainIT-nurse role. The definition of these roles and their association with specific portlets (giving access to remote services/data), and finally their dynamic configuration through information presented by Shibboleth is at the heart of the CCP.

Figure 2: Example of CCP Application in the Neurological domain
image showing role-based access control in a portal

The SPAM-GP Attribute Certificate Portlet (ACP) is a JSR-168 compliant portlet that supports sites wishing to define and enforce their own remote authorization. Thus it is unlikely that a resource provider will simply delegate their security and access control to a potentially remotely managed portal. ACP allows the security information (attributes) to be signed and stored in a local attribute store for use by remote providers in enforcing their own local authorization policies. Currently the ACP has been applied successfully to a range of distributed resources and resource providers including those in the clinical domain through projects such as the Medical Research Council (MRC) funded Virtual Organisations for Trials and Epidemiological Studies project (VOTES), the social science domain through projects such as the Economic and Social Science Research Council (ESRC) funded Data Management through e-Social Science project (DAMES) and the geospatial domain through projects such as the Joint Information Systems Committee (JISC) funded Secure Access to Geospatial Services project (SeeGEO).

Summary

Employment of an adequate trust and security model is crucial to e-Research. It must provide researchers with easy access to shared heterogeneous, distributed resources while ensuring adequate protection of those resources. Some disciplines place more emphasis on security, for instance the medical field where patient confidentiality is paramount, but all disciplines undertaking e-Research involving distributed systems require a model that takes into account issues of single sign-on authentication and authorisation which should apply to all computational and data resources. In this chapter, we have presented examples of models that work well to address these issues of resource sharing. These models are now being used in a variety of diverse large scale projects including major European clinical trials; nanoCMOS electronics; social sciences and the arts and humanities amongst others. More information on these solutions and the work of NeSC at Glasgow is available at www.nesc.ac.uk/hub.

Acknowledgements

This work was funded by a variety of grants from the EPSRC, ESRC, JISC and the MRC. We gratefully acknowledge their support. More information on NeSC at Glasgow and the security-oriented projects that they are involved in is available at www.nesc.gla.ac.uk/projects.

References/Further Reading

Watt, J., Sinnott, R.O., Ajayi, O., Jiang, J. and Koetsier, J. (2006). A Shibboleth-Protected Privilege Management Infrastructure for e-Science Education. 6th IEEE International Symposium on Cluster Computing and the Grid, CCGrid2006, May, Singapore.

Sinnott, R.O., Watt, J., Chadwick, D.W., Koetsier, J., Otenko, O., and Nguyen, T.A. (2006). Supporting Decentralized, Security focused Dynamic Virtual Organizations across the Grid. 2nd IEEE International Conference on e-Science and Grid Computing, Amsterdam, December.

Sinnott, R.O., Watt, J., Ajayi, O. and Jiang, J. (2006). Shibboleth-based Access to and Usage of Grid Resources. IEEE International Conference on Grid Computing, Barcelona, Spain, September.

Sinnott, R.O. (2008). Grid Security. In Wang, L, Jie, W. and Chen, J. (eds.) Grid Computing: Technology, Service and Application, CRC Press, May.

Sinnott, R.O., Chadwick, D., Doherty, T., Martin, D., Stell, A., Stewart, G., Su, L. and Watt, J. (2008). Advanced Security for Virtual Organizations: Exploring the Pros and Cons of Centralized vs Decentralized Security Models. 8th IEEE International Symposium on Cluster Computing and the Grid (CCGrid 2008), May, Lyon, France.

Wei, J., Arshad, J. and Sinnott, R.O. (2010). A Review of Grid Authentication and Authorization Technologies and Support for Federated Access Control, to appear in ACM Computing Surveys, January.

Collection Navigation

Content actions

Download:

Collection as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Module as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Add:

Collection to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks

Module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks