EGI VMOps dashboard & VO entitlements

(Giuseppe La Rocca) #1

Hi All,

I would like to update you about the technical meeting today I had with Alexander Nakos and William Karageorgos from IASA.

During the meeting we have discussed how to reduce the waiting time between the registration of the user in one of the available VOs and the access to the VMOps dashboard.

So far the workflow is the following:

  • The user starts the enrollment procedure to join a new VO (e.g.: VO)
  • The VO manager is notified by the EGI AAI Check-In about the new pending request
  • When the VO manager approves the request, the user becomes member of the User Community.
  • The EGI VMOps dashboard uses the EGI Operations Portal API to integrate additional info for the user (e.g.: vm_operator and vo_member entitlements). These APIs are used in a cron which is executed every 12h.

During the meeting we agreed that the easiest way to speed up the integration of the VO entitlements for the users is to use the EGI AAI Check-In REST API that I am currently using for the members of the EGI AoDs.


To set-up the two VO entitlements for the user:

I have created this simple python script [1]

]$ python [.] Set VO membership information for a given EGI ID [ Request ] = [ Payload ] = {u’RequestType’: u’VoMembers’, u’Version’: u’1.0’, u’VoMembers’: [{u’Status’: u’Active’, u’VoId’: u’’, u’Person’: {u’Type’: u’CO’, u’Id’: u’’}, u’Version’: u’1.0’, u’ValidThrough’: u’2020-06-29’, u’ValidFrom’: u’2019-05-29’}]} [.] Get VO membership information for a given EGI ID [ Request ] = [ Response ] - [{u’status’: u’Active’, u’vo_id’: u’’, u’valid_from’: u’2019-05-28T21:00:00.000Z’, u’valid_through’: u’2020-06-28T21:00:00.000Z’, u’epuid’: u’’, u’id’: 110}]

With this REST API the two VO entitlements are immediately available for the user and he/she can immediately login the EGI VMOps dashboard and deploy VM topology in the EGI infrastructure as soon as the request is approved by the operator.

Now, before to adopt this approach also to other VOs supported by the EGI VMOps dashboard we have to:

  • Ask Nicolas whether it is possible to extend these REST APIs also to other VOs
    • I’m already VO manager of, and VOs
    • I’m going to contact him.
  • Think about a workflow to manage requests every time a customer ask us to enable a new VO in the EGI VMOps dashboard,
    • Should we (member of the EGI UCST (?)) register in the new VO as VO manager as well ? In this way we are notified when a new user’s request arrives and can use the above API to set-up the memberships

What do you think ?

Thank you

Cheers, Giuseppe


(Enol Fernández Del Castillo) #2

I think this needs some input from Check-in experts, I can only guess what’s going on but have no real information of the internal mechanisms.

The problem I see here is determining the “source of truth” for the user’s VOs. If it’s Check-in itself then there should be no real need to do this kind of tricks as Check-in can deliver the attributes directly.

If it’s an external source, then enforcing Check-in to add users to a given VO seems to me problematic as we would be effectively creating a new source of truth for the VO (how long should this membership enforced at Check-in need to be considered? what happens if the external source of VO membership never says the user is member of the VO? what happens if the user is removed from the VO?)

(Enol Fernández Del Castillo) #3

I believe this is not entirely true. For those VOs that are Check-in only (and we have some of these now), ops portal is not able to deliver any information about membership and AppDB is working fine. Also your solution is reinforcing this fact as you are just delivering the information needed by AppDB directly via Check-in and not via ops portal.

(Giuseppe La Rocca) #5

Indeed, for the VO we (EGI) are acting as a central authority to grant access to the VO based on the result of the vetting process. To do so, we are still relying on the EGI Check-In but via the REST API. With the REST APIs we set the VO entitlements (by default valid for 1 year), and when they are gone the user is not member of the VO anymore. In the end, we have still 1 “source of trust” ==> Check-In.

(Enol Fernández Del Castillo) #6

Kind of, this one is a bit tricky as users of the VO are managed at Check-in level, but the infrastructure is accessed with VOMS proxies that are completely independent of what Check-in says.

So we have “regular users” managed by Check-in and “infrastructure users” managed by VOMS, Check-in says the same for all of them, but source of information is different. This sort of mixed scenario works so far because we have deep control on all the pieces but can :boom: easily :slight_smile: