Introduction

It was initially envisaged that a ‘Road map’ integration or migration document would be produced at the end of this project. Part of the essence of the project was that we were to keep an open mind regarding the eventual architecture that we would build, prototype or recommend. With our rather - some would say - simplistic approach of a Customer-Service Provider model of grid use benefiting the vast majority of grid users, and the applicability of Shibboleth therein, a 'Road map' seems inappropriate. We are not recommending a 'migration' and the 'integration' is straightforward. Nevertheless, the ESP-GRID project has established some recommendations for the UK e-Science community. These have been interpreted from the findings elsewhere in our documents and wiki.

Recommendations in summary

The main recommendation we have is to consider future users and to build grids and grid applications that suit the majority of those users. There is still a need for higher security for the Power Users (currently the vast majority of users, but that proportion will shrink markedly), and digital certificates and the active use of X.509 security and practices by these users is appropriate. With the ability to protect grid infrastructure from non-computing-technical end users via applications and services built especially for them, and with the easily available alternative access management mechanisms (such as Shibboleth), there is no pressing need for such users to handle certificates.

Shibboleth is ideal for use with the 'ordinary end users' and may have some uses to benefit the Power Users. An example of a good usage is to manage access to proxy certificates using the home organisation's single sign on username and password. The concept or use case of hiding X.509 certificate use behind a 'Shibboleth front end' should be used with much caution. Of course such a system can be implemented securely, but it will be very easy to make mistakes. Furthermore, it weakens the overall security, but keeps all of the costs of heavyweight X.509 PKI.

There is a strong argument for using digital certificates where sophisticated delegation is a requirement. However, in situations where a machine makes the delegation decision - as opposed to a human - that advantage is lost. We may as well use a system of machine-to-machine trust (e.g. Shibboleth and SAML etc.) instead of a (difficult to manage) system of human-to-machine trust (e.g. X.509 personal digital certificates) if we are to hide the PKI-based user authentication/authorisation behind a user-friendly front end.

There are - and there will be many more - grid use-cases where privacy and/or confidentiality are major requirements. The use of Shibboleth, certainly for the former, is highly advantageous, but only if automated suspension mechanisms are built in to the grid, as we have advised within our Customer-Service Provider model.

Fundamentally, X.509 user certificates are fine for computer-technical Power Users. Shibboleth is ideal for 'ordinary end users'. If the use of automated, machine-based delegation becomes widespread, then the argument for using digital certificates at all for managing end users is very weak indeed.

Observations from the development process

See DeveloperEvaluation for details. These are summary notes from those pages. They are comments from the developers and largely pertain to the difficulties in setting up both Shibboleth IdPs, SPs and getting Shibboleth and PERMIS to work with/from the GridSite portals and portlets.

Usability of PKI certificates

As the BRIDGES project progressed it became evident that a major user requirement would be an easy to use interface to the grid. Biologists were simply not going to use the applications if they had to do complicated things like get UK e-Science certificates for themselves. As PERMIS, when used in conjunction with Globus, requires PKI certificates to get the username the developers used PERMIS as a look-up system rather than integrating it completely with the BLAST service.

The operating system

One problem was to find a compatible platform or operating system that did not need everything built from source, so that it all ran correctly. The developers strongly recommend a flexible attitude to operating system, considering there are quite a few dependent packages that need to be installed.

Boundaries between protocols

It was difficult (described as "complicated" by one developer) to understand where one protocol stopped and another started. Error messages would be returned - for example - referring to the PERMIS policy, or the PKI authentication methods or the Globus service implementation. Understanding where they were coming from could be very tricky. A lack of supporting documentation and difficulties navigating the source code meant the developers created their own documentation see http://www.nesc.ac.uk/hub/projects/etf/.

Shibboleth, Single Sign On and the push and pull of attributes

The SSO of Shibboleth makes it a good authentication solution for services like BLAST but it is not enough for authorisation. A service like BLAST would have to be designed to perform authorisation using attributes. At the moment, the developers are pushing attributes to Service Providers (SPs), but a pull model is better in some scenarios (i.e. requesting attributes only when needed).

The Shibboleth framework is easy to use

Although not easy to install, the main benefits of the framework are its flexibility, expandability, and ease of use. Shibboleth greatly reduces the administration load for authentication and authorisation. The administration boundary is very clear: the !IdP is only responsible for the user information and information release policy, while the SP is only responsible for the authorisation policy of the resource. Also, adding or removing a particular organisation from the federation is relatively easy. There are no complex connections between an organisation and the whole framework. This feature gives the framework "good expandability".

Virtual Organisations (VOs)

The technology paradigm allows distributed access to resources and provides a nice, flexible way of transferring attributes between participants in a Virtual Organisation (VO). This is a good way of limiting and exposing access to resources as and when they are needed in a VO. However, this may be of limited use if the implementation uses only very specific attributes (specific to the application in use). Unfortunately, the attributes may not be re-usable for other purposes, which would be the ideal. Also, it may be difficult for your 'average' !IdP to predict which attributes may be required by SPs such as these. At the moment, our IdP releases all attributes to all of the demonstrator applications: this is not optimal either. The latter of these issues would be overcome by the use of an Attribute Release Policy Editor, some of which are beginning to appear for the community.

Firewall

Unless you tailor your firewall properly to block certain ports it is quite easy for someone who knows that the system is there just to reference the URI:port directly to gain access to the Shibbed portal, and bypass authentication. This is a weakness that attackers will get to know about and the firewalls must be configured properly.

