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:

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:

Disadvantages:

2.2. Internet2 Shibboleth SP

(See also reference [2].)

Advantages:

Disadvantages:

3. References

  1. The Internet is Too Secure Already, Eric Rescorla, RTFM, Inc. (Prtesented at USENIX Security 2003) http://www.rtfm.com/TooSecure-usenix.pdf

  2. Internet2 Shibbleth project - http://shibboleth.internet2.edu/

  3. Guanxi project - http://www.guanxi.uhi.ac.uk/index.php/Guanxi

  4. Shibboleth architecture - http://shibboleth.internet2.edu/draft-internet2-shibboleth-arch-v05.html


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

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.