UVOS Overview

For a very high level description of UVOS software, its components and features see Home section. Here we present more details.

UVOS is a component that acts as an information point and organises entities within a hierarchical group structure. Top level groups of this structure are called virtual organisations. Each entity is assigned a list of group membership and a set of attributes. An attribute is composed of a name and a set of values, which can be empty. In addition, a single entity can possess multiple representations, for example in two different formats. These equivalent incarnations of the same entity are called identities, and are usually invisible for an outside user.

Example

What follows is a comprehensive example of the UVOS database. It serves as an illustration of various concepts which are presented in more detail later on. Please note that you can find the creation script for the following example in the system distribution, so you can easily play with it.

Groups hierarchy:

[UVOS root]
|-Math-VO
|       |-Staff
|       |   |-Admins
|       |   |      |-UNICORE example user(DN)
|       |   |      |-Eve(email)
|       |   |-Amy(email)
|       |   |-Ben(email)
|       |-Scientists
|       |   |-Ben(email)
|       |   |-Andrew(DN)
|       |   |-Chris(email)
|       |-UUDB
|           |-SiteA
|           |-SiteB 
|-QSAR-VO
        |-Ben2(DN)
        |-Tom(DN)
        |-UNICORE example user(X509Cert)

There are two top level groups defined, which are called VOs. The first one has complicated contents with subgroups. There are also users presented (in italics) with the type of identity in brackets. There are two equivalent identities (in another words: entities with different representations): UNICORE example user and Eve. UNIOCRE example user is the identity from example certificates of UNICORE 6.0 distribution - "sample admin".

Entities

Distinct members of the UVOS system are called entities. Every entity has unique label and typically one token which defines it. This token must be of one of the supported formats. Currently there is support for the following types:

  • X.509 certificate
  • DN - distinguished name
  • Email address

The token along with it's type is called identity. As it was stated entity typically possess one identity, but it can has more of them, even of the same type. To give an example: Entity with label "Jimmy Page" can have three identities attached: X.509 certificate issued by VeriSign, another X.509 certificate issued by ICM Warsaw University and an Email address jpage@example.com.

What is important to remember is the fact that all identities that compose a entity share the same characteristics (like attributes, groups membership, permissions). So in practice service works in terms of entities, and any of it's identities can be given as the representation.

Attributes

Attributes are composed of name and values list. Name are URNs, and values are arbitrary strings. The values list can be empty.

Administrator can assign attributes to entities. There are three methods to achieve it:

  • using global attributes: entity can have attribute assigned globally. Such attribute is valid always and in any context.
  • using group-assigned attributes: group can have attribute assigned, what effectively means that all members of this group automatically holds this attribute too (no matter if they were added later or prior creation of group-assigned attribute). However this attribute is valid only in this group scope.
  • using group-scoped entity attributes: those are assigned to the entity (just as global) but have additional group restriction, and are valid only in this group scope.

Two latter methods introduce group-scoped validity of attributes. This requires further explanation. From the technical point of view requester can ask for the entity's attribute in some group. Such query will return all entity's global attributes and all group-scoped attributes valid in this group. E. g. consider example situation shown above. The user Eve can have attribute "administrator" in the scope of the VO Math-VO (remember that VO is just a normal group) but no such attribute in the VO QSAR-VO, where she is a regular user.

There is also another distinction of attributes, important only when querying for them:

  • effective attributes are those that VO service consumer (e.g. Policy Decision Point) is interested in. SAML queries always return effective attributes. Effective attributes are composed of all attributes which are hold for the entity or the entity in the group scope (including inherited, etc.),
  • exact attributes are the same as effective in case of global and group-assigned attributes. The difference is in case of group-scoped entity attributes: exactly assigned attributes to the ID1 in the group G, are those exactly assigned for ID1 in the group G scope, and do not include e.g. attributes which are global or assigned in any of G subgroups (which are effective attributes). Exact attributes are useful in VO managing, and SHOULD NOT be used for authorization purposes.

Note: it is possible to set group-scoped entity attribute even when the identity isn't a member of the group. However this attribute will not be visible as an effective attribute, only as exact.