Last updated: 
2 weeks 4 days ago
Group Manager
At the request of the Research Councils UK e-Infrastructure group, Janet established a working group from 2013-2016 to support those providing and using e-infrastructure services in achieving an approach that both protects services from threats and is usable by practitioners. More detail about the group can be found in the Terms of Reference The Working Group published the following papers: E-infrastructures: Access and Security (summary paper) (Jan 16) Federated Authentication for e-Infrastructures (Sep 14) Technical Security for e-Infrastructures (Nov 14) Authorisation/Group Management for e-Infrastructures (May 15) Policies for e-Infrastructures (Jan 16) Accounting and e-Infrastructures (Nov 16) Information about the Working Group's activities, as well as discussion documents, links and recommendations is linked under the following categories. Unless marked otherwise, all items are works-in-progress and we very much welcome your comments and contributions. Meetings   Presentations Case Studies Discussions Technologies References     Andrew Cormack (WG Chair)

Group administrators:

E-Infrastructure supporting Virtual Organisations

20 March 2014 at 10:03pm

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.

Comments

Stephen

I'm wondering whether project/group/VO management might be something we want to focus on at a future WG meeting? At the moment I'm not clear what the requirement for "portable" groups is, for example:

  • how far do groups need/want to be delegated from the service providers?
  • what policies does group management need to play a part in?
  • do groups need to be portable across both certificate-based and SAML-based services?
  • do groups need to include both certificate-based and SAML-based users?
  • are there standards/protocols that could help?
  • if not, then at how many stages, and in which directions, do we need to bridge?

I doubt we'll be able to build an all-encompassing group-management service, but if we can get our heads around questions like that then maybe we can at least identify sets of requirements that would be useful for such services to aim for?

I thought the focus on security at the last meeting worked well. If we want to do the same sort of thing for groups then I'd investigate whether we could get a couple of knowledgeable speakers (either from inside or outside the group) to help us along?

And here are links to some varied examples of group management software:

I don't think I've come across anything that bridges the SAML and certificate worlds, though, either in the sense of allowing a group to be built from users with both types of credential or in the sense of allowing the same group to be portable between a certificate-based service and a SAML one. How complex a solution we need is something for discussion, I think.