LISTSERV 16.5 - XROOTD-DEV Archives

Just as a follow, and perhaps to state the obvious here.

The way ALICE's authorization scheme for TPC works (with dCache) is:

1. the directive --tpc delegate only is used. This ensures that the tpc.scgi element is included in the opaque data given to the destination.
2. that tpc.scgi contains a separate authz= token.
3. The scgi becomes the cgi of the path used by the third-party client when communicating with the source server.

In this schema, it is then a matter of having the initiator/moderator of the TPC (in this case, xrdcp) pass two tokens, not one. The second token is the one in the tpc.scgi, which I suppose we could refer to as the 'delegated' token, though it is not so in the sense that it should be used and then reused, but simply a token destined for the TPC client.

Is such a strategy not generalizable?

Al

________________________________________________
Albert L. Rossi
Senior Software Developer
Scientific Computing Division, Scientific Data Services, Distributed Data Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023

________________________________
From: Albert Rossi ***@***.***>
Sent: Thursday, March 24, 2022 7:00 AM
To: xrootd/xrootd ***@***.***>; xrootd/xrootd ***@***.***>
Cc: Mention ***@***.***>
Subject: Re: [xrootd/xrootd] ZTN and Scitokens auth (Issue #1584)

Hi Andy,

Thank you for this very good summary of the situation. It reflects perfectly what I remember discussing with you last year.

I am interested to know what Brian thinks of all of this.

It would be nice to keep dCache on the same page as everyone else in this regard.

Cheers, Al

________________________________________________
Albert L. Rossi
Senior Software Developer
Scientific Computing Division, Scientific Data Services, Distributed Data Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023

________________________________
From: Andrew Hanushevsky ***@***.***>
Sent: Wednesday, March 23, 2022 8:16 PM
To: xrootd/xrootd ***@***.***>
Cc: Albert Rossi ***@***.***>; Mention ***@***.***>
Subject: Re: [xrootd/xrootd] ZTN and Scitokens auth (Issue #1584)

Hi Albert,

Correct, while TLS would have been preferable the additional safeguards put in place to protect the rendezvous token made it highly unlikely to be subverted (you would need to accomplish at least three other subversion before the token became vulnerable). Now that TLS is widely available nothing prevents the token being transmitted using TLS, though for backward compatibility, it's not required.

As you state it, the door is not in a position to use the rendezvous token presented by the destination since it needs to authenticate the destination first. So, if that's how the code sits then, yes, without skipping authorization in the presence of a token, it would not work. Mind you rendezvous tokens are only meant to be used for pull requests so they are incapable of performing and destructive action.

So, presumably you are wondering that one could get around the problem by having the destination use a JWT along with the rendezvous token. The issue here is how does one get the JWT? I was told that it can't be the requesting clients JWT as these are not delegable, though I still don't see what prevents them from being used by someone else, hence why they need TLS. The destination server is also not really in a position of getting a JWT. Seems like an issue here.

Of course, that all hinges on whether the requesting client's JWT cannot be used by the destination server. If it can be (or at least if the client can get a delegable token) then, yes, we could handle the rendezvous in that way. That said, why bother with a rendezvous token at all since we could do the same thing with JWT's can't we?

So, in the end we need to get all of this straightened out to figure out the positioning of a rendezvous TPC. Maybe @bbockelm<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bbockelm&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=aPJycUjsDal5ouobRnOW-RIHzPPgfWgiSWaEQX9bqly0KTaVVNSqf2rh9RFPwBN8&s=XQ9LPm9jjB3Nc1AWnQVIzoJOOqlATM4CeXN4TWvFKIM&e=> will see this post and expand on how a requesting client's JWT can and cannot be used in a TPC context by the destination server.

—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_xrootd_xrootd_issues_1584-23issuecomment-2D1076971468&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=aPJycUjsDal5ouobRnOW-RIHzPPgfWgiSWaEQX9bqly0KTaVVNSqf2rh9RFPwBN8&s=kwUKeUD7KFApYCw0rQ2DjTJvo5dbooGDeHSLNRZojhA&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA6NBHAAQLWSENTBDTXTOJDVBO65TANCNFSM5LUMRMZQ&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=aPJycUjsDal5ouobRnOW-RIHzPPgfWgiSWaEQX9bqly0KTaVVNSqf2rh9RFPwBN8&s=DoVAXQRpM6K5_rzgHcu8DNgRSaVo7hdn_qFBeufS2hg&e=>.
You are receiving this because you were mentioned.Message ID: ***@***.***>

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

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1584#issuecomment-1077829942", "url": "https://github.com/xrootd/xrootd/issues/1584#issuecomment-1077829942", "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