VO (Virtual Organisation) is a quite broad concept. Here (as for now) we use it in a quite simple way, but still offering great benefits for grid administrators.
VO server software is used to store identities of grid entities along with their attributes. Entities are managed with the usage of groups to help administration. Those attributes can be used e.g. for authorization purposes. This document describes how to take advantage of this approach in any XFire based service along with some additional features as how to use a VO service to obtain XUUDB-like data (e.g. UNICORE Xlogin).
There are two basic modes of operation supported by this subsystem:
It is possible to use both modes simultaneously. This package contains also code for supporting PUSH mode on client side: there is possibility to easily configure assertions that should go with the request.
A typical usage of this module is to make service authorization process more flexible. E.g. Unicore/X XACML policy can require certain attributes in order to grant an access to a resource (e.g. to TSS resource which allows for submitting jobs). Those attributes can be retrieved from a VO service (in any mode).
In a classic situation XUUDB service can be seen as a very trivial VO service. It is limited to carry only one attribute 'role' and additional Xlogin information for any user. The Xlogin is used to map a user's certificate to a local account name. Therefore XUUDB stores Xlogin information and role with an associated VSite identifier (so every VSite can have different mappings).
This module can be configured to use attributes retrieved from a VO service to simulate XUUDB features: selected attribute can be mapped to XUUDB 'role' and another selected attribute can be used as a Xlogin. What is special about VO services are the groups (often hierarchical) to which entities belong. This subsystem takes advantage of this feature to establish where are defined XUUDB-like mappings for the local system. It is also possible to use the fact that a user is (or isn't) a member of a VO or its group as an authorization constraint.
If you want to use UVOS instead of classic XUUDB you can simply store mappings of certificates to accounts in a special attribute. Also UNICORE roles can be handled this way. XUUDB can be then even not installed.
There are three issues with the above approach. The rest of this section explains how to easily solve them.
First of all it must be defined how to recognize account mappings for the VSite, as UVOS service can be used (and usually is) by many VSites concurrently. The solution is that a special group is created for each VSite (e.g /VO1/UUDB/SiteA) and only attributes which are assigned in this group scope are used by the VSite. Of course VSite configuration contains a parameter which specifies the group.
The next issue is how to handle situation when there are multiple Xlogins/roles available for the user, and how to mark the default one? To overcome this for both role and Xlogin there are two attributes used. Base one can possess many values (e.g. in case of Xlogins every value is different Xlogin) while the additional holds the single default value. When there is no need for multiple values then the base attribute can be used alone. When default attribute is defined then its value overrides the value of base one. This is useful in PULL mode. In PUSH mode user has freedom of choice. E.g. she can ignore default one, select anyone of base values and present only that one to the service.
The last issue is the choice of names for the attributes. You can use any you wish, however there are predefined values, used in examples and as default configuration values. The default ones are presented below in the table with configuration options.
Currently there are several implementations of services that can be used as server side. This module was tested and works well with UVOS system which was created in the Chemomentum project. There are other possibilities and you can try to use any SAML (2.0) Attribute service. We are interested in all success/failure stories!