On 28/06/2021 10:36, Carsten Klein wrote:
Hi there,
I have two questions about Tomcat's Integrated Windows Authentication:
Tomcat is stuck on version 7.0.52 on an outdated Ubuntu 14.04 LTS.
Note that Tomcat 7 is no longer supported.
1. useDelegatedCredential = true
I'm using JNDIRealm together with the SPNEGO authenticator. If the
Realm's option 'useDelegatedCredential' is set to true, I'm getting
exception:
javax.naming.AuthenticationException: GSSAPI [Root exception is
javax.security.sasl.SaslException: GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Failed to
find any Kerberos tgt)]]; remaining name 'xxx.yyy.zzz...'
Everything works fine when not using delegated credentials, but
configured connectionName and connectionPassword.
What's the reason for that? Is it a Tomcat configuration issue? Or, is
the client (Google Chrome) not sending enough (credential?) information:
There is Chrome's Policy option 'AuthNegotiateDelegateWhitelist'
(deprecated, replaced by 'AuthNegotiateDelegateAllowlist') which must be
configured in order to delegate the user's identity. However, setting
any of these policy settings to true does not help.
See
https://www.chromium.org/developers/design-documents/http-authentication
Is it a limitation/setting in Active Directory Server? The exception
occurs after SpnegoAuthenticator has contacted ADS trough Kerberos. Is
the response obtained from that Kerberos call not suitable for using
delegated credentials?
That looks more like some form of configuration issue but I always found
the Kerberos error message rather hard to decipher.
2. Fallback Authenticator
We have some clients connected through VPN, whose Windows sessions are
not logged on to the Active Directory's Windows Domain, so Integrated
Windows Authentication cannot work. SpnegoAuthenticator reports 'No
authorization header sent by client'. However, I've not yet found a way
to fall back to e. g. FORM authentication for those clients.
AFAIK, there is no way to do this with Tomcat, since a Context can only
have one single authenticator valve.
Oracle's WebLogic Server support configuring more than one
authentication method, by adding something like
<auth-method>CLIENT-CERT,BASIC</auth-method> into web.xml.
What about adding support for that or something similar in Tomcat? A
CombinedAuthenticator (like with CombinedRealm) could be a solution.
That could instantiate other required Authenticator valves and pass the
request from one to the other until authentication succeeds. Those
valves must not necessarily be queued in the container's pipeline, but
could be called by the CombinedAuthenticator valve.
Thats likely not too simple but it could be done. Are you open to such a
solution?
It has been mentioned before. There is this on the Wiki:
https://cwiki.apache.org/confluence/display/TOMCAT/SSLWithFORMFallback
As with most enhancements, whether it is accepted is going to depend
largely on the benefit it brings vs how complex / invasive the code is.
Rémy mentioned he was looking for a development project. Maybe this
could be it.
I believe that only the SpnegoAuthenticator needs such a fallback, as it
uses mechanisms that you can't just add to any client. (In contrast, you
could always distribute a X509 certificate or use FORM, BASIC, or DIGEST
login. But you can't add your client to a Windows Domain just in order
to log in to an application.) Adding a fallback mechanism to
SpnegoAuthenticator only may be much easier.
What other solutions do you know?
You might be able to authenticate external users in a reverse proxy and
have it pass the user ID to Tomcat rather than have Tomcat do the
authentication.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
