Initial code to internally proxy security credentials with a macaroon. #1115
Conversation
This causes HTTP requests coming in using an X509 proxy to generate a new macaroon used internally. Since the macaroon serializes the security session, this avoids problems to forward authorization if this is a gateway.
|
@ffurano - this is the code we had been discussing today: it should allow an EOS gateway to forward authorizations along as if the HTTP request came in with a token. With this, the "HTTPS smoke tests" work when run in gateway mode! |
|
@bbockelm : you are linking now https://github.com/xrootd/xrootd/pull/1115/files#diff-db7a029d325861c5a1b6bacccc3f20edR55 but there is no guard checking if https://travis-ci.org/xrootd/xrootd/jobs/637440081?utm_medium=notification&utm_source=github_status this needs fixing before we can merge ;-) |
|
If you just want to make the linking to the Macaroons library condition on 0001-Conditional-link-Macaroons-lib.txt |
|
The question is: after this PR gets merged will XrdHttp be still functional if libmacaroons are missing? this is to be answered by @ffurano and @bbockelm and possibly @abh3. (we are building for platforms were libmacaroons are not available, though I don't think anyone is using those platforms to run XrdHttp) |
|
Hi @simonmichal - (Sorry for the delayed response - travel last week really knocked me out of commission) Cleaning up the various build issues and ensuring things are conditionally compiled only on platforms with However, I'm still waiting to hear back from @ffurano on whether this new feature is the way he wants to go with the code. When we originally talked about this at CERN, he was reluctant about the whole approach given that he and Andy had previously discussed a different path based on SSI security instead. If folks are willing to merge this, I can do the remaining untangling of the build... Brian |
|
Hi, I think that your comment tells it all: "useful when an internal filesystem (such as XrdPss) does not have the ability to forward an XrdSecEntity but might understand macaroons." The approach is solid, it's a pity that the internal theoretically orthodox approach (i.e. through XrdSec) has to be worked around in such ways, and I totally see the point for this kind of things. I can merge it, will you please fix the build errors Brian? |
|
Well, that seems to backtrack on everything that we agreed on and that was
not to branch at the security level as that would essentially create two
copmplete and different services that would likely never converge. A total
mess if you ask me. We also agreed, well thought we did, that we would use
the SSS approach to carry through the the credentials as this was
uniformaly the way it was expected to be done. Now I see that is off the
table. Does that mean any more development for SSS is also off the table
(i.e. not desired)? Obviously, I don't agree with this approach unless you
all want to create a big mess. I'm not into big messes.
Andy
…On Mon, 24 Feb 2020, Fabrizio Furano wrote:
Hi,
I think that your comment tells it all:
"useful when an internal filesystem (such as XrdPss) does not have the ability to forward an XrdSecEntity but might understand macaroons."
The approach is solid, it's a pity that the internal theoretically orthodox approach (i.e. through XrdSec) has to be worked around in such ways, and I totally see the point for this kind of things.
I can merge it, will you please fix the build errors Brian?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1115 (comment)
|
|
Should be available in 5.1 if not sooner.
…On Tue, 25 Feb 2020, simonmichal wrote:
For the record, the SSS approach is being tracked in #1138, @abh3 : could you give us a timeline for this development? I suppose if there is a consensus that #1138 makes this PR unnecessary we could close this it, @bbockelm , @ffurano what's your opinion?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1115 (comment)
########################################################################
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
|
|
Hi, I understand the direction of willing to keep the xrootd protocol in the back of a gateway, and it makes sense to me. Even if I like the idea of a macaroon for this use case I'd also vote for the XrdSSS approach, and hope that it becomes able to forward the additional info that an XrdSecEntity instance can hold. |
|
I’m certainly happy to close this out (SSS is a more comprehensive approach if taken) if the 5.1 timeline works for EOS! Maybe ping Elvin on it? (At any rate, glad we forced the discussion and didn’t try to merge it into 4.11.2!) |
|
I've just crosschecked with Elvin and it seems he no longer needs a proxy for HTTP, hence from EOS side there's no desire for this PR. |
|
Yes, good that we settled things. Please take a look at the new SecEntity
structure. It supports additional fields as well as arbitrary passive
(i.e. key-value) and active attributes (i.e. pointer-object). At the
moment, everything except active attributes will be relayed (mostly
because there is no workable model for active attributes. Active
attributes are meant to be used at the node that deals with the
SecEntity structure -- for example, authorization that can use such an
attribute to reuse authorization credentials without needing to rebuild
them each time). If anything is missing, now is the time to speak up.
…On Tue, 25 Feb 2020, Brian P Bockelman wrote:
I?m certainly happy to close this out (SSS is a more comprehensive approach if taken) if the 5.1 timeline works for EOS! Maybe ping Elvin on it?
(At any rate, glad we forced the discussion and didn?t try to merge it into 4.11.2!)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1115 (comment)
########################################################################
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
|
|
I suppose we can close this PR? |
|
Yup! Looks like I have the ability to close this ... thanks for the feedback everyone! |
|
Yes, I think you can.
…On Mon, 9 Mar 2020, simonmichal wrote:
I suppose we can close this PR?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1115 (comment)
########################################################################
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
|
This causes HTTP requests coming in using an X509 proxy to generate a new macaroon used internally. Since the macaroon serializes the security session, this avoids problems to forward authorization if this is a gateway.