Add mapfile support for XrdVoms

[matyasselmeci]

We'd like to be able to create a mapfile for voms authentication such that we can choose the mappings between FQANs and Unix users; this is needed for multiuser to work. VOMS mapfiles are made of lines like

"FQAN-PATTERN" USERNAME

where USERNAME is a Unix user and FQAN-PATTERN is a glob.

For GSI, mapfile support is built in, but we've been told it's better to write a post-auth plugin for VOMS instead.

[brianhlin]

@vokac mentioned this morning that VOMS mapfiles are something that they'll want for StoRM as well

[abh3]

Indeed, the more we delve into this the more is seems we really need a discussion. How about using part of the XCache meeting for this as the principals here attend the meeting as well. Brian, Matyas can either of you to set something up

[wyang007]

Isn't this already supported? I thought that RAL ECHO uses gridmap. Should we check with James Walder?

[abh3]

It is in GSI but not for http.

…

On Mon, 25 Oct 2021, Wei Yang wrote: Isn't this already supported? I thought that RAL ECHO uses gridmap. Should we check with James Walder? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1538 (comment)

[vokac]

@vokac mentioned this morning that VOMS mapfiles are something that they'll want for StoRM as well

I was trying to explain why we like different unix accounts for production vs. analysis jobs (StoRM GPFS filesystem can be mounted rw locally on WN) => that's why we need special mapping of tokens to different unix accounts in HTCondor-CE. I have to admit it is not completely clear to me how this relates to XrdVoms module ... besides that XRootD may use same mapping library.

[brianhlin]

I was trying to explain why we like different unix accounts for production vs. analysis jobs (StoRM GPFS filesystem can be mounted rw locally on WN) => that's why we need special mapping of tokens to different unix accounts in HTCondor-CE. I have to admit it is not completely clear to me how this relates to XrdVoms module ... besides that XRootD may use same mapping library.

Ah, that makes sense. Nevermind then!

[bbockelm]

To return to the original topic -- my line of logic on this is:

• for the GSI-based authentication logic, we provide a mechanism for mapping from the X.509 subject to the XrdSecEntity user identity.
• by symmetry, for the VOMS-based authentication logic, we should provide a mechanism for mapping the VOMS FQAN to the XrdSecEntity user identity.

Don't think this is a "xrootd protocol versus HTTP protocol" question: we should strive to make those behave similarly.

[wyang007]

Hmm, Brian Lin was talking about VOMS mapfile. I thought he was talking about gridmapfile... Then this is a question of whether we want two different kinds of authorization "DB".

[bbockelm]

I think two types of authentications is reasonable as we have two types of authentication mechanisms (GSI and VOMS). I don't view these as authorization DBs as they simply populate fields in the XrdSecEntity and don't make authorization decisions.

One interesting question is precedence: currently, GSI and VOMS fill in mutually-exclusive fields in the XrdSecEntity for making authorization decisions. If both could fill in the user field, which should "win"? GSI over VOMS seems reasonable to me (and what's been done in the past).

It is possible (and not entirely irrational) to have a unified mapfile which has both VOMS FQAN and GSI DN's intermixed. That is more flexible than independent mechanisms but I can see the possibility for confusion.

[wyang007]

You are right, I wasn't thinking straight. mapfiles (GSI or VOMS) aren't auth DB.

The thing I like about the current auth DB is that, for VOMS, it is a single place to config. I don't have to worry about coordinating VOMS mapfile and auth DB (though we can't do the same for GSI). The thing I don't like is that the concept of "compound ID" in auth DB is a bit hard to understand and remember.

[bbockelm]

Hey Wei,

I think the VOMS mapfile tackles the case where there's an underlying storage system that really needs a "user name" that can't be derived algorithmically via the FQAN.

Examples I know about are EOS and xrootd-multiuser (the former does the "VOMS mapfile" by converting a VOMS FQAN to a long list of DNs and maps those to a single username... that kinda works but is problematic for other reasons).

Brian

[abh3]

Brian kindly provided a patch for this, so I am closing this ticket. This should appear in 5.5.0.