Development conclusions

The main conclusion from the developers' perspective is that the technologies used are very complex and highly variable, depending upon context. It is still too difficult for developers such as those at NeSC to set up Shibboleth, PERMIS, grid and portal technology - and they have been doing this for quite some time now. Showing others how to set up secure Shibboleth based access to grid resources is non-trivial. It is also the case that the documentation needed for this needs to be improved greatly.

Recommendations in full

Think about future users of the Grid

The Customer-Service Provider model of grid use

The current model of grid use is for collaborations of research scientists and computer scientists building useful (to the researchers) resources on "the Grid". The next phase of grid use needs to be considered. When these collaborations deliver useful algorithms, applications and resources to the research community, they are likely to be most conveniently delivered as web-based applications. At that stage "the Grid" may have many users who are non-computing-technical. These users need easy interfaces and usable security mechanisms. It would seem highly likely that the vast majority of users will be in this 'ordinary user' (non-computing-technical) category, and such users will not write code or scripts. These users have predictable use patterns and set algorithms delivered within applications and services which can assist with keeping the users' activities secure.

For such web (or portal) based use, Shibboleth is ideal to mediate access management. We have termed this convenient (and secure) division of responsibilities as the Customer-Service Provider Model.

Power Users

It seems very likely that the numbers of highly-computing-technical users will grow but their relative proportion in terms of number of users will diminish greatly. For those compiling code remotely or moving executables from resource to resource, there remains a need for higher assurance, directly asserted identity at each grid node. Client digital certificates are ideal for this purpose, although there could be alternative mechanisms. However, we would currently advise the status quo of using client digital certificates for this diminishing proportion of grid users.

Consider high(er) privacy use cases for the grid

Shibboleth was first conceived with privacy in mind, especially the 'right to read anonymously'. It does not mandate privacy (or anonymity, or pseudonymity) but it is an enabler for those situations where it is useful. Actually, the concept of Shibboleth (from the biblical etymology) is that the Service Provider cares more for what the end user is, rather than who she is. There are use-cases in the web-based information environment where anonymity or pseudonymity is required; for example, where users of politically sensitive resources need to be authorised based on group memberships (e.g. biological science graduates) but need to keep their identities obscured. Such use cases will arrive for the grid in almost exactly the same way.

If we accept that use cases requiring privacy will exist, then Shibboleth can be a great enabler for the grid. However, whichever access management system is eventually provided, it is imperative that pseudonymity is allowed-for. It will be highly short-sighted if this requirement were precluded in any future architecture. (N.B. It is possible to use Shibboleth and mandate that persistent and unique identifiers be asserted in any transaction: this would be an example of precluding the privacy use-cases).

Security requirements are not the same as requirements for identity assertion

As laid out in our paper for the All Hands Meeting (A case for Shibboleth and grid security: are we paranoid about identity?), and - in particular - within the verbal presentation given to that paper, it seems that many people confuse the need for good security with the need for 'up front' identity assertion. (See slides 12-13 in the Case for Shibboleth presentation). The need for up front identity assertion is a solution to the need for security. There are other solutions that would be equally applicable, including those involving Shibboleth.

Some of the arguments heard that oppose the use of Shibboleth (and/or pseudonyity, in addition) assume that the up front identity is a solid requirement. We addressed the (real) requirements of grids within this wiki at RequirementsDoc (and further explainations appear at RequirementsDocFull).

Take care when combining PKI and Shibboleth

The type of Public Key Infrastructure (PKI) based on (what should be) client digital certificates has been found to be difficult to use and understand for a number of users. As the DCOCE project discovered, we should be able to avoid many of these difficulties, but unfortunately we usually do not. Shibboleth is based on a security model of machine to machine trust whereby a trusted machine (a Shibboleth Identity Provider - !IdP) asserts that the user has passed the authentication/identification test and "here are some of his attributes". Client-PKI is based on user to machine trust, whereby a user proves directly to the remote machine that she is actively engaged in the authentication process by using her private key. (Awkwardly, this paradigm changes when the user creates a proxy certificate and allows another machine to manage it!). Combining these two trust models raises great complexities, but may also give rise to security risks. These risks may appear due to the complex interfaces between the 'systems' (the more complex the interfaces, the more likely for security holes to exist). Risks may also appear due to the theoretical problems of one system - based on explicit identity assertion - being mixed with another system - based around the reliance on third parties to assert that authentication has taken place (i.e. PKI and Shibboleth, respectively).

Other findings from within the ESP-GRID project

More details than that which are presented on this summary page may be found within the following wiki pages:

Stand alone reports

We have two papers that were presented at the UK e-Science All Hands Meeting 2006. These papers and the presentations that accompanied them should represent our final findings of this investigative phase. This output can be seen on the AllHandsPapers2006 page and are as follows:

Follow on work

We are following up the project with a study regarding grid usability to new users which we hope will support some of our assertions around that idea of "if it's too hard, researchers just won't use it" and considering the types of users. The proposal can be found at:

This study should run from September 2006 and January 2007 and is funded via ESP-GRID and also forms part of the eHorizons research (see http://www.e-horizons.ox.ac.uk/) into the future benefits of e-Science technologies.

Findings will be posted here as they arise.

ESPGRIDwiki: Final_recommendations_for_e-Science (last edited 2013-05-17 16:26:48 by localhost)