Recommendations for Policy Management and Exchange

Introduction

Access policy management and exchange of those policies is an area of growing importance. Standard methods of managing policies and advertising or exchanging them are crucial to an environment where the numbers of users are likely to grow vastly. This certainly includes grid environments, but is not limited to those environments. It is tempting to assume that the grid is a special case in terms of access management, but is this actually the case? Certainly the sharing of resources may be unique to grids, but when it comes to the authorisation decision, is the resource shared status, just one other attribute to be used within the access decision?

Security policies and access policies

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

Many policies, many owners

Ian Foster has summarised the policies of managing access to a resource (or a site) as in the following venn diagram.

In this way, we can see that the interests of the three groups are such that, often, only a small intersection may occur.

The three groups are identified as:

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 [http://www.opensciencegrid.org/ Open Science Grid] in the USA uses [http://grid-auth.infn.it/docs/voms-FGCS.pdf Virtual Organization Membership Service] (VOMS) servers, but the level of sophistication is still limited: the VOMS server is mostly a more scaleable way of maintaining lists of users and to which group or virtual organisation (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 form of role-based access control (RBAC) becomes necessary. RBAC may be a little too simplistic in this context: we are likely to need to be able to check whether a user (or other entity?) is a member of a VO and whether she has the role of 'full member' (for example).

Shibboleth

Shibboleth is well placed to provide an infrastructure in which to manage and deliver attributes needed by security policies to make authorisation decisions. Efforts are now appearing to provide software and interfaces with which to manage those attributes. For example, the [https://mams.melcoe.mq.edu.au MAMS] initiative has developed a tool known as [http://mams.melcoe.mq.edu.au/wiki/display/MAMS/Shibboleth+Attribute+Request+Policy+Editor+(ShARPE) ShARPE] (Shibboleth Attribute Request Policy Editor) in which the local institution is able to set any local policies that will affect its users' access to external (and presumably, internal) resources. A similar initiative, and one which has fed into ShARPE no doubt, has been pursued at Internet2 and is called [http://middleware.internet2.edu/signet/ SIGNET]. (See also [http://middleware.internet2.edu/dir/groups/grouper/ Grouper]). One particular item to note regarding ShARPE, is that this initiative has suggested the use of an XML Service Description file. This file effectively conveys something about the authorisation policy of the SP and the user attributes required for granting access to each "service level" provided by the SP are given in this file. The file is public and held (or advertised) at the federation level.

In these initiatives it is possible to impose local institutions' (or communities') security policies upon sets of users. However, additionally, the user can impose his own privacy requirements on the exchanges. For example, the user may not wish to reveal certain attributes about himself and this could restrict his access to certain sites (as those sites mandate the presentation of those attributes).

In this way, we can see Ian Foster's venn diagram as having a fourth set. That of the users' self-imposed restrictions.

Nevertheless, despite the great thought and extensive work of the Shibboleth community in this area, there are currently some restricting factors for the grid community in it's possible use of the Shibboleth software components:

  1. There is nothing explicit in the original Shibboleth architecture to deliver the attributes needed to the grid environment
  2. Currently, there are no widely used tools to enable non-HTTP access.
    • (But there are plans, I believe.)

  3. Similarly, attribute authorities (AAs) cannot currently be owned/managed by different organisations than those where the Identity Provider (IdP) is based: this poses difficulties regarding the use of the technology to enable VOs.

    • (Again, there are several plans/possibilities to address this deficiency).

Anchor(stateplaygrid)

Grid

Within the grid computing world, we have already mentioned that much access management is currently performed by each resource keeping lists of users in grid mapfiles. This clearly has scalability problems regarding:

There are several initiatives underway to tackle these issues. Possibly the best known of which is the [http://grid-auth.infn.it/docs/voms-FGCS.pdf VOMS] work. VOMS was developed by European Datagrid and Datatag collaborations to solve current LDAP VO servers limitations. Each VO has its own VOMS server and there is support for group memberships (including subgroups and roles etc.). VOMS is essentially a front-end to a (relational) database. VOMS can also be used for grid-mapfile generation, but it is normally used to create pseudo and attribute certificates that can be used by clients to make access decisions that are similar to role-based decisions (i.e. is this user a member of the VO?).

The Community Authorization Service ([http://www.globus.org/grid_software/security/cas.php CAS]) works in a conceptually similar way in that the VO (the "community") runs a CAS server. When a user who belongs to the VO wants to access resources served by the CAS, the CAS server issues a GSI restricted proxy credential to the user. This credential has an embedded policy giving the user the right to perform the requested actions. There are many more details regarding CAS at [http://www-unix.globus.org/toolkit/docs/4.0/security/cas/user-index.html#s-cas-user-introduction globus.org].

The main differences between CAS and VOMS are that:

Another technology in this area is [http://infnforge.cnaf.infn.it/gpbox/ G-PBox]. The drivers behind G-PBox are very much directed towards resource sharing. G-PBox utilises the eXtensible Access Control Markup Language ([http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml XACML]). G-PBox attempts to address the three separate policy areas of:

Shibboleth and Grid

There are potentially many ways in which the technologies provided-for and enabled by Shibboleth and those associated with grids could be combined. Probably the most advanced implementation to combine elements of Shibboleth with elements of grid access management is to be found within the [http://gridshib.globus.org GridShib] project. GridShib is an integration of the [http://www.globus.org/toolkit/ Globus Toolkit] and Shibboleth. The complete software package consists of two plugins, one for Globus Toolkit (to use SAML to discover the attributes) and another for Shibboleth (to provide the attributes to the grid SP). With both plugins installed and configured, a GT Grid Service Provider (SP) may securely request user attributes from a Shibboleth Identity Provider. There are two main GridShib scenarios: one involving the 'push' of authorisation-enabling attributes, and another of the 'pull' of those attributes. Both scenarios involve the authentication/identity assertion first via an X.509 digital certificate (via the usual Grid Security Infrastructure - [http://www.globus.org/security/overview.html GSI] - mechanism).

Other projects have used Shibboleth with grid applications and services. The [http://www.brc.dcs.gla.ac.uk/projects/bridges/ BRIDGES] and [http://labserv.nesc.gla.ac.uk/projects/dyvose/ DyVOSE] projects have worked with this (the ESP-GRID) project to enable portal-based access to grid services. The portal uses Shibboleth to perform the authentication and authorisation steps and the grid-based resources trust the portal. This is usable and scalable, but represents a different trust model to the one that usually applies to grid resources.

In a contrasting vein, the recently-begun ShibGrid and [http://www.sve.man.ac.uk/Research/AtoZ/SHEBANGS SHEBANGS] projects are beginning to develop solutions whereby either:

Both of these projects are aiming to ease the experience of digital certificate users. However, it is yet to be proved whether the combination of security mechanisms is appropriate or too risky. Shibboleth is based on a security model of machine to machine trust, whereas client-PKI is based on user to machine trust. Combining these two in such a manner raises great complexities, but may also give rise to great security risks. These risks have been largely avoided by the [http://gridshib.globus.org GridShib] project which enables identity assertion/authentication via certificate (i.e. user to machine trust) but uses a machine to machine interaction to learn about authorisation attributes.

One area where Shibboleth should be able to provide a good workable solution to grid applications is with VOs. This was one of the drivers of the GridShib project. The GridShib project saw that 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. See below for a section regarding VOs.

VOs

In the absence of a widely accepted definition of 'Virtual Organisation' (but see the ["VODefinition"] work within this wiki), 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.

For the sake of this discussion, VOs are assumed to be lists of users.

VOs and Shibboleth

One one level, the management of VOs, as lists of users with possible other attributes, would seem to be perfectly suited to the general Shibboleth model. However, the problem exists that the current version of Shibboleth (v 1.3) as well as the upcoming versions (2.0 and probably 2.1) consider the attribute authority to be owned by the identity provider (home organisation). If the Shibboleth mechanism allowed for multiple AAs to be queried then this would enable independent and ad hoc VOs to be created and maintained. It would simply be a matter of creating a VO server and registering this server with the Shibboleth federation. Two candidate mechanisms appear for the use of the VO server:

The disadvantage of the second mechanism is that it is difficult for it to serve the use cases whereby privacy is an issue. Although the relative number of such use cases is small, it is a design strength of Shibboleth to enable privacy, and it's use with the grid could mean that privacy is could be maintained but yet a rogue user could still be traced with the assistance of her home organisation.

Both of these mechanisms are being considered by the Shibboleth community and one or both may find their way into a future release of the software.

As noted above, the GridShib project considered the Shibboleth AA to be an attractive point from which to query attributes regarding users. However, the project is currently restricted in that the home organisation is expected to maintain the VO list of users.

VOs and grids

The Virtual Organization Membership Service ([http://grid-auth.infn.it/docs/voms-FGCS.pdf VOMS]), the Community Authorization Service ([http://www.globus.org/grid_software/security/cas.php CAS]) and [http://infnforge.cnaf.infn.it/gpbox/ G-PBox] mechanisms of grid-based VO management are described in the [#stateplaygrid State of play (grid))] a section above. There is a tendency for these mechanisms to conflate the need for authorisation (based on VO membership) at the point of the resource with the overall policy of resource sharing. These concepts should be separated where possible, although it is appropriate that they are brought together at some point.

The role of the VO to the grid service or resource is to provide supporting assertions of VO membership (as well as other attributes, where necessary). These assertions may take different forms. For example:

Many of these apparently competing mechanisms are sure to find their separate niches as they will be more suited to certain situations and users. Therefore, it is quite possible that mature grids could use all of these technologies for access management based upon VO membership.

Policy management and enforcement

Tools are emerging for the management of access policies. We have already mentioned [http://infnforge.cnaf.infn.it/gpbox/ G-PBox]. The PrivilEge and Role Management Infrastructure Standards Validation ([http://www.permis.org/en/index.html PERMIS]) set of tools have various advantages as they have 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. [http://labserv.nesc.gla.ac.uk/projects/dyvose/ DyVOSE] and [http://gridshib.globus.org GridShib]).

The PERMIS tools have been formulated to enable:

PERMIS is relatively mature in comparison with other such projects but does not yet enjoy a very wide install base and production-level implementations.

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

To avoid entering into a long discussion of possible combinations of technologies and ideas, we would like to highlight the work of the GridShib project in establishing that policies for attribute-based authorisation can work in the (Globus) grid context. The work of the [https://mams.melcoe.mq.edu.au MAMS] initiative, and in particular the [http://mams.melcoe.mq.edu.au/wiki/display/MAMS/Shibboleth+Attribute+Request+Policy+Editor+(ShARPE) ShARPE] tool has shown that policies can be managed by institutions, communities and users (and VOs, but see below). The ShARPE work has also shown how grid sites/resources can advertise their authorisation policies via the Service Description file. The PERMIS...