Introduction

The Shibboleth infrastructure works on the assumption that a user's home institution will both authenticate the user and provide the user's attributes for authorisation. This assumption is valid in Shibboleth's primary application areas, for example, obtaining publications from Elsevier. The user's home institution (or identity provider IdP) has a long term relationship with the user, and with the Shibboleth service providers (SPs). The home institution stores the user's long term attributes in its central databases. These attributes include such things as: name, date of birth, department, salary scale point, login id etc. and a selection of these, such as eduPersonPrimaryAffiliation, can be made available to Shibboleth SPs for authorisation. The user's home institution typically does not store the user's short term attributes that change on a day to day basis, as the administrative effort to maintain these would be prohibitively expensive. Nor does the user's home institution typically store authorisation attributes needed for access to the remote resources of virtual organisations (VOs) and research groups etc. since it is not authoritative for these.

Virtual organisations (VOs) are often much more dynamic and much shorter lived than a user's affiliation to his home institution. In fact, we are trying to move towards the situation where VOs can be dynamically created and destroyed with a minimum of effort, and may last for less than a day. The management of these VOs must be delegated to the people who are part of them. It is inconceivable to think that a university's central administration would be responsible for adding attributes about a user's VO memberships to its central databases on a daily basis. Consequently tools such as VOMS have been introduced which allow a VO manager to create his own database and to record in there the attributes of the various VO members. Unfortunately, when Grids and Shibboleth are attempted to be linked together we hit the problem that some attributes are in the user's home institution and some are in the VO database, and both are needed for authorisation. SWITCH has already recognised this problem, as has the MAMS project and GridShib. SWITCH is now working on a solution for adding Shibboleth attributes into VOMS. However, this includes only two attribute sources. SWITCH does not plan to add support for more attribute sources within the time scale of their work in EGEE-II. The GridShib solution is worse, and only uses attributes from the Shibboleth IdP. However, limiting the problem domain to just one or two attribute authorities is short term thinking and does not provide a complete or general enough solution to the problem space. For example, medical grids already need to consider attributes from other authorities, such as the General Medical Council (GMC) which issues GP attributes to doctors.

We have enhanced Shibboleth so that it is capable of returning a referral that allows the PERMIS authorisation software to pull information about additional user accounts at other IdPs. This user account information can in turn be used to pull additional authorisation attributes. This allows us to accept attributes from multiple attribute authorities including the user's IdP, VO management authority, professional society, financial authority and other relevant authorities required by the SP, so that integration with Grids will be much easier to accomplish, and much more flexible than now.

We have been working with acknowledged international experts in this area including the Terena EMC2 working group and the liberty Alliance Consortium in order to produce a Liberty Alliance based protocol specification ), for collecting attributes from multiple authorities that will be using Shibboleth developed by the Internet2 consortium. We have now built a nAA-PIP for PERMIS that acts as a new Attribute Repository that is capable of pulling the different attribute assertions from the different authorities and merging them all together under the same identifier, ready for passing to the PDP for an authorisation decision. This Attribute repository has been combined with a standalone PERMIS authorisation server that accepts standard SAML authorisation decision messages to make it accessible to any Grid Client that wishes to call it.

We have created a Liberty Alliance profile that can either be implementated as a push or pull protocol and we are hoping to have this protocol standardised by the liberty Alliance Consortium in the near future. (A Liberty Alliance profile is composed of multiple protocols which themselves have bindings.) Both push and pull have their advantages and disadvantages. Either way, the elegance of our proposal is that in both cases it does not need to alter the integration or configuration of existing PDPs at the SP site. Existing PDPs such as PERMIS or XACML can be used as is with their existing interfaces. But they will now be given a richer set of user attributes, validated by the nAA-PIP, from which to make more effective access control decisions. Furthermore, our proposal does not need to alter the integration work being done at in the SHEBANGS project, since SHEBANGS is primarily concerned with enabling Shibboleth authentication for grids. Our work will complement that of SHEBANGS by providing a Shibboleth multiple AA collection mechanism that will take over after SHEBANGS authentication has finished and prior to PDP decision making taking place. However, as noted in the FUSINGS proposal from Wallom and Pickles, standard Shibboleth mechanisms cannot work in scenarios where the user's web browser is not available. Therefore FUSINGS proposes to build a multi-IdP collection client based on the protocols specified in this proposal, and to insert this bag of credentials into a VOMS proxy certificate, for pushing to the nAA-PIP for validation. FUSINGS therefore complements our proposal perfectly, and will implement the protocols we will define and push the result to the nAA-PIP that we will build.