I agree with Elvin, and that makes the things more clear. On top
of that, also tokens may be involved, and noone has ever thought that
if there is no token then the connection has to be shutdown
by the token plugin.
So why should it be the case for VOMS? We are used to clients
coming with both, and the authorization decision must be clear
and simple. EOS and DPM use ACLs for that. Castor (and the
old DPM codebase) was instead entangling authentication
and authorization in a painful mix.
Frankly, I am totally for EOS and DPM...
And for the records, the "faux pas" is totally doable with Apache
(and indeed DPM uses that) so site managers should just
be properly informed on what to do... and/or given sound
configuration tools and examples.
... thoughts guys?
f
Il 02/07/20 12:19, Andrew Hanushevsky ha scritto:
> Because that is a security faux pas. No one does security that way. If I
> were CERN security I would just shit you down. Been there done that.
> Frankly, I don't think you can support both of those plugins in a secure
> way. For R5 you don't have to. However, if you adopt my middle ground
> approach then you can have your cake and eat it too.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/xrootd/xrootd/issues/1236#issuecomment-652921575>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABJBUT4OHE4RUS6UDHA4UMLRZRNLTANCNFSM4OOWIFAA>.
>
—
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-652927910",
"url": "https://github.com/xrootd/xrootd/issues/1236#issuecomment-652927910",
"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
