EGI Robot user accounting teleconference
15/April/2014
Chair: Diego Scardaci (EGI.eu)

Participants:
Giuseppe La Rocca (INFN)
Ivan Diaz Alvarez (EGI Accounting portal)
John Gordon (EGI Accounting system)
Stuart Pullinger (EGI Accounting system)
Luis Font (AMC, in charge of system administration / development)
Marco Verlato (WeNMR)
Sorina Pop (developed some of the extensions in the Virtual Imaging Platform)
Zoltan Farkas (MTA SZTAKI, SCI-BUS)
Gergely Sipos (EGI.eu)
Nuno Ferreira (EGI.eu)

Diego Scardaci (see slides):
- introduced the problem we are trying to solve: Gathering basic user information about the users of robot certificates that are plugged into science gateways and into other types of high level environments
- presented EGI.eu's proposal for a solution, which is based on enriching the DNs of robot proxies with basic user data, and changing the EGI Accounting system (primarily the Portal) to be able to understand personalised robot proxy DNs
- informed the audience about the open questions that we are trying to answer today

Giuseppe La Rocca (see slides):
- introduced the eToken service that is developed and operated by INFN Catania, and is used by several science gateways to generate personalised proxies for the users
- tests are still ongoing with respect to integration with the EGI accounting system and portal

John Gordon, Stuart Pullinger:
- there seems to be no major impact on the accounting system by the proposed EGI solution
- we still need to test the INFN system with the various middleware setups that EGI has (ARC, Unicore, gLite, Globus, ...) to see that the extended DN does not cause any problem (for the APEL client we need the blah log to create an accounting record. Other systems use their own methods to create the record)
- the limit for DN length seems to be 255 character in the Accounting database, but this also needs to be tested through the whole processing chain
--> INFN to work with STFC on the testing

Ivan Diaz Alvarez:
- we are already discussing the representation of the new type of information. It seems to require minimal development in the portal

Discussion:
- Where and how will the number of robot users be displayed?
* The number of users is currently publicly displayed in the Operation Portal. This is picked up by the Operations Portal from VOMS (so the number includes only personal certificates, and robot certificates, but not the robot certificate users).
* The robot user numbers will be known by the Accounting Portal --> The Operation Portal should pick up the robot user number from the Accounting Portal, for example using an XML feed (the VO activity XML feed?) --> Diego to discuss the details with the Accounting and Operation Portal providers.
* Sensitive information about robot users can be displayed but only for the VO managers (in the Accounting Portal or in the Operation Portal?) --> Diego to discuss the details with the Accounting and Operation Portal providers.

Marco Verlato:
- Concern that one robot certificate would be used by all the users across multiple science gateways. The WeNMR gateways store files in rather complex directory structure for the users, this should be changed because of the change in the proxy used -->  INFN to follow up with WeNMR to understand how much change would be required in their portals

Sorina Pop:
- The VIP is using DIRAC to submit jobs into EGI. We still yet to understand how much effort it would be to implement the eToken server in VIP, and in DIRAC, and whether they have the effort for this. --> INFN to follow this up with the VIP team

Zoltan Farkas (SCI-BUS):
- Some of the users do not specify their name when they sign up for a science gateway account. They have e-mail address, and an ID --> Diego: Any unique string can be used to make the robot proxies unique. The portal has to be able to map a real identity to this string --> Zoltan to check what information the SCI-BUS portals are collecting about users, and how the unique IDs should be chosen for the proxies
- Currently SCI-BUS portals are fetching robot proxies from MyProxy servers. This should be extended with another option: fetch proxies from eToken servers. This seems to be a relatively small amount of work, and can be done in the next few months. --> Diego to follow up with Zoltan

Gergely Sipos:
- In what format does INFN Catania offer the eToken server?
Giuseppe La Rocca:
* As an online service - there are two servers at the moment in Catania. They are configured with different smart cards. Additional servers can be setup if needed
* As an open source software (in sourceForge). Science gateways can operate local instances to generate proxies.
- What's the difference between RFC and Legacy proxies? Which one can be used with the EGI middleware services?
Diego Scardaci:
* Legacy proxies are supported by middleware services from start
* RFC proxies are new variants, and the middleware services are gradually migrating to this. At the moment they support both RFC and legacy proxies.
* The EGI Federated Cloud works only with RFC proxies

Marco Verlato:
- in wenmr we add also the VOMS group info in the proxy, would be that supported?
Diego Scardaci:
- The VOMS extension is not affected by the extension of the proxy DN, so VOMS groups remain as they are in the proxy.