 |
 |
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://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 > ######################################################################## 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