Page completed and frozen

Note that detailed notes exist on private pages at DeveloperEvaluationNotes (project team only).

Evaluation of the technical development

In February 2006 the NeSC developers from the BRIDGES and DyVOSE projects answered the questions of the ESP-Grid project who evaluated their experiences, expectations and the problems they encountered during the development (see also NeSC_Shibbolized_Resources). The developers included:

Contact details confirmed at http://www.nesc.ac.uk/nesc/team.html with biographies.

The developers considered specifically the Shibbolizing of the BRIDGES and DyVOSE web portal, and all the myriad of steps which had to be completed to make this work (including PERMIS - Privilege and Role Management Infrastructure Standards Validation), and identified for us:

  1. What did you find difficult?
  2. What makes Shibboleth a good solution for accessing a service like BRIDGES/BLAST or the DyVOSE data sources?
  3. Which issues can you see in a real-world production of this with 100s of users, maybe a commercial data provider, issues for the future etc.?
  4. What scalability issues can you identify?
  5. How could the access control you've implemented be subverted by e.g. a bad person, or by an expert trying to get round the system for their own convenience, or by a careless user?

Scenario

To spark some real-world flavour a scenario was contrived: the developer was asked to imagine he has by chance met a manager of a faculty resource in the corridor, and he/she knows of the developer's experience and naively thinks he's the person who can just "Shibb their target..." - "This afternoon, if you've time?"

What did the developers find difficult?

In no particular order here is a summary of what the developers recorded as being difficulties during the development:

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.

Client operating system

Security and single sign-on (SSO) will be greatly improved if in future Shibboleth works with the operating system and not Internet browsers.

The portal container

Shibbolizing the portal container proved impossible. Servlet containers are used to host the BRIDGES portal on Tomcat, but Shibboleth protects resources hosted on Apache. It is very difficult to force the requests that come for the portal container through the Apache Shibboleth module first. The developers used the mod_jk (plug-in that handles the communication between Tomcat and Apache) so that Shibboleth can indirectly protect the Tomcat services. (Because mod_jk allows Apache to wrap Tomcat services, it will be difficult for a hacker to access a Tomcat service directly.) The developers are pleased that there does not seem to be a performance issue for using mod_jk as a wrapper/bridge. They strongly recommend that Tomcat is necessary to Shibbolize portals that require a Servlet container.

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/.

Find an established federation

Input from an established federation meant targets could be Shibbed in days rather than weeks. In BRIDGES' case, the SDSS Development Federation at EDINA (Shibboleth Development and Support Services (SDSS)) normally responded to queries within 24 hours. Also the Identity Providers (IdPs) and Service Providers (SPs) could be configured and tested separately before joining them together.

Cookies

To provide authentication services for local users, the developers implemented Identity Provider - IdP (authentication site) using LDAP. The WAYF service (Where Are You From) stores a cookie on the user's Internet browser to identify their IdP for single-sign-on (SSO) purposes and for subsequent access to other service providers in the federation. But if a user turns off cookies in their browser then SSO cannot be achieved. Also if a user switches browser, say from Microsoft Internet Explorer to Firefox, they have to re-authenticate.

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).

Why Shibboleth?

In no particular order, here is a summary of why the developers think Shibboleth is a good solution for accessing a service like the BRIDGES or DyVOSE portlets:

Adding other projects to the infrastructure was not difficult

It is very easy to tailor attribute release/acceptance once Shibboleth is running. Adding other projects to the developers' infrastructure was not difficult. The developers interfaced Shibboleth with GridSphere successfully, and bypassed the GridSphere login to use the mod_auth_ldap authentication.

Single sign-on (SSO)

The single sign-on (SSO) capabilities of Shibboleth are desirable in the Grid context of BRIDGES. Users without computing expertise will become more and more reliant on their organisation's usual (and familiar) authentication method and credentials.

A Scottish grid

