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 benefitting the vast majority of grid users, and the appliccability of Shibboleth therein, a 'Road map' seems un-necessary. We are not recommending any 'migration' at this stage 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.

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

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 [http://www.dcoce.ox.ac.uk DCOCE] project discovered, we should be able to avoid many of these difficulties, but unfortunately we usually do not. UNFINISHEDXXXX

Observations

Think about future users

Application-based access. Suitable for Shibboleth

Numbers of technical users will stay the same.

PKI suitable for technical (computer-centric) users, Shibboleth suitable for others

Developer Evaluation

See DeveloperEvaluation

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. (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

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/. (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

Cookies

...A non-cookie solution will make the current Shibboleth implementation more secure in the future. 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). (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

The 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. System administrators can easily and freely adjust user information on the Identity Provider (IdP) side without impacting the (Service Provider) SP side. On the other hand, a SP can often adjust the access management policy without troubling the IdP. In this way, 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". (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

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. (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

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. (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

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. (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

In conclusion

The main conclusion from the developers' perspective is that this all needs to be explored in much more detail. 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. Richard Sinnot writes: "We know how to do it one way, but if someone has a slightly different OS or different version of Globus, or wants to use OMII or UniCore or whatever, then we [the NeSC developers] can guarantee nothing." (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

It is also the case that the documentation needed for this needs to be improved greatly; this is what the NeSC team have been trying to do but it is still non-trivial in that their documentation tends to be more like a complex installation and configuration recipe, ("set classpath to this, configure XML file to that, make sure this .jar .gar is in the right place etc etc.") Trying to let a developer from another university know how to do these things is likely to be an issue, especially if they do not fully understand the complete picture. Perhaps, the more demonstrations and applications built with Shibboleth access then the more can perceive the benefits of it. This is a complex environment to develop in and therefore, unfortunately, the software solutions are complex. The developers express some concern about this in the longer term though... "if it is too complex then folk might simply say, 'Forget about it!' (-- AlunEdwards DateTime(2006-06-19T14:23:25Z))

Point of vew of Service Providers

• See ServiceProvidersEvaluation. For final report, need to discuss issues like the following (taken from ServiceProvidersEvaluation).

  1. Is anonymous access to your databases acceptable? Or must you always know who is using your data?
  2. If anonymous access is unacceptable, why is this? e.g. is it mis-use of the data which concerns you so an audit trail is required, or is it that the data is only available for users from bioinformatics centres of subscribed institutions?
  3. If you must know the identity of the user, would it be sufficient to know that the user is a legitimate researcher from a life sciences department of a subscribed institution, without actually knowing his/her name?