Macaroon IdMap

Site Administrators
1

Hi all,

WLCG wants to retire gridftp and enable webdav for all sites, we’re in the process of setting this up.
We have a functional setup to access our site with webdav and certificate auth.
However, it’s not fully working for macaroons. I’m wondering if I’m missing config of if the mapping does not work as I expected with macaroons. I used a tesst installation. of EOS 4.8.39 to test this.

With macaaroons, first you get aa token from the server (with certain privileges) then you can use this token (for a limited time) to access files. I captured the token create request from the logs (added line breaks for readability):

210223 12:19:11 95403 sysMacaroonGen: ID=e2cf9a56-7117-40ba-a97b-6452adbe7828, resource=/eos/dev/scratch/asdf, 
name=/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ebirngru/CN=845559/CN=Erich Birngruber, host=[::ffff:172.24.96.242], 
vorg=cms, role=NULL, groups=/cms /cms/Role=NULL /cms/Role=NULL/Capability=NULL, endorsements=/cms/Role=NULL/Capability=NULL
base_activities=activity:READ_METADATA,UPLOAD,DOWNLOAD,DELETE,MANAGE,UPDATE_METADATA,LIST, 
user_caveat=activity:DOWNLOAD,LIST, expires=2021-02-23T11:49:11Z

note the attributes: name, vorg, role, groups etc.
I used the example from the docs (HTTP(XrdHttp) and XRootD TPC with delegated credentials — EOS CITRINE documentation) to decode the token:

>>> print M.inspect()
location eosdev
identifier e2cf9a56-7117-40ba-a97b-6452adbe7828
cid name:/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ebirngru/CN=845559/CN=Erich Birngruber
cid activity:READ_METADATA,UPLOAD,DOWNLOAD,DELETE,MANAGE,UPDATE_METADATA,LIST
cid activity:DOWNLOAD,LIST
cid path:/eos/dev/scratch/asdf
cid before:2021-02-23T11:49:11Z
signature 29ff657a1abee5f12819661cfb5f7c475fcd01d531c7d4c525bafca5b4db0312

The “name” attribute was added, but none of the vorg, role, group attributes. When the request is made, the “name” attribute is used to do a lookup in the grid-mapfile to get an actual user identity. Consequently we would have to have a fully blown gridmap file next to the existing EOS vid map config (plus I don’t think we can fully map our EOS vid config to a gridmap file alone - i.e. gid mappings).

What I would like to achieve is this:

  1. macaroon generate request is made
  2. all voms attributes are added to the token (vorg, role, group)
  3. when the request is made with the macaroon token these attributes are used to map the user id through the EOS vid mapping parts to get a id mapped
  4. that id is used to access the file

Best,
Erich

2

Hi Erich,

For the moment using the grid-map file is the way EOS instance at CERN work. The functionality that you are expecting is not there yet and there are multiple reasons for this: first the way all these plugins are stacked makes it cumbersome to take into consideration the eos specific vid map in the early stages of authentication. Then the fact that only the name value is passed in the Macaroon is a thing specific to the Macaroon library which I believe is not so easy to change.

Having said this, we are looking into ways to accommodate the token paradigm without the need for a gridmap-file, but it is still not clear yet (still being discussed in the various WLCG working groups) what is the best way to go. I will let you know once we have new developments in this area. But for the time being the gridmap file is the way to go as it would then embed directly the local user identity in the token which will be used when doing various operations.

The gridmap file is populated with info from the various voms-admin endpoints using edg-mkgridmap, for example for CMS:

# cms
group vomss://voms2.cern.ch:8443/voms/cms?/cms/Role=cmst0admin phedex
group vomss://voms2.cern.ch:8443/voms/cms?/cms/Role=cmst1admin cms001
group vomss://voms2.cern.ch:8443/voms/cms?/cms/Role=cmst2admin cms002
group vomss://voms2.cern.ch:8443/voms/cms?/cms/Role=cmsprod cmsprod
group vomss://voms2.cern.ch:8443/voms/cms?/cms/Role=production cmsprod
group vomss://voms2.cern.ch:8443/voms/cms?/cms cms003

Cheers,
Elvin

3

Hi Elvin,
Thanks, we’re preparing to use edg-gridmap for this. supporting this in vid map would be greatly appreciated!
For context: we use vid / voms mapping for all generic use cases.
For our local users (i.e. a defined set), we will use the gridmap file to map them to their local user accounts to access data outside of experiment hierarchy. Effectively they have different identities when they come with or without VOMS extension - this has worked nicely for us so far, but as things are now we won’t be able to continue with this.

Best,
Erich