Shibboleth looks quite promising especially for an academic environment where we would want to, say, give access to an application for anyone in Scotland as part of a Scottish grid. The developers would then not have to worry about managing their own user base but instead have arrangements with all other Scottish universities and institutions. If a user's distinguished name (DN) can be extracted programmatically from within the portal, offending users could be tracked and hopefully dealt with at their home institution. The developers are already able to trace user activity and user origin/details, (as an end resource the National Grid Service (NGS), for example, dictates this to the developers under the existing agreement).

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".

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.

Real-world production

Here are the issues (in no particular order) which the developers identified for a real-world production in the future:

PERMIS (Privilege and Role Management Infrastructure Standards Validation)

PERMIS is useful as a policy engine that that ties in with Globus services and interprets SAML (Security Assertion Markup Language), but its implementation requires a complex supporting infrastructure of specific technologies such as different LDAP (Lightweight Directory Access Protocol) versions, that makes it quite inflexible and time-consuming to set up and operate. This may mean that it could be an unattractive solution for some. Also the interface PERMIS provides - in this context - is limited. If a Globus service method protected by PERMIS fails to run, an Authorisation Exception occurs. There is no handle, such as a parameter saying "PERMIT/DENY" that the developer can use to control the flow. In addition, although technically PERMIS is authentication-agnostic it does require a local LDAP server back-end that matches the DNs (distinguished names) used in the authentication tokens (certificates). If PERMIS is implemented poorly, the developers warn that there is a danger here of the "illusion of security".

Scalability

It is hard to build a system where you have no real estimate of your potential user numbers e.g. when you open things to big institutions like other universities. You would ideally want to strike a balance and devise a system which handles roughly the load you expect, but with larger numbers of potential users the load becomes harder to estimate. Building extensibility into the system from the start would be the answer here. NeSC Glasgow is looking at performance aspects of portal technology which will feed into any investigation of high-load Shibboleth use now the grid's user base is increasing. Other specific scalability issues were identified:

Security

The developers considered the following when asked to think how could their implementation be subverted (for example by an attacker, or by an expert trying to get round the system for their own convenience, or by a careless user?):

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.

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. 1

Public computer

If a user on a public computer does not log-out of a session he has requested to be remembered by the IdP, it is possible that someone can re-use his session to gain access to other federation sites, which would be the same problem as if his password were to be stolen. However the public computer problem has a time limit: the rogue user, presumably, will have to leave the computer (and she cannot take the credentials with her, and the cookie/credential will shortly expire, anyway).

Data in headers

Ideally, users' attribute certificates are returned as SAML responses to the service provider (SP). The portals could have the IdP release attributes using the LDAP server the developers set up. The identity handle is used to query the LDAP for user attributes. Because of the way GridSphere (Portal technology) handles data in headers, attributes are returned as short strings to the portal. This currently is not secured, but the developers are working on a better solution such as SAML assertion compression/hashing.

Authorisation using attributes

The BRIDGES portal uses attributes to interact with grid services e.g. BLAST. The developers think there are no performance issues or further security risks from this. They assert that the security questions really are: What do you do with attributes once exchanged at the service providers' side? What type of PMI (Privilege Management Infrastructure) does the service provider have? Can the PMI be driven with attributes such as Roles or distinguished name (DN)?

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."

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!'

Note that detailed notes exist on private pages at DeveloperEvaluationNotes (project team only).

  1. The DCOCE project http://www.dcoce.ox.ac.uk/ found that user experiences with client digital certificates should not be onerous as each problem encountered should be relatively simple to resolve. However, there are some issues that are either difficult to resolve, or the willingness is not there in the software developers or the operating system vendors. The project concluded that most of the small issues were not being resolved and therefore the difficulty of using client digital certificates for the majority of users is prohibitively high. (1)

ESPGRIDwiki: DeveloperEvaluation (last edited 2013-05-17 16:26:46 by localhost)