dcache-xroot: Allow ZTN authentication to function as fallback author…

…ization

Motivation:

Originally, the 'ztn' protocol was conceived of as a way
of preliminarily checking the legitimacy of a client by
asking the client to produce a token and checking its
issuer.   The ztn token was not required to have a sub
or claim.  This was in distinction to the actual JWT
authorization token to be included as the authz element
on the path query.

However, for a number of different reasons, the SLAC
team has decided that the ZTN token, if desired, should
serve as a fallback authorization token, eliminating
the requirement of expressing that token in the path query.

This patch makes a modification to support this change.

Modification:

In order to check the validity of the ZTN token when
the ZTN module is loaded as plugin, it is passed to
gPlazma as a private credential.  Since it was not
being used for authentication purposes, the login
policy used by ZTN was anonymous.  This, however,
obliterated the token, once validated, from the
subject stored as login reply.

A simple change to use the UnionStrategy, like every
other authentication module, rectifies this situation.

See further the testing below for how this should now
work.

Result:

A ZTN token can now be given without further downstream
tokens expressed, and full authorization of the subject
will take place.

Target: master
Request: 8.0
Request: 7.2
Patch: https://rb.dcache.org/r/13498/
Requires-book: yes (part of patch)
Requires-notes: yes
Acked-by: Dmitry

docs/TheBook/src/main/markdown/config-xrootd.md

@@ -302,9 +302,77 @@ it will not be turned on.
 > of whether the server supports TLS or has indicated that it should
 > be turned on.
 >
-> By using 'xroots', the client guarantees TLS will by on at login or
+> By using 'xroots', the client guarantees TLS will be on at login or
 > the connection will fail.
 
+####  Scitokens (JWT) and the ZTN protocol
+
+Scitokens are for authorization; however, the XrootD protocol also defines an authentication
+equivalent, ZTN, where a token is passed as a credential at authentication (just after login).
+
+Originally, this was a countermeasure taken to prevent stray clients from accessing the
+vanilla server via methods where there was no path (and thus no CGI authz element).  However,
+recent changes to the vanilla client and server have allowed a ZTN token to be used as
+a fallback authorization token as well, without further need to express a base64-encoded token
+as part of the path query.
+
+dCache now supports this strategy.  To illustrate, here are two different door configurations.
+
+This one:
+
+```
+[xrootd-1095-${host.name}Domain]
+dcache.java.memory.heap=2048m
+dcache.java.memory.direct=2048m
+[xrootd-1095-${host.name}Domain/xrootd]
+xrootd.cell.name=xrootd-1095-${host.name}
+xrootd.net.port=1095
+xrootd.authz.write-paths=/
+xrootd.authz.read-paths=/
+xrootd.plugins=gplazma:none,authz:scitokens
+xrootd.security.tls.mode=STRICT
+xrootd.security.tls.require-login=true
+xrootd.plugin!scitokens.strict=true
+```
+
+indicates that any client will be allowed through with anonymous credentials (NOBODY) at
+authentication time, but ultimately will need a token on the path in order to be authorized, with
+the subject and claim being converted into dCache user and restrictions at the time of the request
+containing the path.
+
+This configuration:
+
+```
+[xrootd-1095-${host.name}Domain]
+dcache.java.memory.heap=2048m
+dcache.java.memory.direct=2048m
+[xrootd-1095-${host.name}Domain/xrootd]
+xrootd.cell.name=xrootd-1095-${host.name}
+xrootd.net.port=1095
+xrootd.authz.write-paths=/
+xrootd.authz.read-paths=/
+xrootd.plugins=gplazma:ztn,authz:scitokens
+xrootd.security.tls.mode=STRICT
+xrootd.security.tls.require-login=true
+xrootd.plugin!scitokens.strict=false
+xrootd.authz.anonymous-operations=FULL
+```
+
+on the other hand, turns on ZTN in the door.  For seamless functioning, this should be coupled with
+a loosening of the strict requirement on the CGI/path token, and FULL anonymous access (which just
+means that an anonymous user will be allowed to try all operations, with underlying acls determining
+whether these succeed or not).   With this configuration, the client will need to be provided
+a ZTN token via an environment variable, e.g.,
+
+```
+XDG_RUNTIME_DIR=/run/user/8773
+```
+
+it will look for a file named 'bt_\<uid\>' in that directory.   With that token in hand, authorization
+will also take place.  A second token can still be passed as the path query CGI element (authz=Bearer%20),
+and will override the original if present, but this is treated as optional, not required.
+
+
 #### Token-based authorization as suggested in [http://people.web.psi.ch/feichtinger/doc/authz.pdf](https://www.psi.ch/search/phonebook-and-e-mail-directory?q=feichtinger).
 
 The first thing to do is to setup the keystore. The keystore file

modules/dcache-xrootd/src/main/java/org/dcache/xrootd/spring/GplazmaAwareChannelHandlerFactoryFactoryBean.java

@@ -129,20 +129,12 @@ private ChannelHandlerFactory createAuthenticationHandlerFactory(
             if (authnFactory != null) {
                 ProxyDelegationClientFactory clientFactory
                       = createProxyDelegationClientFactory(name);
-                /*
-                 *  for ztn we don't want to use the union strategy because it has
-                 *  no specific authentication strategy and we don't want to allow
-                 *  anonymous operations on the door.  We just want the user to be 'nobody'
-                 *  until further authorization, such as using tokens, takes over.
-                 */
-                LoginStrategy loginStrategy = "ztn".equals(name) ?
-                      _anonymousLoginStrategy : _loginStrategy;
                 return new LoginAuthenticationHandlerFactory(GPLAZMA_PREFIX + name,
                       name,
                       clientFactory,
                       _properties,
                       authnFactory,
-                      loginStrategy);
+                      _loginStrategy);
             }
         }