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 toconsider future usersand tobuild grids and grid applicationsthat 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.

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.

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.

Consider high(er) privacy use cases for the grid

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?