Hi.
Glad if I could be of even limited help.

It would be nice if you sent to the list a complete layout of your solution, to put into the Tomcat FAQ (e.g. like here : https://wiki.apache.org/tomcat/HowTo, in section 3 Configuration)
That may help someone else in the future.


On 20.09.2018 15:38, Thomas Delaney wrote:
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





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to