Technologies for Policy Management (as at May 2006)

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 grids, 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, the resource's shared status is just one other attribute to be used within the access decision.

Security policies, access policies, sites/services/resources

Please note that 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.

Similarly, we have used the term "sites/services/resources" frequently. In the literature, generally, "Sites" and "Resources" tend to signify (usually grid) nodes and machines. Services may be thought of as at a level higher than sites or resources, but all three concepts may require similar authentication and/or authorisation practices. This is why they have been grouped together.

The idea of access policy can be further subdivided. Some of the concepts within this document refer to 'authorisation policy' (the policy of the site/service/resource to guide its access management decision) and some concepts pertain to the 'attribute request policy' (regarding the attributes - e.g. role, status, affiliation - required for the site/service/resource to make the authorisation decision). Where it assists the reader, we have endeavoured to point out the type of policy that is relevant in context. In Shibboleth terms, there is also an 'attribute release policy' (the combined policy of the identity provider and user regarding which attributes are released to a site/service/resource). This is potentially confusing and so the use of abbreviations has been avoided.

Many policies, many owners

Ian Foster has summarised the policies of managing access to a resource (or a site) with the following Venn diagram.

• 

  Reproduced with permission from Ian Foster's talks site (Link is directly to the PowerPoint file and is 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. However the level of sophistication is still varied between the implementations. For example, the Open Science Grid in the USA and the Enabling Grids for E-sciencE project use Virtual Organization Membership Service (VOMS) servers. However, the VOMS server is often seen as merely a more scaleable way of maintaining lists of users and to which group or virtual organisation (VO) they belong.

