UVOS and VOMS comparison

In EMI UVOS is planned to be maintained only until VOMS is able to take over. To achieve this we need to solve two issues:

• ensure protocol compatibility,
• ensure that at least major features of UVOS (used by UVOS users) have counterparts in VOMS.

The point one is tracked by SAML working group, implementation of EMI SAML profile should solve it. This page tracks the 2nd point.

In the whole text internal UVOS and VOMS concepts are used, for instance 'group' is understood as an entity used to organize users, not as an attribute (as it is exposed by SAML interface).

By "VOMS" we mean either VOMS-Admin instance (one web-application installed in a container) or a generic VOMS feature which is related to underlying database contents. This should be clear from the context.

General conceptual differences

In VOMS the role is a special concept (e.g. one can assign (generic) attributes to role owners). In UVOS all attributes are "equal".

In VOMS one VO is served per VOMS instance, and each user registered in VOMS is automatically a member of this VO. In UVOS VO==top-level group, one server can serve multiple VOs, users can be registered in database without assignment to any of the VOs.

The VOMS-Admin is managed by a WWW application. UVOS doesn't offer such (except for users registration and web authentication) but provides a sophisticated standalone GUI manager (RCP - eclipse based).

UVOS and VOMS internal authorization is solved in a different way but at first it seems that possibilities offered by both solutions are similar.

Functional differences

The following list enumerates features which are present in UVOS but are not present in VOMS.

1. Notifications: UVOS administrator may configure UVOS to send (currently email) notifications when any of the management operation take place. This is useful when multiple admins maintain the DB. In VOMS notifications can be sent only on certain operations. If notification subsystem is activated then all administrators that have permission to perform an operation get message if it was performed. List of VOMS operations generating notifications: user suspension, VO applications, group applications and role requests.
2. UVOS supports email-type identity (note that this is not an attribute) along with password used for authentication and certificate-type identity, while VOMs only supports DN identity type (also supported by UVOS).
3. UVOS supports SAML Web-based authentication. This allows web portal to be very easily integrated with authentication based on UVOS. If user has email identity in UVOS this allows for logging with user & password.
4. UVOS registration forms are quite different to what VOMS offers. Integration of VOMRS features into VOMS should provide a similar set of features in VOMS-Admin. What still will be different is: no possibility to register CSR, bit different user-experience as each user which is registering must have a certificate loaded into web browser. It won't be possible to apply for generic attributes (only for role and group).
5. UVOS provides a feature to populate user attributes from DN of a new member.
6. UVOS supports 3rd party SAML queries (under work in VOMS Admin)
7. Attribute scopes: in UVOS all attributes can be group-scoped. In VOMS only the role.
8. Attributes inheritance: in UVOS attributes assigned in subgroup are also visible in the parent group (e.g. role=admin in assigned in /users/staff is also valid in /users). In general UVOS is designed to be able to control inheritance (up or down) but only the up direction is stable. This implies significant differences in groups organization between VOMS and UVOS.
9. In VOMS generic attributes have a single value. UVOS allows for list of values for any attribute.
10. In VOMS role can not be assigned globally.
11. UVOS can be deployed with embedded (no-config) database and with PostgeSQL and MySQL databases. Support for the two first is missing in VOMS.
12. UVOS records all DB management events, therefore admin can check what happened. E.g. what identity removal actions were done since a given date.
13. UVOS provides possibility to go back in time and browse (of course in read only mode) a snapshot of the database at a given point in the past.
14. UVOS supports filtering of attributes served by SAML interface.
15. Management UI differences are quite big due to different technology (UVOS - RCP standalone application, VOMS - WWW interface) and many differences in both solution concepts. Some of the differences in cases where features are similar:
    1. VOMS shows up to 10 identities on one page.
    2. There is no possibility to change sorting.
    3. There is no possibility to check what are a given principal's permissions in a given group.
    4. Non-english characters are messed (e.g. in user's address).
    5. There is no tree view of groups (only one group contents can be displayed at once).
    6. It is not possible to check effective generic attributes of a user (i.e. including those implicated by roles and group membership).
    7. All user related operations must be made from user page, what might be sometimes inconvenient (e.g. Attributes view, user x owning attribute y found, to delete it admin has to change view, find user X again, enter its view and only then attribute can be deleted).

Note that making an inverted list doesn't make much sense (unless EMI changes the task to be opposite ;-). So the below enumeration is a quick draft only:

1. UVOS doesn't support AUP management (except of showing a VO agreement doc upon users registration).
2. UVOS doesn't issue ACs.
3. It is not possible to assign a specified attribute to all owners of other attribute. VOMS supports this solely for the Role attribute.
4. UVOS doesn't offer a membership expiration feature.

-- KrzysztofBenedyczak - 05-May-2011