indigo-iam / iam

INDIGO Identity and Access Management Service

Home Page:https://indigo-iam.github.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

institute not displayed to VO Admin role

deesto opened this issue · comments

I see in the code an institute var returned here, which I assume says what it means, but as a VO admin (ATLAS), I do not see this value displayed in user records, even for my own membership. Is there a reason this field is not shown to VO admins (or possibly more or all roles), or has it been hidden intentionally? I think admins may need to see this value when troubleshooting certain membership issues -- it is certainly a common factor in current VOMS issues.

Institute is not used internally by IAM and referenced class seems to be used only to process data that comes from CERN HR database. Only given name, family name and email is synchronized from CERN HR DB

public void synchronizeInfo(RegistrationRequestDto request, String personId) {
VOPersonDTO voPersonDTO = hrDbApi.getHrDbPersonRecord(personId);
request.setGivenname(voPersonDTO.getFirstName());
request.setFamilyname(voPersonDTO.getName());
request.setEmail(voPersonDTO.getEmail());
}

Unless we have some use-case for institute within IAM than in my opinion it would be better not to add more details. Actually these information could be exposed in the ID-token, but I'm not aware of any place / application where we could benefit from exposed institution (as far as I know our applications doesn't rely on institution stored in legacy VOMS; only VOMS Admin have access to these details and our applications doesn't have these privileges).

If you can guarantee the above validation calls are the only place where IAM gets user info, and institute is never among the data pulled, then fine, but institute mismatches have certainly been an issue many times in VOMS alone, as well as in synced data between VOMS and IAM. I don't see the benefit of hiding it if it's available.

As we continue to work with IAM and handle user requests, collecting and exposing the institution in an IAM record makes even more sense, especially when group requests are made for cloud orgs, e.g., verifying that a user is associated with a US institution aids the approval of their request for the atlas/usatlas IAM group.