The approach of managing lists of (named) users is 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). Such functionality has been enabled within VOMS since the first version and there appear to be VOMS implementations that are beginning to reach this level of sophistication.

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 MAMS initiative has developed a tool known as ShARPE (Shibboleth Attribute Release 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 has been pursued at Internet2 and is called SIGNET. (See also 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 the user attributes required for granting access to each "service level" provided by the SP (and therefore possibly something about the authorisation policy of the SP). The file is public and held (and advertised) at the federation level.

We should also note that the SWITCHaai initiative in Switzerland also has a system of managing the 'advertising' of the SP's attribute request policy at the federation level. SWITCH calls this its Resource Registry and this is already in production for 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 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, at least in a restrictive way (i.e. disallowing access to some resources). 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). An example of this functionality is the 'Autograph' interface being developed in parallel with the ShARPE tool where the user can edit and manage the release policies in this way.¹

• With the MAMS tools, the actual Attribute Release Policy for a user is manipulated in two stages. The ShARPE tool is used by Identity Management Administrators local to the user (for example librarians or registration officers) to enable (and therefore also restrict) the sites/service providers that groups of users can attempt to access. The user can then employ Autograph to select more restricted attribute release options, based upon her privacy requirements; thus restricting her access to some sites further. The resulting Attribute Release Policy is therefore the product of both of these actions (via ShARPE and then Autograph).

We can, therefore, see Ian Foster's venn diagram as having a fourth set: that of the users' self-imposed restrictions.

• 

  Diagram showing the sources of control of access to a particular resource or site. (The user may impose a further set of restrictions, probably due to privacy concerns).

The "Access granted by community to user" in the pure Shibboleth case (and where virtual organisations do not play a role - see below) is intended to depict the control of the local institution (the Identity Provider) over the access of the end user to certain resources. This control is a little fuzzy and difficult to depict, however. Where a resource requires a set of attributes to be passed from the Identity Provider (IdP) to it via Shibboleth, the local institution can deny access. Where a user is able to either bypass Shibboleth, (for example, by creating an account and relationship directly with the resource) or where the resource does not ask for any attributes, other than a temporary 'handle' from the Shibboleth IdP, it is either difficult or impossible for the 'community' or IdP to restrict access. Nevertheless, these illustrations assume that the resources (or Service Providers) approve of such multi-party access restrictions, and find them useful.

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 its 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 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:

• 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 VOMS (link is to PDF file) 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 can also be used for grid mapfile generation, but it is normally used to create 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 (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 globus.org.

With CAS, the emphasis is on a central 'body' making access decisions on behalf of sites/services/resources. However, CAS does not merely issue a simple permit/deny message: it issues signed authorisation decision statements, consisting of a tuple (subject, resource, action, permit). These tuples are received by the client and 'pushed' to the site/service/resource.² The validities of the client and the CAS server can therefore be checked within the assertion.

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 authorisation 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 fundamental difference of real-world implementation. VOMS is oriented towards RBAC, whereas CAS supports a form of discretionary access control.

Another technology in this area is Grid Policy Box (G-PBox). The drivers behind G-PBox are very much directed towards resource sharing. G-PBox utilises the eXtensible Access Control Markup Language (XACML). G-PBox attempts to address the three separate policy areas of:

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

The G-PBox and VOMS teams are working together in order to establish a suitable authentication/authorisation framework for a production VO-oriented Grid. In this development, VOMS is considered as the attribute authority: VOMS is used to manage groups to which a user belongs, as well as the roles a user is allowed to take and therefore the attributes that the user should present a resource owner. G-PBox manages the policies. The combination of G-PBox/VOMS should therefore enable the VO to build groups, assign roles and to associate policies to each group and role. This can be carried out dynamically and is also designed to ease the implementation of the agreements with the resource owners.

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 GridShib project. GridShib is an integration of the 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 - GSI - mechanism). To date, only a 'pull' profile has been implemented as a clear use case for 'push' has yet to be identified.

The GridShib mechanism effectively parses the attributes that are asserted and makes a decision by comparing them to an access control list that contains the permitted attributes. This is of somewhat limited functionality as it does not allow decisions based on combinations of attributes (e.g. member of University X and project Y), or on dynamically changing conditions, such as the time of day, the amount of resources being consumed etc. However, the GridShibPERMIS project has been established to enhance the functionality within GridShib to improve the policy-driven role-based access control decision making for grid jobs. PERMIS is described within the Policy management and enforcement section below.

Other projects have used Shibboleth with grid applications and services. The BRIDGES and DyVOSE projects have worked with this (the ESP-GRID) project to enable portal-based access to grid services. The portal uses Shibboleth to mediate 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 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 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 security risks. These risks have been largely avoided by the 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. However, some of the advantages (e.g. effective anonymity) of Shibboleth are lost with GridShib as the authentication via certificate explicitly identitifies the user.

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). The SHEBANGS project plans to use VOMS with role attributes alongside Shibboleth to enable a crossover between the identity management worlds of grids and information environments (IEs).⁶

SWITCH and EGEE are also working together at the moment so that VOMS servers will be able to query local institutions' Shibboleth AAs. See below for a section regarding VOs.

VOs

Issues of the definition of VO

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 (IE) 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 (IES)". 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. By whichever means or purpose 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

On one level, the management of VOs, as lists of users with other possible 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 AA to be owned by the IdP (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. A disadvantage in comparison with the second mechanism is that, from the IdP's perspective, it makes the functionality of the local AA more complex.

A 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 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 was restricted in that it seemed unreasonable to expect the home organisation to maintain the VO list of users. For this reason, the GridShib project, teamed up with myVocs ⁸. myVocs is a virtual organization collaboration system which presents itself as a Shibboleth SP so that other services can rely on it to ensure that the user has been authenticated and the myVocs servers assert the attributes that the SPs in the VO need to make their authorisation decisions.

The MAMS team are also working on methods of extending the functionality of AAs at home organisations/identity providers to become Authorisation Service Providers, rather like CAS or VOMS in concept, to effectively be AAs for VOs. (This should also be applicable in the grid context - see VOs and grids below).

VOs and grids

The Virtual Organization Membership Service (VOMS), the Community Authorization Service (CAS) and G-PBox mechanisms of grid-based VO management are described in the ''State of play (grid)'' section above. When considering decision points at each site/service/resource, there is a tendency to conflate the need for authorisation (based on VO membership) with the overall policy (between organisations) 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, 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 is being taken up by another project at 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 G-PBox. The PrivilEge and Role Management Infrastructure Standards Validation (PERMIS) set of tools have various advantages as they have been developed for both the grid and the IE communities and there are some implementations where Shibboleth has been used alongside PERMIS on grids (e.g. DyVOSE and 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 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'' section above and should assist sites in supporting their users and also service providers in having transparent access management policies. Much of the content of the XML Service Description Files should, in theory, be able to be generated 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.

Attribute Request Policy discovery

As the 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 Attribute Request Policy (and perhaps an indication of the authorisation policy) of services/resources.

Keep access control results hidden

There are scenarios where the access control results must be kept hidden. For example, I may wish Alice (as a society member) to be able to access my resource, but to exclude Bob. Further, I may not wish Bob to know that Alice can access the resource. This does not necessarily mean that the Attribute Request Policies need to be hidden: advertising that the SP needs "these attributes" to make a decision may be adequate. However, it should not be possible for Bob to capture Alice's access control result (or even the log of its result) or for him to test what that result would be. The site/server-based (usually XACML) policies should be kept private but this requirement may also impinge on the functionality within the Service Description File: it is often convenient to advertise the access levels within such a file, but this may not be possible in some situations where these would clearly betray such access decisions. Further, if Bob realises that the site is asking for 'SocietyMemberValue', then he may work out the authorisation policy from that. This is a potentially difficult area.

Silent failure due to authorisation refusal at closely-related resources

One problem that relates very closely to policy discovery is that of silent failure at the Policy Enforcement Points- or Policy Decision Points of resources that have common or shared access policies. 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 is usually highly desirable from a security point of view, as feedback would give an attacker greater knowledge of the access mechanisms. However, where there are closely related resources being protected by closely related policies, this can cause great headaches for both the end user and of the local support for those users.

• The 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.

In this example, the portal had to be intelligent enough to try each resource in turn before alerting a failure to the user. However, the resources could be subject to change. There could suddenly be a cluster of three resources and the access policy amended to cover all three, instead of two as before. If this were to happen, code would have to be changed at the portal again, as well as at the resources. This would seem to be unrealistic, but it is not a trivial problem to solve.

There is therefore the difficulty 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 and resource discovery may need to be a little more intelligent in such cases. One could recommend that the 'cluster' of resources have a single access management layer. This would be a little similar to the CAS and myVocs-GridShib integration models, as described above (and a model from which PERMIS would not be excluded, we should add). Effectively an access management layer would exist quite separately from the resources and the resources would trust assertions and/or decisions made by this access management layer. A relatively complex solution thus arises from this simple use-case. This is a good example of the potential complexity of supporting workable, yet apparently simple, access management requirements.

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 (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 distinguished names (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 GridShib project has pioneered the concept of the grid lookup of user attributes based in a Shibboleth attribute authority (AA), although the PERMIS software has effectively done this for some time, both within the IE and, more recently, the grid environments.

Many of the grid users of tomorrow are likely to access grid services through tightly-controlled portals, as the BRIDGES and 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 MAMS initiative and, in particular, the ShARPE and Autograph tools have shown that policies can be managed by institutions, communities and users (and, in theory, virtual organisations (VOs)). The ShARPE work has also shown how grid sites/resources could advertise their Attribute Request (and sometimes authorisation) Policies via the Service Description file. The VOMS, Community Authorization Service ( CAS) and 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. When comparing VOMS and CAS, a subtle - but very important - difference exists in that the CAS server is a central point where nearly all access control is maintained for the resources 'in the VO'. VOMS, in contrast, maintains the lists of users/members of the VO and can therefore allow a role-based access decision to take place at each resource. The GridShib project has begun to show how the VO can be managed as a Shibboleth Attribute Authority. The PERMIS toolkit is providing means by which to manage and edit these policies, both in the grid arena and the IE, and the work in the latter is complemented by the ShARPE attribute release policy editor.