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=
>