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]).

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

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

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

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.