Re: Questions about Integrated Windows Authentication
Sorry Mark, I've clicked the wrong button in my mail client :( On 28.06.2021 15:29, Mark Thomas wrote: Note that Tomcat 7 is no longer supported. I guess it's nearly the same for all versions of Tomcat. That looks more like some form of configuration issue but I always found the Kerberos error message rather hard to decipher. AFAIK, the Kerberos is working fine. This error occurs in JNDIRealm's getPrincipal method. One log line before, Kerberos reports Found ticket for HTTP/apps.atlas-03t.gvsn.local@GVSN.LOCAL to go to krbtgt/GVSN.LOCAL@GVSN.LOCAL expiring on Thu Jun 24 18:26:05 CEST 2021 So, there is a ticket. However, JNDIRealm cannot use it or the ticket does not allow binding to the directory with that user. I'm not understanding the whole process, so I was asking if someone has more glue on that. 2. Fallback Authenticator It has been mentioned before. There is this on the Wiki: https://cwiki.apache.org/confluence/display/TOMCAT/SSLWithFORMFallback Will have a look at that. It's basically what I was thinking about adding a fallback to SpnegoAuthenticator only. 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. For sure. Rémy mentioned he was looking for a development project. Maybe this could be it. I guess, Rémy was taking my user attributes Realm extension as development project... 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. I read about that somewhere some months ago. However, I don't know how to get the authentication from the reverse proxy (my Tomcat already runs behind an Apache HTTPD using mod_proxy_ajp) to Tomcat? Finally, Tomcat needs the Principal and a couple of roles for authorization (including my additional user attributes). Passing the user ID only is likely not sufficient. Could you please describe that in more detail or point me to some sites to learn more about that? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Questions about Integrated Windows Authentication
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 CLIENT-CERT,BASIC 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
Questions about Integrated Windows Authentication
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. 1. useDelegatedCredential = true I'm using JNDIRalm 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? 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 CLIENT-CERT,BASIC 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? 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? Carsten What other solutions do you know? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
