Open fstagni opened 2 years ago
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.
Although I did not follow all the discussions on that topic, I want to mention something to keep in mind
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.
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
}
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...
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.