Hi ELvin,

Sounds good I will take a look today (I finally took some time off during
the long weekend to keep my sanity). You are correct this is a policy
decision. The way XRootD handles it is that you get to say what the policy
should be and I hink the only way to resolve this without a huge debate
that will just mire this in controversy is to do the same here. So, I
would suggest:

http.secxtrator [require] <shared library>

So, require simply means if VOMS fails to extract, authentication fails.
Otherwise, it does what you have. One could do the same for gridmap (as is
the case in XRootD). The big difference is that in XRootD, require is the
default. Since, HTTP has lived long enough without "require" one could
argue that this "non-require" behaviour should continue to be the case.

All of this is sort of deja vu as Brian correctly predicted years ago that
xrootd would simply wind up being re-implemented using http wrappers. His
prediction seems to have been correct.

Andy


On Fri, 3 Jul 2020, Elvin Sindrilaru wrote:

> I've redone the pull request in #1238. The VOMS attributes and the gridmap file are both optional configuration functionalities that don't necessarily increase the security but enforce a certain policy. Having any or both of them fail does not mean authentication was not performed or that the security was more relaxed - we do have a certificate for the user that we verified so this should already be good enough from the security point of view.
>
> The libXrdVoms.so plugin does what it should, namely saying there are no VOMS attributes to be extracted from a non-voms certificate. The XrdHttpProtocol was here at fault since it was denying access if the VOMS extractor returned an error - at the same time the libXrdHttpVOMS library was just faking an ok response when there were no VOMS attributes and this is why all this was working. I've fixed this in the XrdHttpProtocol so that an error response from the VOMS extractor is treated properly i.e. should not deny access for that request.
>
> Now all this work fine and with all types of certificates with the exception when access is done using a token. I mentioned this in the PR: https://github.com/xrootd/xrootd/pull/1238#issuecomment-653085407
> My patch does not change the behavior that exists in all current XRootD releases. If we want to allow this or not, whether it is good practice or not, I guess should be topic of a different discussion. PR #1238 allows proper handling of certificates, proxy certs and multi-delegated proxies in the context of gridmap files.
>
> --
> You are receiving this because you were assigned.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1236#issuecomment-653554322

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1236#issuecomment-654419880", "url": "https://github.com/xrootd/xrootd/issues/1236#issuecomment-654419880", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1