1-to-1 mapping between DIRAC group and IdP group

[fstagni]

Discussed during BiLD meeting of March 3rd 2022, and before in BiLD meeting of 11/11/21 (see also slides from 12) we agreed on moving to a configuration in which there is exactly a 1-to-1 relation between DIRAC group and IdP group/role/scope.

This change will make it such that, by construction, the WebPortal behaves like the CLI currently works. We should then remove the possibility to change easily the DIRAC group from the WebApp drop-down menu, basically expecting a logout-login as a base mechanism for changing the group/scope.

[chrisburr]

Ideally we should make this work in such a way that people can have multiple windows with different groups open at the same time. We'll have to dig into the current implementation to figure out which mechanisms can be used for this.

[chaen]

Although I did not follow all the discussions on that topic, I want to mention something to keep in mind

DFC

We will for sure need to change the DFC security policy. At the moment, we can register files using Vladimir:lhcb_mc credentials, and move them using Federico:lhcb_data because these two groups share the same VOMS role. We have to be careful not to break that functionality.

Storages

Permissions on storages are managed by VOMs Roles, so same things applied

---

Storage authorization will likely be done based on scopes (https://github.com/WLCG-AuthZ-WG/common-jwt-profile/blob/master/profile.md#capability-based-authorization-scope)

And since the LFN is part of the PFN, we can imagine using the same scopes for the DFC and the storage.

It is just that the definition in IAM of the groups and scopes (https://indigo-iam.github.io/v/v1.7.2/docs/reference/api/scope-policy-api/) would have to be pivoted with respect to what we are used to in the CS

Now in the registry

GroupA
{
  Properties = PropX, PropY
}
GroupB
{
  Properties = PropY,PropZ
}

Later in IAM

PropX
{
  Group = GroupA
}
PropY
{
  Group = GroupA,GroupB
}
PropZ
{
  Group = GroupB
}

[iueda]

Just jumping in... as suggested in the DUW session.

https://indico.cern.ch/event/1107386/contributions/4827828/ reads DIRAC groups == IdP scopes, rather than IdP groups as the subject suggests

With IAM, what is currently suggested/implemented is VOMS roles == IAM optional groups

Then, this

Storage authorization will likely be done based on scopes (https://github.com/WLCG-AuthZ-WG/common-jwt-profile/blob/master/profile.md#capability-based-authorization-scope)

suggests VOMS roles == IAM scopes

The above three do not seem consistent... I should read the above-mentioned documents...