Recommendations for Policy Management and Exchange

Introduction

Access policy management and the 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's 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.

• http://users.ox.ac.uk/~markn/wikifiles/fosterAMpolicy.png

  (Currently reproduced without permission - from [http://www-fp.mcs.anl.gov/~foster/Talks/051206%20SOS%20Melbourne.ppt Ian Foster's talks site] (from a talk given in Melbourne on 13 December 2005, and repeated in Jan and Feb of 2006).

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:

• The site itself

  • This may also be considered as either the resource or a particular service where there is a clear ownership.

• The policy of that site with respect to a particular community

  • e.g. the site may decide to grant trivial access to any user, but to grant deeper access to members of a particular community.
• The policy of the community itself
  • The community may control access in different ways to different types of users, or it may restrict access to its users if it sees it as being inappropriate for them.

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

Anchor(shibboleth))

Shibboleth

Shibboleth is well placed to provide an infrastructure in which to manage and deliver attributes needed by access 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 (and advertised) at the federation level.

• We should also note that the [http://www.switch.ch/aai/ SWITCHaai] initiative in Switzerland also has a system of managing the 'advertising' of the SP's authorisation policy (or at least the required attributes) at the federation level. SWITCH calls this its Resource Registry and this is already in production for the Higher Education users in Switzerland. The list of resources and this meta-data is published at the federation level within the federation metadata file. However, SWITCH predicts that keeping all of this information in the one file will eventually lead to scalability problems and may move to publishing such information in many files. With regard to the advertising of the attributes required by the SPs, this may - possibly - eventually resemble something approaching the method adopted by the MAMS initiative.

In these initiatives it is possible to impose local institutions' (or communities') access 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.

• {{{ OO OO Proper diagram to follow soon! }}}

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

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:

• sheer numbers of users (lists being too long)
• distribution and refreshing of the lists (every day? every hour?)
• the dynamic nature of the lists (users and privileges change, as well as the policies regarding which groups of users should have access to each resource)
• the lack of an easy way of managing ad hoc, temporary or highly dynamic groups of users

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 [http://www.globus.org/security/overview.html 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:

• VOMS usually issues Attribute Certificates (ACs)
  • CAS does not issue ACs but issues proxy certificates for the user, with authorization attributes within extension fields in the certificates

• Conceptually CAS stores permissions (asserting, for example, that a user should be able to access a resource) whereas VOMS is concerned with groups or roles and, technically, leaves the access decision to the resource owner/administrator.

  • This is a subtle difference and it would appear that this difference could be trivially semantic, rather than a technical hurdle.

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:

• VO/community
• grid policies
• individual site/resource policies

[XXXX could do with more detail regarding G-PBox].

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:

• a user's digital certificate is hidden from him behind an apparently Shibboleth-only access management interface
  • or
• a (conscious) digital certificate user may keep a copy of her certificate or a proxy certificate within a myProxy server that has been Shibboleth-enabled
  • or
• a user does not ever hold a digital certificate and performs actions through a Shibboleth-enabled portal

Is there a danger of mixing trust models?

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/access 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.

Shibboleth should help with VOs

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 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, two campus grids. The access policies for a campus grid may, typically, be far less complex, but would have the potential to be as fine grained as in the IES example above. The major difference is that the ownership of the grid resources and the management of the access 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 appear to be in 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 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 IdP AA is instructed by the user that he is a member of VO x (required by a particular service) and the home AA queries the VO AA server and 'pushes' the signed attributes to the service with the other Shibboleth attributes and the authentication assertion.

• The IdP authenticates the user, passes some attributes to the service along with the authentication assertion and the service queries the VO AA server independently, in a 'pull' manner.

An advantage of the first mechanism is that it could - in theory - be made to work with solutions such as VOMS, CAS and myProxy where the attributes could be inserted into fields within attribute certificates or proxy certificates.

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 its use with the grid could mean that privacy is could be maintained but yet a rogue user could still be traced and her activity quickly suspended 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)] 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 in a policy considered at a higher level than that of the VO membership.

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:

• attribute certificates (e.g. VOMS, possibly PERMIS)
• proxy certificates with attributes stored as extensions (e.g. CAS)

• direct ["SAML"] assertions from a Shibboleth-enabled AA (e.g. GridShib)

