Re: Tomcat7: debugging realms - a howto?
On 14 Mar 2015, at 3:43 PM, Graham Leggett minf...@sharp.fm wrote: Changing the auth-type to CLIENT-CERT shows that the username has been replaced by the subject-DN of the cert, which is progress. Reverse engineering tomcat showed that the tomcatAuthentication parameter solved half the problem - when the webserver provided REMOTE_USER, this was used as the principal in the request, but as a side effect the role lookup was bypassed, and any web application using roles stopped working. The attached patches for tomcat v7.0.x, tomcat v8.0.x and tomcat 9.0.x introduce the tomcatAuthorization flag: https://bz.apache.org/bugzilla/show_bug.cgi?id=57708 The tomcatAuthorization flag, when true, takes the REMOTE_USER from the webserver, but ensures that all the role lookups occur as normal. This means you can drop in a webserver in front of a tomcat hosted web application, and automatically the authn of the webserver will replace the authn in the web application, leaving the authz intact and working. This solves my problem. Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7: debugging realms - a howto?
On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: You are using JRE's default java.util.logging.LogManager. You need to configure JRE to use the Tomcat JULI implementation of log manager with -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager The JRE class is usable, but its logging.properties format is a bit different. Adding the above to Eclipse’s launcher configuration brought sanity back to the logging. What this revealed was that no realm decisions were being made - we weren’t getting that far. Placing a watchpoint on the “status” variable in the response revealed the point at which we were getting the 403. In my case switching from basic auth to cert meant changing the tomcat protocol from HTTP to AJP, and this in turn caused a org.apache.catalina.valves.RemoteAddrValve configuration to kick in, which now no longer pointed at localhost (address of Apache proxy) but rather the browser IP, thanks to AJP: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127.0.0.1”/ Stepping through the org.apache.catalina.valves.RemoteAddrValve implementation in the debugger showed that when it returned the 403, it logged nothing in the log, and it returned no explanatory message in the response. Ideally this needs to be fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=57705 Now I get the basic authentication to hit as normal. Changing the auth-type to CLIENT-CERT shows that the username has been replaced by the subject-DN of the cert, which is progress. Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7: debugging realms - a howto?
Graham, On Fri, Mar 13, 2015 at 3:02 PM, Graham Leggett minf...@sharp.fm wrote: Hi all, I have a working realm installation using basic authentication, which I need to switch to client certificate authentication. Having done so it doesn’t work, I just get “forbidden”, with no indication of the error involved. Just to confirm, the 403 Forbidden page was rendered by Tomcat, not Apache HTTPD? I don't expect it is an Apache issue here - because you mentioned your application worked before - I assume with the same URL, and no updates to Apache HTTPD configuration. Next thing I would probably increase the verbosity of the Realm logging, by updating your conf/logging.properties, e.g. org.apache.catalina.realm.level = ALL org.apache.catalina.realm.useParentHandlers = true org.apache.catalina.authenticator.level = ALL org.apache.catalina.authenticator.useParentHandlers = true You might want to disable buffering as well, e.g. 1catalina.org.apache.juli.FileHandler.bufferSize = -1 Hope that helps! Cheers! Neven
Re: Tomcat7: debugging realms - a howto?
On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com wrote: Just to confirm, the 403 Forbidden page was rendered by Tomcat, not Apache HTTPD? Yes, it is branded tomcat and appears in the tomcat access log. I don't expect it is an Apache issue here - because you mentioned your application worked before - I assume with the same URL, and no updates to Apache HTTPD configuration. Next thing I would probably increase the verbosity of the Realm logging, by updating your conf/logging.properties, e.g. org.apache.catalina.realm.level = ALL org.apache.catalina.realm.useParentHandlers = true org.apache.catalina.authenticator.level = ALL org.apache.catalina.authenticator.useParentHandlers = true You might want to disable buffering as well, e.g. 1catalina.org.apache.juli.FileHandler.bufferSize = -1 None of these changes to logging.properties have any effect on my test system of tomcat v7.0.59 deployed to RHEL6. I get no changes to catalina.out at all, it stays completely silent. I tried to make the same changes to a tomcat v7.0.59 running within Eclipse, and in this case I get the following: Can't load log handler 2localhost.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.util.logging.LogManager$3.run(LogManager.java:418) at java.security.AccessController.doPrivileged(Native Method) at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:405) at java.util.logging.LogManager.addLogger(LogManager.java:609) at java.util.logging.LogManager.demandLogger(LogManager.java:355) at java.util.logging.Logger.getLogger(Logger.java:328) at org.apache.juli.logging.DirectJDKLog.init(DirectJDKLog.java:71) at org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:196) at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:170) at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:311) at org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:452) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1102) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:816) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Further on, the following is logged, which suggests that there is no roles defined at all: Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase invoke FINE: Security checking request GET / Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase invoke FINE: Security checking request GET / Mar 13, 2015 10:13:12 PM org.apache.catalina.realm.RealmBase findSecurityConstraints FINE: No applicable constraints defined Mar 13, 2015 10:13:12 PM org.apache.catalina.realm.RealmBase findSecurityConstraints FINE: No applicable constraints defined Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase invoke FINE: Not subject to any constraint Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase invoke FINE: Not subject to any constraint None of this is making any sense. Is there no simply way of switching on realm debugging as we used to with the “debug” attribute? Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7: debugging realms - a howto?
Graham,
On Fri, Mar 13, 2015 at 4:43 PM, Graham Leggett minf...@sharp.fm wrote:
On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com
wrote:
Just to confirm, the 403 Forbidden page was rendered by Tomcat, not
Apache
HTTPD?
Yes, it is branded tomcat and appears in the tomcat access log.
Great. We know it is Tomcat rendering this page.
Next thing I would probably increase the verbosity of the Realm logging,
by
updating your conf/logging.properties, e.g.
org.apache.catalina.realm.level = ALL
org.apache.catalina.realm.useParentHandlers = true
org.apache.catalina.authenticator.level = ALL
org.apache.catalina.authenticator.useParentHandlers = true
You might want to disable buffering as well, e.g.
1catalina.org.apache.juli.FileHandler.bufferSize = -1
None of these changes to logging.properties have any effect on my test
system of tomcat v7.0.59 deployed to RHEL6. I get no changes to
catalina.out at all, it stays completely silent.
Sorry, I think we forgot to include the ConsoleHandler and FileHandlers to
collect ALL logs, not just FINE level (out-of-box level), e.g.
1catalina.org.apache.juli.FileHandler.level = ALL
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
1catalina.org.apache.juli.FileHandler.bufferSize = -1
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
Also, try to switch over to the old system quickly (where things were
working properly), and try to input a wrong username, or a user that has
proper password, but not the appropriate role. Let's see if the
authorization error (403) shows up now in the logs.
I will test this on my Tomcat with DataSourceRealm. I've got it to log with
my out-of-box UserDatabaseRealm, e.g.
Mar 13, 2015 5:36:56 PM org.apache.catalina.authenticator.AuthenticatorBase
invoke
FINE: Security checking request GET /SimpleAppAuth/time
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.RealmBase
findSecurityConstraints
FINE: Checking constraint 'SecurityConstraint[SecurePages]' against GET
/time -- true
Mar 13, 2015 5:36:56 PM org.apache.catalina.authenticator.AuthenticatorBase
invoke
FINE: Calling hasUserDataPermission()
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.RealmBase
hasUserDataPermission
FINE: User data constraint has no restrictions
Mar 13, 2015 5:36:56 PM org.apache.catalina.authenticator.AuthenticatorBase
invoke
FINE: Calling authenticate()
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.CombinedRealm authenticate
FINE: Attempting to authenticate user john with realm
org.apache.catalina.realm.UserDatabaseRealm/1.0
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.CombinedRealm authenticate
FINE: Authenticated user john with realm
org.apache.catalina.realm.UserDatabaseRealm/1.0
Mar 13, 2015 5:36:56 PM org.apache.catalina.authenticator.AuthenticatorBase
register
FINE: Authenticated 'john' with type 'BASIC'
Mar 13, 2015 5:36:56 PM org.apache.catalina.authenticator.AuthenticatorBase
invoke
FINE: Calling accessControl()
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.RealmBase
hasResourcePermission
FINE: Checking roles GenericPrincipal[john(APP_USER,)]
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.RealmBase hasRole
FINE: Username john does NOT have role APP_ADMIN
Mar 13, 2015 5:36:56 PM org.apache.catalina.realm.RealmBase
hasResourcePermission
FINE: No role found: APP_ADMIN
Mar 13, 2015 5:36:56 PM org.apache.catalina.authenticator.AuthenticatorBase
invoke
FINE: Failed accessControl() test
Hopefully, once we get the logging working - it will give us ideas why you
got 403.
I tried to make the same changes to a tomcat v7.0.59 running within
Eclipse, and in this case I get the following:
Can't load log handler 2localhost.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at java.util.logging.LogManager$3.run(LogManager.java:418)
at java.security.AccessController.doPrivileged(Native Method)
at
java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:405)
at java.util.logging.LogManager.addLogger(LogManager.java:609)
at java.util.logging.LogManager.demandLogger(LogManager.java:355)
at java.util.logging.Logger.getLogger(Logger.java:328)
at
Re: Tomcat7: debugging realms - a howto?
2015-03-13 23:43 GMT+03:00 Graham Leggett minf...@sharp.fm: On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com wrote: Just to confirm, the 403 Forbidden page was rendered by Tomcat, not Apache HTTPD? Yes, it is branded tomcat and appears in the tomcat access log. I don't expect it is an Apache issue here - because you mentioned your application worked before - I assume with the same URL, and no updates to Apache HTTPD configuration. Next thing I would probably increase the verbosity of the Realm logging, by updating your conf/logging.properties, e.g. org.apache.catalina.realm.level = ALL org.apache.catalina.realm.useParentHandlers = true org.apache.catalina.authenticator.level = ALL org.apache.catalina.authenticator.useParentHandlers = true You might want to disable buffering as well, e.g. 1catalina.org.apache.juli.FileHandler.bufferSize = -1 None of these changes to logging.properties have any effect on my test system of tomcat v7.0.59 deployed to RHEL6. I get no changes to catalina.out at all, it stays completely silent. I tried to make the same changes to a tomcat v7.0.59 running within Eclipse, and in this case I get the following: Can't load log handler 2localhost.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.util.logging.LogManager$3.run(LogManager.java:418) You are using JRE's default java.util.logging.LogManager. You need to configure JRE to use the Tomcat JULI implementation of log manager with -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager The JRE class is usable, but its logging.properties format is a bit different. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7: debugging realms - a howto?
2015-03-13 22:02 GMT+03:00 Graham Leggett minf...@sharp.fm: Hi all, I have a working realm installation using basic authentication, which I need to switch to client certificate authentication. Having done so it doesn’t work, I just get “forbidden”, with no indication of the error involved. Back in the day there was a simple “debug” flag that turned on debugging. That seems to have been replaced with the significantly more complicated java.util.logging implementation, based on adding a logging.properties file. Adding this file, along with suggested entries to debug realms has had no effect, I can still see nothing in console.out. Can anyone point at a simple, clear and unambiguous set of instructions that indicate how to debug a realm configuration? I have tomcat up and running in a debugger, if the realm logging is broken is there a suggested point in the code I should be placing a breakpoint so I can step through this? A realm is a database used by an authenticator. The BASIC authentication is implemented by BasicAuthenticator. I would recommend to start debugging with that authenticator class. An authenticator is essentially a Valve. Its entry point is invoke() method. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
