Actually, I misdescribed the anonymous access to the door.
An unauthenticated connection when authentication is turned off in dCache gets permission to do nothing, but is not rejected until it tries to. This allows us to wait until the third-party connection presents the rendezvous key, at which point we give it permission
to read the file.
Obviously we don't want to give read-only permissions up front to everyone (unless some other policy dictates it) on that door. So if the initiating client calling open does not get authorized by a bearer token, then it will have no authorizations to do anything,
and the third-party client will also fail, as it should.
Brian,
Actually, my problem is with the TPC connection from the destination server.
Let me explain it this way:
xrootd client => requests open on source with provided rendezvous key
xrootd client => requests open on destination with
provided rendezvous key
third-party client =>
requests open on source with the rendezvous key in hand
However the xrootd client gets authorized on the source really doesn't matter here, just so long as it does. It should know, before the third-party connection, whether it has permissions to open that file there. Successful open means it does, and implicitly
its third-party proxy client should be permitted as well.
So I find nothing wrong with a strategy whereby dCache allows anonymous read-only access to the source (i.e., no necessary authentication). If the xrootd initiator never authenticates
(remains anonymous), the permissions to read the file will depend on the underlying ACLs anyway. When the third-party client connects, on the other hand, it is "allowed through" the authentication by this anonymous permission, but since it holds the
rendezvous key which is checked, will implicitly be authorized to read the file, which is all that is necessary.
The dCache code actually was already capable of handling this, except that I introduced a check when I implemented bearer token handling which
inadvertently defeated it. I have rectified this.
My issue is now: what happens with ZTN?
From the prior discussion and recent changes, I gather that it has now become desirable always to use ZTN because this allows you to bypass having to express the bearer token which authorizes a path request as part of the path query.
dCache supports ZTN on the server (door). But if I turn on ZTN, dCache is going to ask for the ZTN token from all clients, because at authentication time I don't think there is a way to distinguish between incoming connections such that I can make an exception
for third-party clients.
So, from where I am standing, we are left with one of two choices:
(a) TPC requires ZTN and the TPC client must be provided a ZTN token somehow.
(b) If the server does not require ZTN, but there is no bearer token explicitly included on the path as ?authz=Bearer%20 element, the client somehow knows to add any token it finds at XDG_RUNTIME_DIR to the path CGI.
Obviously (b) presents problems, and is not really feasible.
So if you don't want to express the token as a CGI element, then, it seems to me the only choice here is to make sure the third-party client has a ZTN token.
But if the third-Party client has a ZTN token, and the ZTN token can be used as fallback for authorization, then why do we need the rendezvous strategy? Seems we are already delegating a token to the third-party client this way.
??
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
Hi Al,
I know very little about the XRootD TPC protocol. But, I'm back from vacation so I can at least speculate!
The problem is we need an authentication mechanism for the XRootD session before we can provide the rendezvous token to the remote server, right? Further, using the host certificate as a client certificate is a pretty lousy option given some
CAs (think: let's encrypt) issue host certificates that are only reasonably usable for TLS servers and not clients.
One nice thing about bearer tokens is they are supposed to be opaque -- there's no need to assume they are a JWT. What if we used the rendezvous token for the ZTN authentication?
Brian
Hello all,
starting a fresh thread here in reference to TPC with tokens.
I believe I have fixed the dCache door to allow for TPC with JWT tokens by allowing the third-party client to pass through authentication if it has the correct rendezvous key/token and TLS is on. It certainly works for dCache to dCache, and I am trying to
confirm dCache to xrootd and vice versa, but I am struggling to get the xrootd server set up properly to authorize using the token issued here at Fermilab.
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?
Or does it still get the ZTN token even though it does not provide a token for authorization to the source server?
Or do you have to turn ZTN off with TPC?
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?
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