Recommendations for Policy Management and Exchange

Introduction

General intro.

Security policies and access policies

Please note that where the term "security policy" is used in this document, it refers more accurately to "access policy". This is to exclude security matters such as operating system patches, for example, and restricts this document to access management issues

State of play at the moment

At the moment many grids merely use lists of Distinguished Names (DNs) in grid mapfiles to drive authorisation decisions (e.g. National Grid Service in the UK).

A few grids are more sophisticated, e.g. the Open Science Grid in the USA uses VOMS servers, but the level of sophistication is still limited: the VOMS server is mostly a more scaleable way of maitianing lists of users and to which group or VO they belong.

These approaches are sufficient when the overall numbers of users are low (for example when user numbers are in the 100s), but as the total numbers of grid users grows, some for of role-based access control will be necessary.

Shibboleth

Shibboleth is well placed to provide an infrastructure in which to manage and deliver attributes needed by security policies to make authorisation decisions.

Ref. MAMS SHARPe - able to impose local institutions' (or communities') security policies upon sets of users. [expand?]

In this way, we can see Ian Foster's venn diagram as having another component:

However, there is nothing explicit in the original Shibboleth architecture to deliver the attributes needed to the grid environment

Grid

Mention VOMS again. Mention also G-PBox.

Best solution probably comes from the GridShib project - their extension to the Globus Toolkit to use SAML to discover the attributes.

Talk about other VOMS competitors...

Hint that it sounds like GridShib (name of GT Module xxxx) and SHARPe have it sorted.

But nothing so far has solved the VO issue. Nevertheless, solutions are being designed whereby the VO could be represented by another Shibboleth attribute authority (AA). Another alternative, would be to expand the implementation of VOMS to include role attributes as the SHEBANGS project plans to do.

VOs

In the absence of a widely accepted definition of 'Virtual Organisation' (but see xxxx), the following two examples illustrate the types of VO that are considered within the information environment and grid realms.

VO based on users

A VO may be dynamic and externally controlled and maintained. For example, "member of the International Ecological Society". The IES may or may not own grid resources itself but there could be a policy in existence that enabled resources/services on a grid to members of the IES. This could be more fine grained: it could be dependent on the status of the individual within the IES (for example, full member, associate, student etc.). The membership will change constantly, as will the categorisation/status of its members.

VO based on ownership

Another, contrasting, type of VO is based on the ownership of the resources themselves. For example, a campus grid. The access policies for a campus grid may, typically, be far less complex, but would have the potential to be as fine grained as the IES example above. The major difference is that the ownership of the grid resources and the management of the security policy may coincide.

Other VOs could be envisaged whereby different organisations are sharing resources and there is some agreement between them. However the VO came into existence, the above two examples may contrast but, ultimately, from an authorisation-decision standpoint, the VOs are really lists of user-members. Resources or services need to find out whether the user is in the VO membership list, and may possibly need other information about them from the VO.

Policy management and enforcement

Tools are emerging for the management of access policies. PERMIS has various advantages as it has been developed for both the grid and the information environment communities and there are some implementations where Shibboleth has been used alongside PERMIS (e.g. DyVOSE etc.xxxx)

[bit more about PERMIS]

Good idea by SHARPe developers to publish the AuthZ policies in an XML file at the Shibboleth federation level to assist sites in supporting their users and also service providers (SPs) in having clear access management policies.

The policies can be managed at the SP level by PERMIS and these policies represent the interests of both the resource/service owner and the VO community and may be advertised/expressed in a SP description file, as advocated by SHARPe xxxx.

In Shibboleth terms, the solution proposed by SHARPe in managing the ARP allows administrators to impose an access policy that can differ from that of the SP and could represent the interests of the insitittion or of the community in general.

Both solutions are standards-based and largely clearly expressed in XML.

A bit about DyVOSE approach xxxx.

And more about policy discovery - DyVOSE example??

Conclusion

Emerging: a good set of tools and methodologies. Quite new and not widely implementated.and means are required to bridge between the grid and the IE worlds.