# IAM technical issues to be resolved before moving away from VOMS Admin * there is also additional [codi document](https://codimd.web.cern.ch/AaR3HBIRS0KofM4J_-FWUQ) with few different issues / feature requests * list of priority issues for [VOMS-Admin EOL tasks](https://docs.google.com/document/d/1bpIyOBYRvbiVyc21PqHJNijs9Y-SBiT1KyfgBcw8iqY/) ([github VOMS-Admin EOL tasks](https://github.com/orgs/indigo-iam/projects/8/views/1)) * few additional ideas from "[VO management with ATLAS IAM](https://indico.cern.ch/event/1417057/)" [discussion](https://indico.cern.ch/event/1417057/?note=280430#2-discussion) * ~~issues identified during [VO Admin Training](https://indico.cern.ch/event/1105143/)~~ * ~~expired AUP doesn't prevent user to use refresh token [issue#447](https://github.com/indigo-iam/iam/issues/447) and new voms certificate [issue#446](https://github.com/indigo-iam/iam/issues/446) - planned for 1.8.1 release~~ * ~~we need AUP synchronization in vomsimporter script before fixes for these issues gets deployed~~ * ~~unable to create/modify/remove user account "labels" using Web interface~~ * ~~during registration process user account `cern_person_id` label is automatically assigned to the account when IAM addministrator approves this account~~ * ~~it seems that label modifications were necessary only for fixing incorrectly synchronized ATLAS service accounts~~ * ~~manualy create service accounts~~ * ~~all account can be linked to CERN SSO including service accounts~~ * ~~this is so rare operation that it can be done even manually directly with REST~~ * ~~missing proxycert API documentation ([doc issue#49](https://github.com/indigo-iam/iam-website/issues/49))~~ * ~~official documentation still points to 1.7.2 release -> now it points to 1.8.0 release (Roberta)~~ * ~~customizable login page at least with a link to the details about VO documentation~~ * ~~already [available](https://github.com/indigo-iam/iam/blob/v1.7.2/iam-login-service/src/main/resources/application.yml#L115-L117) but still [not documented in 1.8.0](https://indigo-iam.github.io/v/v1.8.0/docs/reference/configuration/)~~ * why CERN IAM doesn't automatically create all ATLAS accounts in IAM according HR database with default list of groups (e.g. `/atlas`) while it already use CERN HR API to suspend accounts? * ALICE prefers current workflow where VO-Admin manually approve each new user, because there are more steps that needs to be done to fully enroll new user for all grid activities * ATLAS - VO-Admins would prefer automatic IAM account creation but it is not clear how to get AUP signature * user must sign AUP before new account can be used for grid activities * user must register certificate subject to be able to get X.509 VOMS proxy * => could IAM ask users without AUP and/or X.509 proxy on first login? * actually could IAM ask to re-sign AUP not only for missing but also expired AUP signature * CMS doesn't use IAM web interface for account management * accounts in CMS IAM are fully synchronized with their own primary CMS member database * their VO admins don't use CMS IAM web interace and we can't expect any feedback from CMS when it comes to the missing features in VO management using IAM web interface * user can choose IAM username (CERN username is default suggestion) during registration * do we really want to give user such freedom or should we just copy CERN username? * Some users have multiple CERN accounts/user names. Perhaps they can be given the option to choose between existing account names, instead of freeform text entry? * This may be slightly complicated, because user details comes from CERN SSO token and alternative account username would require at least LDAP query. * Unfortunately attempt to SSO with secondary account fails with error message: "External authentication error: Validation error - Claim 'cern_personal_id' not found" [issue#524](https://github.com/indigo-iam/iam/issues/524) * user can choose IAM email (CERN primary mail is default suggestion) during registration * changed address just leads to red but empty error box -> It doesn't seem so (Roberta) * do we really want to give user freedom to choose different email address not registered as primary at CERN? * [pre-GDB October 2022 IAM Workshop](https://indico.cern.ch/event/1185598/) - it is better not to allow user to modify email, because the one that comes from CERN SSO token is validated (it is more trustworthy) * ~~registration confirmation email contain incorrectly formatted sentense -> solved in 1.8.0 (Roberta)~~ * ~~*You can set your local $organisationName password by following this link:*~~ * ~~is it possible to customize email templates~~ * ~~we normally don't use IAM passwords - can we drop such useless / misleading text from info email~~ * ~~email notification are not sent to the IAM administrators~~ * ~~probably just configuration issue with production IAM instancess~~ * ~~is email gateway configured for ATLAS instance?~~ * ~~25 July I received email with new account request => fixed~~ * ~~sender email is not working address atlas-auth@atlas-auth.web.cern.ch~~ * ~~some email servers may consider unreachable FROM addresses less trustworthy~~ * ~~CERN IAM OPS team should configure sender address from `@cern.ch`~~ * ~~user group request is sent to both - IAM Group Managers and IAM administrators -> [issue#521](https://github.com/indigo-iam/iam/issues/521)~~ * ~~should IAM administrators get all these emails?~~ * ~~[pre-GDB October 2022 IAM Workshop](https://indico.cern.ch/event/1185598/)~~ * ~~only Group-Managers should receive these emails~~ * ~~IAM admins should still see pending requests in the web interface~~ * missing [VOMS-Admin notifications](https://github.com/italiangrid/voms-admin-server/tree/master/voms-admin-server/src/main/resources/templates) / limited list of [IAM mail templates](https://github.com/indigo-iam/iam/tree/master/iam-login-service/src/main/resources/email-templates) ([issue#732](https://github.com/indigo-iam/iam/issues/732)) * account suspension / account restoration? * AUP reminder? * AUP expiration? * configurable template with `IAM_CUSTOM_TEMPLATE_LOCATION`? * ~~configure cleanup of suspended accounts~~ * ~~default account cleanup is 30days after suspension, we asked for [13 months](https://codimd.web.cern.ch/muIh9zERRbSoIKK-Z4Qwjw?both#IAM-sycnhronization-with-CERN-HR)~~ * ~~we can always re-create account in future (once user revive its ATLAS membership), but~~ * ~~it'll be necessary to add user again in all groups~~ * ~~all token clients registered by user needs to be re-registered~~ * ~~this can initially be very confusing and it'll definitele lead to a lot of support questions~~ * ~~suspension status synchronization with HR database - activate accounts / remove cleanup date [issue#530](https://github.com/indigo-iam/iam/issues/530)~~ * ~~IAM automatically [set endDate for suspended accounts](https://github.com/indigo-iam/iam/blob/5bf97fab616c1347ccff03e93204000b9b71cc21/iam-login-service/src/main/java/it/infn/mw/iam/core/lifecycle/cern/CernHrLifecycleHandler.java#L176)(?)~~ * ~~account with set endData are automatically [cleaned](https://github.com/indigo-iam/iam/blob/5bf97fab616c1347ccff03e93204000b9b71cc21/iam-login-service/src/main/java/it/infn/mw/iam/core/lifecycle/ExpiredAccountsHandler.java#L127) after [30 days](https://github.com/indigo-iam/iam/blob/5bf97fab616c1347ccff03e93204000b9b71cc21/iam-login-service/src/main/java/it/infn/mw/iam/config/lifecycle/LifecycleProperties.java#L57)~~ * disabling suspension of service accounts - documentation for account labels and their meaning [issue#57](https://github.com/indigo-iam/iam-website/issues/57) -> [PR#108](https://github.com/indigo-iam/iam-website/pull/108) * ~~do we want association of service accounts with CERN HR personal ID?~~ * ~~[pre-GDB October 2022 IAM Workshop](https://indico.cern.ch/event/1185598/) - no, accounts are linked with SSO to the CERN account and we don't need service account suspension linked to CERN HR DB~~ * ~~IAM Administrators -> their tokens give privileges regardless of scopes (e.g. scim:write)~~ * ~~we can have separate second accounts for VO-Admins (possible to use username & password with `?sll=y` URL suffix, secondary CERN SSO account or second certificate with different subject)~~ * ~~[pre-GDB October 2022 IAM Workshop](https://indico.cern.ch/event/1185598/) - it is better to separate user and admin accounts => VO-Admins will need second IAM account with admin privileges linked to secondary CERN account~~ * issue for CERN IAM team - secondary CERN account doesn't currently work with ATLAS IAM * ~~still default behavior for IAM admins is dangerous [issue#543](https://github.com/indigo-iam/iam/issues/543)~~ * ~~it would be also difficult to manager secondary acccounts for each Group-Manager (100+ ATLAS IAM accounts)~~ * ~~Audit of changes (who / when / what)~~ * ~~CERN is using their standard logging infrastructure with Elasticsearch~~ * ~~We [discussed](https://indico.cern.ch/event/1185598/) it would be useful to try to trace what's logged for refresh token request~~ * GGUS & EGI Operation Portal - followed by WLCG * missing VO statistical endpoint for EGI (collect number of VO users) [issue#516](https://github.com/indigo-iam/iam/issues/516) * used probably by [VO Id Card](https://operations-portal.egi.eu/vo/view/voname/atlas) * ~~no VO group/role synchronization with EGI GGUS~~ * ~~this was done using legacy VOMS API which is no longer available in IAM~~ * ~~no progress in WLCG <-> EGI communication how to replace this functionality~~ * ~~currently it is expected that we'll have to ask GGUS to add user ALARM role~~ * ~~it is not clear if GGUS needs to know normal user relation with VO (list of user certificates from given VO)~~ * [GGUS will be retired](https://indico.cern.ch/event/1369601/contributions/5917197/attachments/2856680/4996639/WLCG_Helpdesk_WLCG_Workshop_15.05.24-1.pdf) at the end of 2024 * login with EGI Check-In, but CERN doesn't sent useful [attributes](https://oidc-attr-viewer.cern.ch/) * actually each VO is supposed to nominate several privileged members for mini-admin role in GGUS * ~~WLCG IAM 1.8~~ * ~~unable to assign group manager with web interface (only via API)~~ * ~~(Enrico) You could add group managers from "Managers" tab of group page. You can access a group page from Groups section, by clicking on group name.~~ * ~~Normal users can't see account configuration for other user~~ * ~~ATLAS ADC needs access to these details (e.g. groups) to understand user issues~~ * ~~only IAM administrator (ROLE_ADMIN) can see these details, but this is too powerful role~~ * ~~we would need something like IAM ROLE_READ(?) that can be used for our distributed computing experts~~ * ~~[issue#543](https://github.com/indigo-iam/iam/issues/543) implementation brings `iam:admin.read`, but this applies only on IAM API and not web interface~~ * ~~discussed in [IAM Hackathon](https://indico.cern.ch/event/1236132/) and making [IAM more open not preferred](https://docs.google.com/document/d/1NrOzsJaRddupSqEOsAyovFXy9H_8Q4ZsJZLNibzhluc/edit)~~ * ~~after 1.7.2 -> 1.8.0 upgrade cached data in browser must be manually cleared~~ * ~~I was not able to see new "Clients" item in the IAM dashboard menu~~ # Open questions from (not only) VO administrator * Can we set "infinite" (e.g. 2100-01-01) AUP expiration time for service accounts? * is this allowed by a (CERN/WLCG/IGTF?) policy that forces our users to sign AUP every year? * ~~MFA for VO administrators for the Web interface~~ * ~~threat them as normal users when they login without MFA~~ * ~~actually CERN is moving to MFA for everybody...~~ * Read privileges for ADC (DAST) experts in IAM web interface [iam#794](https://github.com/indigo-iam/iam/issues/794) * experts need access to user account details to be able to debug issues * Group managers currently doesn't have privileges to update group managers * same behavior as in legacy VOMS * actually with legacy VOMS group managers were able to add group managers, but removing them could be done only by VO Admins * for ATLAS with many groups it would make sense to delegate also management of group managers to the (sub?)group managers # VOMS Admin -> IAM synchronization issues * ~~`userName` & `displayName` synchronization~~ * ~~currently `user.ABCD` format where `ABCD` is VOMS user ID~~ * ~~there are users with different CERN username for primary account vs. nickname~~ * ~~fixed for ATLAS by using CLI parameter `--username-attr=nickname` and `--link-cern-sso`~~ * group synchronization (removing groups, not just adding) * implemented but with issues for accounts without parent group (e.g. [ATLAS voms 4924](https://voms24.cern.ch:8443/voms/atlas/user/load.action?userId=4924)) * IAM by design can't use subgroups that doesn't have parent group * group manager synchonization (e.g. ATLAS has ~ 250 groups, ~ 2000 group managers) * well, it's a mess in ATLAS VOMS and we have to cleanup at least top level groups and their managers * ~~`Group-Manager` role from VOMS should not be synchronized(?)~~ * ~~use `Group-Manager` role just to add IAM Group Manager~~ * ~~remove `Group-Manager` optional group once we move away from VOMS Admin~~ * ~~code exists, no pull request yet...~~ * ~~`syncmanagers.py` script for full group manager synchronization (add&remove)~~~ * ~~doesn't work with current ATLAS IAM 1.7.x~~ * ~~found issue with IAM API [RQF1950850](https://cern.service-now.com/nav_to.do?uri=u_request_fulfillment.do?sysparm_query=number=RQF1950850) and waiting for 1.8.x deployment~~ * ~~mutiple certificates with same subject but diffrent issuers~~ * ~~only one certificate synchronized [issue#8](https://github.com/indigo-iam/voms-importer/issues/8)~~ * ~~OK for our case, because all certificates with duplicate subject are anyway expired~~ * ~~actually still we face problems while CA transition from old issuer to the new one~~ * ~~`CN=TERENA eScience Personal CA 3,O=TERENA,L=Amsterdam,ST=Noord-Holland,C=NL` -> `CN=GEANT eScience Personal CA 4,O=GEANT Vereniging,C=NL`~~ * ~~is could be fixed on VOMS side by removing old / unused certificates (tricky to manage)~~ * ~~fixed in 1.8.3 with by implementing [issue#454](https://github.com/indigo-iam/iam/issues/454)~~ * removing certificates that are no longer in the source VOMS data [issue#15](https://github.com/indigo-iam/voms-importer/issues/15) * cleanup of linked certificates [voms-importer#15](https://github.com/indigo-iam/voms-importer/issues/15) * rely on one time cleanup before legacy VOMS are switched off in summer 2024(?) * we should also cleanup **all** certificates with issuers that no longer exists in IGTF * `CN=CERN Trusted Certification Authority,DC=cern,DC=ch` * `CN=CERN Root Certification Authority 2,O=CERN,C=ch * `CN=DigiCert Grid CA-1,O=DigiCert Grid,DC=DigiCert-Grid,DC=com` (still valid???) * `CN=GRID2-FR,O=CNRS,C=FR` * `CN=INFN CA,O=INFN,C=IT`, `CN=INFN Certification Authority,O=INFN,C=IT` * `CN=CA,OU=Authority,O=eScienceCA,C=UK`, `CN=UK e-Science CA,OU=Authority,O=eScienceCA,C=UK` * `CN=CESNET CA,DC=cesnet-ca,DC=cz`, `CN=CESNET CA 3,O=CESNET CA,DC=cesnet-ca,DC=cz` * ~~issues with comma in the certificate subject [GGUS:156765](https://ggus.eu/index.php?mode=ticket_info&ticket_id=156765)~~ * ~~did we test that certificates with comma really works with `voms-proxy-init`? yes, see the comments in the related GGUS issue~~ * ~~list of certificates with unusual characters in subject or unusual structure~~ * ~~`CN=Errenst\, Martin errenst@uni-wuppertal.de,O=Bergische Universitaet Wuppertal,C=DE,DC=tcs,DC=terena,DC=org`~~ * ~~`CN=Harenberg\, Torsten harenber@uni-wuppertal.de,O=Bergische Universitaet Wuppertal,C=DE,DC=tcs,DC=terena,DC=org`~~ * ~~`CN=Fabrizio Parodi fabrizio.parodi@infn.it,O=Istituto Nazionale di Fisica Nucleare,C=IT,L=Frascati,street=Viale Enrico Fermi 54`~~ * ~~`CN=Sandhoff\, Marisa sandhoff@uni-wuppertal.de,O=Bergische Universitaet Wuppertal,C=DE,DC=tcs,DC=terena,DC=org`~~ * ~~`CN=uclhc-fe-1.t2.ucsd.edu,O=University of California\, San Diego,L=La Jolla,ST=California,C=US,DC=incommon,DC=org`~~ * ~~`CN=uclhc-fe-1.t2.ucsd.edu,OU=UCSD,O=University of California\, San Diego,L=La Jolla,ST=California,C=US,DC=incommon,DC=org`~~ * ~~`CN=uclhc-fe-1.t2.ucsd.edu,O=University of California\, San Diego,ST=California,C=US,DC=incommon,DC=org`~~ * `~~CN=Walkowiak\, Wolfgang\, Dr. gg381@uni-siegen.de,O=Universitaet Siegen,C=DE,DC=tcs,DC=terena,DC=org`~~ * ~~`CN=Tom Kresse,gn=Tom,sn=Kresse,OU=Technische Universitaet Dresden,O=GridGermany,C=DE`~~ * ~~cleanup these certificates(?)~~ * ~~we'll need AUP time synchronization as mentioned above ([#17](https://github.com/indigo-iam/voms-importer/issues/17) solved)~~