André, I was able to use the reference you made about making tomcatAuthentication false. With this Tomcat setting combined with HTTPD's mod_proxy_ajp proxy rules I was able to get this working. I am still testing this but looks clear to me that this is the solution. Thanks for the quick responses yesterday!
On Wed, Sep 19, 2018 at 5:10 PM André Warnier (tomcat) <a...@ice-sa.com> wrote: > Hi. > Much better.. > I don't know if I will be able to help you, considering my little > knowledge of Kerberos, > but I'm sure that someone else now will be. > > On 19.09.2018 16:08, Thomas Delaney wrote: > > Here is more detail into what I went through for setting up Apache > Tomcat.: > > I configured each Apache Tomcat instance using this bit of documentation: > > SPNEGO > > http://spnego.sourceforge.net/ > > > > I also used this documentation in order to get my workstation to accept > > Kerberos authentication and not default to NTLM. > > > https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM > > > > *I created/configured the following based on what was outlined from the > > SPNEGO doc:* > > login.conf > > krb.conf > > HelloKDC.java successfully connected when testing > > The SPNEGO filter in Apache Tomcat's web.xml > > Took the source code for spnego.jar and placed it in Apache Tomcat's > library > > hello_spnego.jsp successfully displayed the correct remote user on the > web > > page > > hello_delegate.jsp successfully displayed the correct delegated > credentials > > on the webpage. > > Ok, so we can assume > - that the basic Kerberos infrastructure works > - that you know how to set it up > - and that it works when you do the Kerberos authentication in Tomcat > itself, and access > tomcat directly from the browser. > > > > > Once I was able to verify that the above steps worked on Apache Tomcat. I > > tested the same web pages on Apache HTTPD. > > You mean "when accessing Tomcat /through/ the Apache httpd front-end, > right ? > > From your original description, I thought that you wanted to do the > Kerberos > authentication in the front-end Apache httpd, and pass on the > authenticated user-id to the > back-end Tomcats then. That's still an option anyway. > But from the description below it looks like you want to keep the > SPNEGO/Kerberos > authentication at the Tomcat level, and just want the front-end httpd to > be "transparent" > with respect to the Kerberos authentication exchanges. > Do I get this right ? > > I ran into issues when testing > > hello_spnego.jsp and hello_delegate.jsp. > > > > Here have been my results: > > hello_spnego.jsp -> "hello root !" (root being a unix user and not the > > AD/Windows user signed onto the domain). > > hello_delegate.jsp -> "No delegated creds." > > > > *Here is the section of the SPNEGO doc source on how to setup > > hello_delegation.jsp and create hello_spnego.jsp:* > > http://spnego.sourceforge.net/credential_delegation.html > > Mmm. This is quite complicated, but I think that I'm starting to guess > what the problem is. > I think that "delegation" is not really what you want to do here. It might > work in the > absolute (if everything was set up correctly to do it), but I believe that > it is overkill > in your case; and I believe that you are missing one piece of the puzzle > anyway. > > Taking into account my total lack of experience with SPNEGO/Kerberos > delegation - and thus > taking this with a grain of salt - I believe (from the above documentation > page) that for > such a delegation to work with an Apache httpd front-end, your browser > would /first/ need > to be authenticated already by the front-end (for example, "as you"), and > that this > front-end /itself/ would need to have /its own (separate) account/ in your > infrastructure > - and an account with special properties - in order to be allowed to > authenticate "as you" > (otherwise said : "impersonate you") with the Tomcat back-end's > SPNEGO/Kerberos Valve. > > > > > *Here is how I have Apache HTTPD forwarding requests to Tomcat. * > > Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" > > env=BALANCER_ROUTE_CHANGED > > <Proxy balancer://application> > > BalancerMember "http://localhost:8081/application"; route=node1 > > BalancerMember "http://localhost:8082/application"; route=node2 > > BalancerMember "http://localhost:8083/application"; route=node3 > > ProxySet lbmethod=byrequests stickysession=ROUTEID > > </Proxy> > > > > ProxyPass /application balancer://application/ > > ProxyPassReverse /application balancer://application/ > > > > What you are setting up here is a standard Apache httpd "reverse proxy > + load-balancer". But, as far as I can see from the above, this proxy > does not (itself) > authenticate the browsers which talk to it. > > So this front-end proxy does not really have a (browser-originating) > user-id for which it > would be able to request a "delegated authentication". > And it is also not set up to do "delegated authentication" with the > back-end Tomcat's > SPNEGO/Krberos Valve. > > This may be a bit confusing, and maybe this article explains it better > than I could : > > > https://blogs.informatica.com/2018/05/07/the-kerberos-conundrum-a-proxys-plight/#fbid=UtL4Ic19fwv > (Obviously, this is talking about some other front-end proxy software, but > you can see > that one needs something additional on the front-end proxy, to do this > kind of thing). > > All in all, if all that you need is that the application installed under > Tomcat would be > able to obtain an authenticated "current user-id", I would suggest that > instead of trying > to configure this using impersonation/delegation, you try something > simpler to set up : > > - remove the SPNEGO/Kerberos authentication part in Tomcat > - add an SPNEGO/Kerberos authentication at the Apache httpd front-end > level, so that the > front-end authenticates the user, *before* proxying the requests to the > back-end Tomcat > - then configure the front-end to pass along this by now authenticated > user-id, in the > requests that it passes to Tomcat > - and configure Tomcat to pick up this user-id from the request, and take > it as the > Tomcat-level user-id for the request > > For the first part, you could use this as a guide : > > http://www.microhowto.info/howto/configure_apache_to_use_kerberos_authentication.html > or this : > http://modauthkerb.sourceforge.net/configure.html > > For the second part, the easiest way is to use the AJP-protocol proxying > between Apache > httpd and Tomcat, as indicated in a previous message to the list. > > > > > > > > > > > On Wed, Sep 19, 2018 at 7:57 AM André Warnier (tomcat) <a...@ice-sa.com> > > wrote: > > > >> On 18.09.2018 23:24, Thomas Delaney wrote: > >>> Hello All, > >>> > >>> I have recently configured Apache Tomcat on a SuSe Enterprise 12 SP3 > >> server > >>> to get Kerberos SSO working with a web client application. I have also > in > >>> addition configured Apache HTTPD 2.4.29 on the same machine.When I > reach > >>> that website I am failing to get SSO working. The web server is not > >> passing > >>> off the delegation credentials to Apache Tomcat server. I have the web > >>> server load balance proxying it's request to multiple Apache Tomcat > >>> instances. I have tried applying mody_proxy_http environment variables, > >> but > >>> the site continues to fail SSO. Is there a guide or configuration that > >>> HTTPD and Apache Tomcat both use to involve Apache HTTPD passing off > >>> delegation credentials to Apache Tomcat? > >>> > >> > >> If you would like someone here to be able to help you, you would need to > >> be much more > >> precise than that. You write "I have done this" and "I have done > that", > >> but without > >> giving any clue as to /how/ you did this or that. > >> You are not even saying /where/ you have configured the Kerberos SSO. > >> Under the Apache > >> httpd front-end ? or under Tomcat ? > >> > >> To point you nevertheless in a possible direction, read this : > >> > >> > https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Apache_httpd > >> (and, in your mind, substitute "Windows authentication" by "Kerberos > >> authentication") > >> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