• ["XACML"] requests from a 'policy repository' (similar in concept to AA, e.g. G-PBox)

  Note that the assertion of attributes between a Shibboleth AA and a VOMS server has been carried out by the GridShib project as a proof of concept. It is now being taken up by another project at [http://www.switch.ch/aai/ SWITCH].

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 Information Environment] communities and there are some implementations where Shibboleth has been used alongside PERMIS on grids (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:

• the writing of access policies by end users and home organisation administrators
• the writing of access policies at the resource/service
• the issuing of attribute certificates to convey the authorisation attribute information

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

The developers of the ShARPE tool chose to publish the authorisation policies of the service providers (SPs)in XML files then held at the Shibboleth federation level. This is described within the main [#shibboleth Shibboleth] section above and should assist sites in supporting their users and also service providers in having transparent access management policies. The creation of these XML files by the SPs should, in theory, be able to be carried out by the PERMIS tools.

Therefore such 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 service description file, as advocated by ShARPE. The VO community can further effect policy through the decisions of who (or what) is allowed to be listed within its VO server.

Within the Shibboleth arena, the solution proposed by ShARPE in managing the Attribute Request Policy (ARP) allows local (organisation) 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.

Policy discovery

As the [https://mams.melcoe.mq.edu.au MAMS] initiative work in producing the ShARPE tool suggested the 'advertising' of the service description file at the Shibboleth federation level, policy discovery may be eased. This is an intelligent approach so that those who have to support users and maintain VO lists are able to discover the authorisation policy of services/resources. There are those who may think that these policies should remain hidden. However, this gives rise to the danger of security by obscurity: it is better to advertise your policy to everyone and to trust a finite set of attribute authorities and other VO servers than to remain obscure and to trust almost everyone.

Silent failure due to authZ refusal

One problem that relates very closely to policy discovery is that of silent failure at the Policy Enforcement Point- or Policy Decision Point. In this situation, the user authenticates and her authorisation-supporting attributes are passed to the service provider. The result may be that the user does not have the right privileges and she is not authorised to enter. The authorisation result is actually "no" or "false" but no feedback is given. This can cause great headaches for both the end user and of the local support for those users.

• The [http://labserv.nesc.gla.ac.uk/projects/dyvose/ DyVOSE] project discovered just this issue when using PERMIS to protect multiple resources. The project had a set of users, divided into two major groups. Group 1 should have access to Resource A and the Group 2 should have access to Resource B (and resources A and B are very closely related). The membership of the groups was dynamic; that is, users can be members of Group 1 on one occasion and of Group 2 on another. Thus the user does not necessarily know to which group he belongs at the present time. Ideally, the Policy Decision Point should be able to say, "you're not allowed access to Resource A but you are allowed access to Resource B: welcome in!". However, if the user, or client application referring the user, tries to connect the user to Resource A, a silent failure could result.

There is therefore the danger of having to write all of the access management logic into both the referring application (or portal as it was in the DyVOSE project case) as well as at the service provider (resource). Therefore, policy discovery may need to be a little more intelligent in such cases.

Conclusion

There is a fine set of tools and methodologies currently emerging for policy management and exchange. However, to date, the needs of the [:Information_Environment information environment (IE)] have been relatively simple. This is changing, however. The needs of the grid community has long been acknowledged to be far more complex, but sophisticated solutions - above those of lists of user DNs in grid mapfiles - have been slow to emerge.

Shibboleth should be a promising mechanism to bridge between the grid and IE worlds, where most local identity providers are concerned. The approach of the [http://gridshib.globus.org GridShib] project has pioneered the concept of the grid lookup of user attributes based in a Shibboleth attribute authority.

Many of the grid users of tomorrow are likely to access grid services through tightly-controlled portals, as the [http://www.brc.dcs.gla.ac.uk/projects/bridges/ BRIDGES] and [http://labserv.nesc.gla.ac.uk/projects/dyvose/ DyVOSE] users do now. Thus a vast number of users are not required to interact with complex or otherwise onerous grid procedures. Their access can be managed by the grid portal and the resources devolve at least the authentication step to the portal. This is a highly scalable mechanism and no bridging of client-certificate-to-Shibboleth is necessary.

In this short introduction, we have avoided entering into a long discussion of possible combinations of technologies and ideas. As exemplars, 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, in theory, VOs). The ShARPE work has also shown how grid sites/resources could advertise their authorisation policies via the Service Description file. The [http://grid-auth.infn.it/docs/voms-FGCS.pdf VOMS], [http://www.globus.org/grid_software/security/cas.php CAS] and [http://infnforge.cnaf.infn.it/gpbox/ G-PBox] initiatives have shown how virtual organisations may be managed in the grid world, although some confusion is apparent when the concept of VO - with regard to authorisation decision - is muddied by the expectation of resource sharing. The GridShib project has begun to show how the VO can be managed as a Shibboleth attribute authority. The [http://www.permis.org/en/index.html PERMIS] toolkit is providing means by which to manage and edit these policies, both in the grid arena and the [:Information_Environment IE], and the work in the latter is complemented by the ShARPE attribute release policy editor.