 |
 |
Hi Albert, OK, I want to do TPC, specifically redezvous TPC. I as a client have contacted the source server have potentially been authenticated but certainly authorized to access the file which is the subject of the TPC and presented the rendezvous key. I, the client, have also contacted the destination server and have been authorized to create the file there and have presented the rendezvoud key along with a TPC request to fetch the file from the source server. Now, when the destination server contacts the source server if the source requires authentication the dest server needs to comply. If not the dest server merely needs to present the rendezvous token and if it matches the one the original client etablished at the source the dest server can open and read the file (i.e. copy it). Now, xrootd accomplishes that and if dCache can do the same then no other tokens are needed other than the rendezvous token. If authentication is required the dest server must comply -- there is no escape around that. There should be no need for any other tokens than the rendezvous token. Does that answer the question? Andy On Tue, 29 Mar 2022, Albert Rossi wrote: > Hi Andy, > > I understand the points you are making below. So it is my fault for not making my concerns clearer. > > dCache can indeed accept scitokens for authorization without authentication. That is what I fixed. But that is not the problem. > > I was just trying to look at this from the standpoint of the client, and what Brian was originally worried about -- unless I've misunderstood that. > > So, let me re-ask the question in another way. > > I am an xrootd client. I want to do TPC. > > But my user does not want to expose a token on the path query as a CGI element. After the changes you have made/are making, authorization can fall back to the ZTN token, provided that token has expressed subject and claims as well as issuer and audience. > > But the server I am talking to does not have ZTN turned on; it only has enabled scitoken authorization. > > There is a token at XDG_RUNTIME_DIR in the env in which I initiate the transfer. > > Am I going to succeed in getting authorized? > > 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 <[log in to unmask]> > Sent: Tuesday, March 29, 2022 1:17 AM > To: Albert Rossi <[log in to unmask]> > Cc: xrootd-dev <[log in to unmask]> > Subject: Re: ZTN and TPC > > Hi Albert, > > Lots of questions here. OK, so let me frst say what is going on here. > > a) When enabled, ztn simply asks the connecting client (irrespective of > what it is going to do) to provide a valid token. This token may or may > not be used for future authorization purposes. That decision is totally > independent. Why? Because at the point we ask for a ztn token all we want > to know is that the client has or can obtain a valid token. That is all we > care about. So, the following points must keep this in mind. > > On Fri, 25 Mar 2022, Albert Rossi wrote: > >> However, that is not the question I have. What I am writing about here >> has to do with ZTN in this equation. If your ZTN module is loaded, how >> does it know to allow the third-party client to get a "pass", since that >> client does not have any JWT token? > Totally independent decision points. Consider this: > a) Client logs in and at that point we have no idea what the purpose is > but we ask for a ztn token. > b) Client supplies one and we check if it is valid, if so, client is > allowed to proceed. > c) Client wants to do a TPC. Perfectly acceptable. Does the ztn token have > anything to do with that? Not necessarily. In fact, we really don't know > and wish Brian would weigh on this but alas no word. > >> Or does it still get the ZTN token even though it does not provide a >> token for authorization to the source server? > Again, please reread the beginning statement. When we ask for a zrtn token > we only wish to ascertain the client's ability to get one. It has nothing > to do with any future autrhorization. To the extend that the authorization > module may use the zn token is up to that module. We really don't care. > >> Or do you have to turn ZTN off with TPC? > > Absolutely not! That is not what the primary purpose of ztn is. I think > you are really confusing the purpose of ztn and what redezvous TPC is > trying to accomplish. The problem here is that unlike xrootd where we can > easily suppress authorization when we know this is a rendezvous TPC dCache > appears not to be able to do this. So, it needs some kind of token in > addition to the rendezvous token to move forward. The question is which > token are we talking about. My asnwer is without Brian's weigh in I don't > know and there is silence at his end. So we are both out of luck. > >> I am asking these questions because I have not figured out, for dCache, >> how to (a) specify ZTN as an authentication protocol, but (b) allow a >> specifically third-party connection not to have to present a ZTN token. >> At authentication time, it does not seem to me the server knows enough >> about the client to be able to distinguish what it is. >> Or does it? > No it does not matter. The problem here is that any server may ask for a > ztn token and you better be prepared to supply one or have another > authentication protocol you can fall back to. I would suggest the simplest > approach here. In the presence of a TPC should the target server ask for a > token then you supply the ztn token should you have it. If you do not then > you will need to fallback on some other authentication protocol that the > target server supports. If there is no other protcol then whole thing > simply fails and you live with that. > > Andy > > > Some guidance here > would be very helpful, > > Thanks, 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 >> >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIBAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=9aahSq-wsU59ZSWZ00xk_zy5ZFU6hyg63E0HPoGzJQ8F6TWVj47l3nCukhbHNHEw&s=_VQWTuyj544srHCnttohyT1-ZjVHIbgM2r3_V-1H_Oo&e= >> > ######################################################################## 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