How to handle multi-VO in IAM?

[federicaagostini]

IAM, by default, does not support multi-VO.

Anyway, some Community tried to set-up a custom way to handle multi-VO as workaround in IAM.
For instance, ESCAPE (that is a project which keeps together different experiments) bases the multi-VO with groups, more or less as follows:

• top level group (escape) to which every user belongs to. After registration in IAM, the user have to explicitly request to join the group and only IAM admins can approve it;
• child groups, one per experiment (e.g. escape/cms), which identifies a VO. The user asks to join the group specifying which is the purpose. A group manager, that is part of the experiment (and should know users) can approve -- also admins have this privilege.

The requirement of the top level group is just because ESCAPE uses VOMS proxies as credentials to access resources, together with JWT tokens and it is not necessary if a Community wants to rely on tokens only.

In a recent thread, a discussion about how to handle multi-VO in IAM started. The suggestion is to let the user choose at the registration phase the group he/she wants to join.

This thread is a follow up discussion that has already been raised by several people.

[marianne013]

Hi,
This is just to add that GridPP (UK) is looking at deploying a community IAM server, replacing the current set of three redundant GridPP voms servers, which serves approximately a dozen active VOs (plus another 30 legacy VOs), most of which are small and not able to run their own IAM server. Replacing 3 voms servers with 3*42 IAM servers does not look like a sensible way forward. (Neither does 3 *12, especially as we get new VOs on a regular basis.) Hence, we would like to deploy a multi-VO IAM server.

We are still in the exploration phase on our test IAM servers, so have not quite worked out which features (if any) we would need, but multi-VO is definitely our favoured (and possibly only) feasible approach.

Daniela

[federicaagostini]

Hi, about replicating VOMS, please consider the PR #729, which is a simulation of distributed VOMS servers.

About multi-VO in IAM, it is still an open issue that I don't think we are able to fix in the close future.