E-Infrastructure supporting Virtual Organisations

Some thoughts on the e-Infrastructure requirements for supporting Virtual
Organisations.

 A Virtual Organisation (VO) is one that intersects with multiple real
organisation.  It is comprised of users from multiple home
institutions. Many of which may be entirely unaware of the existence
of the VO at all.  This means that the Virtual Organisation needs to
be self-organising and must be provided with the tools to manage its
own membership.

There are many examples of services that support communities that fit
this description, for example JISC-mail mailing lists and the Janet
communities website. In these examples the services all manage their
groups locally. This approach will be acceptable in many cases.
However where a VO consumes services from many different Service
Providers (SP) it might be desirable to have a single interface for
controlling and monitoring the activies of the VO. This is especially
true where there are many services of a similar nature, for example HPC or
data services, or where the VO is very large.

If there is an enabling contract/agreement between the VO and the
Service Provider (ie the VO is purchasing resources) then the VO needs
to provide the SP with Authorization rules defining who its members are and the access its
members are allowed to the service. In turn the SP may need to provide
accounting information to the VO about the use of the service.

The VO has to establish an identity for each of its members and could
in principle act as an Identity Provider (IdP). This will not always be
desirable but may be appropriate in some cases. The main problems with
this approach are that:

• The user may be a member of several VOs, forcing them to maintain multiple identities. The VOs themselves may rely on an external Authentication mechanism which could be the same for each VO but the user-name the user presents to the service would have to reflect a  single VO. If the user then wishes to access a resource on the same  service via a different VO they would have to re-authenticate.
• The SP might require a high level of assurance of a users identity (e.g for security reasons) than is required/implemented by the VO.
• All Authentication requests pass through the VO. This may provide a greater degree of information about a users usage of the service  than is required by the agreement between the VO and the SP.

The more general solution is to allow the separation of Authentication
and Authorization into separate services. Users Authenticate via
standard Identity Providers (IdP). For example one provided by their home
institution. Some authorization attributes provided by this IdP might
be relevant to Authorization but Information is also needed from the
VO, for example by a SAML attribute server maintained by the VO.

The IdP might be using different user identifiers for different service
providers. The VO may also choose to do the same for the identities it
uses for Authorization/Accounting purposes. In this case some kind of
identity linking step is required for the SP to associate the identity
provided by the IdP with that provided by the VO. Though this extra
step is cumbersome it has the additional advantage that there is no
requirement for the VO and the SP to be using a common IdP or even a
common Authentication mechanism.

If a common IdP (which provides the same global identity to all users) is available
then the linking step can be omitted. This is the approach taken by the ESG who use OpenID
together with SAML based VO attribute server.

One currently active implementation of the VO concept is the VOMS
system. This implements virtual organisations in terms of a
proxy-certificate security framework. Prior to performing any
operation the user contacts the VOMS server to create a VOMS proxy
certificate. The VOMS server verifies the users membership of the VO
and encodes the VO specific attributes into a proxy certificate which
is returned to the user. The user can control which attributes are
asserted when creating a proxy so it able to create a proxy with
limited permissions if so desired. The strength of this approach is
that it creates a delegated credential that can be used at a later
date as part of a complicated work-flow. On the other hand it it is
less useful for dynamic information because the attribute data is
frozen at the point the proxy is created. It is also not possible for
a service provider to build static service configuration files by querying
the VO for the attributes of all known users as this information is only available as part of an
authenticated service request. Therefore there are probably valid use
cases for both a VOMS and a SAML-like approach to VO attributes. It
would therefore be desirable to be able to configure a VOMS server
based on a SAML one.

Some VOs might want to build their own VO infrastructure so the
Authorization service protocols should be well defined allowing
multiple implementations. However a default VO management service would
also be desirable for general use.