Guanxi vs Internet2 Service Provider module

Notes on the choice of Shibboleth Service Provider module to use with Sakai: Guanxi or the standard Internet2 offering?

Contents:

Contents

The problem with Sakai and Shibboleth
Guanxi vs Internet2
1. Guanxi
2. Internet2 Shibboleth SP
References

1. The problem with Sakai and Shibboleth

(Text mainly adapted from SakaiVre/PlanningProgress/20060807.)

It seems that the Sakai authorization structure is a poor fit with Shibboleth attribute delivery. Alistair Young has encountered similar issues with his Guanxi development, and is taking the approach of constructing a "pod" of data from Shibboleth assertions, suitable for responding to Sakai authorization queries.

A copy of the main elements of the discussion of Sakai's authentication/authorization model on the Sakai-dev discussion list can be reviewed here:

This discussion has clarified the scope for interaction between Sakai authentication, Sakai authorization and Shibboleth. Unfortunately, it seems that it is not a simple matter to write Sakai providers that simply answer authentication and access control queries on the basis of available Shibboleth attributes, which is what we were looking for. The reason is that Sakai does not provide access to the incoming request context where the Shibboleth attributes are provided to an application, but rather assumes that the provider module has access to all relevant information about authorized users at all times. But Shibboleth provides this information in HTTP headers when a user attempts to access a controlled resource, and does not provide a general lookup facility - this design is driven in part by privacy concerns. It seems that Sakai, being primarily responsible for handling incoming HTTP requests, assumes that it has extracted all the useful information, and does not allow that provider components might also need access to the request context.

We believe (and plan to demonstrate) that basic authentication linked to Sakai's internal access control is possible, because Sakai extracts and uses the Shibboleth-provided user identifier using the Servlet APIs, and can use that to kety into its own internal user database. The difficulties arise when we want to use Shibboleth-supplied role information to make access control decisions. Looking further to the future, a separate access control infrastructure may be workable, if it maintains a list of all authorized user identifiers.

2. Guanxi vs Internet2

The discussion that follows is concerned only with the Shibboleth Service Provider module that might be used to enforce access control.

We intend to use the Internet2-based Identity Provider (IdP) and Attribute Authority (AA) deployed by the SPIE project with our own Sakai demonstrator. The Service Provider (SP) module intercepts (or is otherwise invoked to handle) requests to an application, and communicates with the IdP/AA modules as needed to obtain user authentication information for the incoming request. See the Shibboleth architectiure [4] for more details.

2.1. Guanxi

(See also reference [3].)

Advantages:

Guanxi development is specifically addressing the Sakai authorization problem by filtering incoming requests and reconstructing a "pod" of user information that can be queried by a Sakai provider module usinbg a private (i.e. non-Sakai) API. This is a non-trivial development, so it would be good to leverage this.
Guanxi has a different model of Shibboleth SP provision that allows a single SP joined to a Shibboleth federation to handle requests for multiple applications. This means that the tricky work of installing an SP module and joining it to a Shibboleth federation can be undertaken just once, or even outsourced, and relatively simple, almost configuration-free, "guard" modules used to control access for individual applications. This approach does have a potential disadvantage that it weakens the Shibboleth/SAML end-to-end trust model, and requires the central SP module to be trusted and to have adequately secured communication paths with its guard modules. But the Guanxi approach does not force a weaker trust model, just allows it. Also, there is a substabtial body of opinion that regards "the best as being the enemy of the good" when it comes to security [1].
Guanxi is a pure Java SP solution, which may make it easier to deploy for use with Sakai.
A Guanxi implementation would serve the wider goal of multiple interoperable implementations for network standards, which are well recognized as helping to achieve a higher quality of technical specification standards.

Disadvantages:

Guanxi is a small-team development, and it is not clear how well supported it will be in the future. As yet, it is not obvious that there is or will be a significant supporting community.
It's not yet clear whether or not Guanxi will track Shibboleth 2 developments, which may in future be important fpor providing Shibboleth mediated access to non-web-facing services (e.g. grid services).

2.2. Internet2 Shibboleth SP

(See also reference [2].)

Advantages:

Internet2 Shibboleth is a substantial project, apparently with a number of active developers and substantial ongoing support.
Internet2 Shibboleth software is widely used and has been use-hardened though a wide range of implementations.
The Internet2 Shibboleth SP code is not restricted to deployment with Java applications, so is inherrently more widely applicable. This may have consequences for the number of different software sub-systems that need to be supported in multi-application sites (like Universities).

Disadvantages:

The Internet2 community have a view of Shibboleth that is not a good match for Sakai access control (and maybe other applications), and do not currently have plans to develop bridging software, either to SAKAI, or to the pool of applications that make similar access control assumptions. That said, Internet2 community are concerned with the problem of Shibboleth-enabling Sakai, and have been canvasing us to implement a solution for Sakai that works with their SP module. Thus it may be that the Internet2 community and friends eventually come up with a solution that deals with the Shibboleth/Sakai mismatch, maybe in a fashion that also serves other applications with similar requirements, but this possibility has be be recognized as pure speculation.
The Internet2 community appear to be actively promoting their own implementation of the standard over the Guanxi implementation. This casts doubts on their intentions to have genuine interoperability within the Shibboleth service (as opposed to between the Shibboleth service and other software components, which it is clear that there is genuine interoperability).

3. References

The Internet is Too Secure Already, Eric Rescorla, RTFM, Inc. (Prtesented at USENIX Security 2003) http://www.rtfm.com/TooSecure-usenix.pdf
Internet2 Shibbleth project - http://shibboleth.internet2.edu/
Guanxi project - http://www.guanxi.uhi.ac.uk/index.php/Guanxi
Shibboleth architecture - http://shibboleth.internet2.edu/draft-internet2-shibboleth-arch-v05.html

-- GrahamKlyne 2006-08-25 10:21:12