date:20150313

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?

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: Switching basic auth to client-cert with realms - how?

Graham,

On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett minf...@sharp.fm wrote:

 Hi all,

 I have a basic authentication setup that works great as below.

 login-config
 auth-methodBASIC/auth-method
 realm-namePatricia/realm-name
 /login-config

 !-- Security roles referenced by this web application --
 security-role
 role-nameadministrator/role-name
 /security-role
 security-role
 role-nameunderwriter/role-name
 /security-role
 security-role
 role-nameaccountant/role-name
 /security-role
 security-role
 role-namebroker/role-name
 /security-role
 security-role
 role-namefeeds/role-name
 /security-role

 It is backed up with a realm like this:

   Realm className=“org.apache.catalina.realm.DataSourceRealm
  [snip]
  userTable=person userNameCol=mail
  userCredCol=user_password
  userRoleTable=company_person roleNameCol=serial /

 I need to switch basic authentication to client certificates, as provided
 by Apache httpd and proxied in with AJP. The username is provided by Apache
 httpd in REMOTE_USER.

 In theory, changing the auth-method to CLIENT-CERT should do the trick,
 but I just get forbidden.

 What doesn’t seem to fit is the realm definition - specifying userCredCol
 is marked as mandatory, but this is obviously not present with a client
 certificate. What do you specify in this field?

 Does anyone have a working example of authentication using client
 certificates and authorization using a realm backed with a DataSource?


Here's a nice article, detailing how to add CLIENT-CERT:
http://java.dzone.com/articles/enabling-client-cert-based

It is based on MemoryRealm, not DataSourceRealm, but the idea is similar.

Here's a summary:

1. You need to define user/pass/roles:

role rolename=secureconn/
user username=CN=client1, OU=Application Development, O=GoSmarter,
L=Bangalore, ST=KA, C=IN password=null  roles=secureconn/

2. You define in web.xml the login type:
login-config
auth-methodCLIENT-CERT/auth-method
realm-nameDemo App/realm-name
/login-config

You would get a 403 if an invalid certificate is sent based on the security
constraints you set earlier.

Ultimately, you need to turn on extra logging on that realm so you would
know why the 403s were generated.

Try doing some online searching for the type of errors you got. Here's what
pops up in my quick google search:
http://stackoverflow.com/questions/5086457/setting-up-client-cert-authentication-with-roles-on-tomcat-6-0

This person had an issue how CNs were handled, and as a result extra
inserted spaces between commas, e.g.
(1) no spaces: CN=testuser,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
(2) with spaces: CN=testuser, O=Internet Widgits Pty Ltd, ST=Some-State,
C=AU

The issue was how X509Principal.getName() call returned:
X500Principal.RFC2253
X500Principal.RFC1779

Let us know what you find by turning on extra logging.

Cheers!
Neven

Re: Switching basic auth to client-cert with realms - how?

Graham,

On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett minf...@sharp.fm wrote:

What doesn’t seem to fit is the realm definition - specifying userCredCol
is marked as mandatory, but this is obviously not present with a client
certificate. What do you specify in this field?

You define the password column, which could have NULL values now, since we
don't use passwords anymore.

Does anyone have a working example of authentication using client
certificates and authorization using a realm backed with a DataSource?

Try doing some online searching for the type of errors you got. Here's
what pops up in my quick google search:

http://stackoverflow.com/questions/5086457/setting-up-client-cert-authentication-with-roles-on-tomcat-6-0

Here's another interesting article that tackles the old version of Tomcat,
but the ideas are very similar. Here's a link:
http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

Summary:

User Names
The user name column should contain the certificate subject's distinguished
name, as a character string. Unfortunately, the method Tomcat uses to
obtain this string produces an implementation-dependent result, so it's
possible if you were to switch to a new security provider or even just
upgrade your Java runtime, you might need to map your user names to a new
form. You'll have to test your deployment to find out what format is used.

Specifically, getName() is called on the Principal returned by
X509Certificate.getSubjectDN() to obtain a String, which is used as the
user name. If you read the documentation, you'll find that this is no
longer the best approach.

Authentication
The simplest set up would be to load your trust anchors into Tomcat's trust
store, which is configured in the server.xml file. With this setup, any
client certificate chain that is root in one of your trusted CAs will be
considered authenticated, and rightly so—authentication means that an
identity is known, and is distinct from authorization, which determines
what that identity is allowed to do.

Authorization
Since anyone with a signed certificate will be authenticated, you need to
set up roles in order to protect private resources in your application.
This is done by setting up security constraints, associated with roles, in
your web.xml file. Then, in your database, populate the roles table to
grant trusted users with extra roles.

The relationship between the user table and the roles table works exactly
as it would with FORM-based authorization, and should be utilized to grant
appropriate permissions to users that you trust.

A Note on Passwords
The JDBCRealm will create a new Principal, which does carry a password, but
unless your application downcasts this Principal to the Tomcat-specific
implementation (GenericPrincipal), this property won't be visible to you,
and it doesn't really matter what you put in that column. I recommend NULL.

In other words, when using JDBCRealm with client-auth, the password field
is ignored. This GenericPrincipal has a method to access an underlying
principal, but unfortunately, the Principal from the certificate is not
passed along; the JDBCRealm will set it to null; the only useful method in
this scenario might be getName() (returning the subject DN is some possibly
non-standard form).

Table Structure and Content
Use exactly the same table structure you would for a FORM-based JDBCRealm
(or DatasourceRealm). The only difference will be in the content. The user
name will be a text representation of the subject distinguished name, and
the password will be NULL or some dummy value.

I don't know how much of it is still relevant in Tomcat7/Tomcat8.

By the way, what platform, what JVM and what version of Tomcat do you run?

Hope that helps!

Cheers!
Neven

Re: Switching basic auth to client-cert with realms - how?

On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com wrote:

 What doesn’t seem to fit is the realm definition - specifying userCredCol
 is marked as mandatory, but this is obviously not present with a client
 certificate. What do you specify in this field?
 
 
 You define the password column, which could have NULL values now, since we
 don't use passwords anymore.

I don’t follow, do you mean I shouldn’t define the password column?

 Here's another interesting article that tackles the old version of Tomcat,
 but the ideas are very similar. Here's a link:
 http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

I’ve already found all of these, and have trawled through them to no avail. It 
appears all the information is stale.

I am currently stuck on two specific areas:

- None of the debug logging seems to work any more in any kind of predictable 
fashion, as detailed in my other message.
- Turning on SQL statement logging in postgres shows that at no point is any 
SQL statement executed against the database.

If I had some kind of meaningful error that accompanied the 403 it would be a 
huge help.

Is anyone able to confirm where I might place a breakpoint to step through the 
tomcat code?

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 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

Switching basic auth to client-cert with realms - how?

Hi all,

I have a basic authentication setup that works great as below.

login-config
auth-methodBASIC/auth-method
realm-namePatricia/realm-name
/login-config

!-- Security roles referenced by this web application --
security-role
role-nameadministrator/role-name
/security-role
security-role
role-nameunderwriter/role-name
/security-role
security-role
role-nameaccountant/role-name
/security-role
security-role
role-namebroker/role-name
/security-role
security-role
role-namefeeds/role-name
/security-role

It is backed up with a realm like this:

  Realm className=“org.apache.catalina.realm.DataSourceRealm
 [snip]
 userTable=person userNameCol=mail
 userCredCol=user_password
 userRoleTable=company_person roleNameCol=serial /

I need to switch basic authentication to client certificates, as provided by 
Apache httpd and proxied in with AJP. The username is provided by Apache httpd 
in REMOTE_USER.

In theory, changing the auth-method to CLIENT-CERT should do the trick, but I 
just get forbidden.

What doesn’t seem to fit is the realm definition - specifying userCredCol is 
marked as mandatory, but this is obviously not present with a client 
certificate. What do you specify in this field?

Does anyone have a working example of authentication using client certificates 
and authorization using a realm backed with a DataSource?

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: Switching basic auth to client-cert with realms - how?

Graham,

On Fri, Mar 13, 2015 at 4:49 PM, Graham Leggett minf...@sharp.fm wrote:

On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com
wrote:

What doesn’t seem to fit is the realm definition - specifying
userCredCol
is marked as mandatory, but this is obviously not present with a client
certificate. What do you specify in this field?

You define the password column, which could have NULL values now, since
we
don't use passwords anymore.

I don’t follow, do you mean I shouldn’t define the password column?

According to my understanding - password field will be irrelevant. Since we
use certificates to authenticate, not username/password combo. Thus, keep
the field as is.

Here's another interesting article that tackles the old version of
Tomcat,
but the ideas are very similar. Here's a link:

http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

I’ve already found all of these, and have trawled through them to no
avail. It appears all the information is stale.

Yes, indeed - most of the info on these pages is very stale. Once we
resolve it, we should add a nice article about this, and add to Tomcat Wiki
:)))

I am currently stuck on two specific areas:

- None of the debug logging seems to work any more in any kind of
predictable fashion, as detailed in my other message.

From your other log files (your last email in the other thread) - it seems
your pages are not secured at all, e.g.
FINE: Not subject to any constraint

Do you have security-constraint defined in your web.xml?

- Turning on SQL statement logging in postgres shows that at no point is
any SQL statement executed against the database.

Well, we are not hitting the database yet, as secured page was not hit yet
- just unsecured / - judging from your provided log files.

That's why I would first make sure the logging does work properly with the
other login method (BASIC/FORM), just to make sure you can see stuff being
logged.

Then you can switch to new CLIENT-CERT, and troubleshoot the problem.

If I had some kind of meaningful error that accompanied the 403 it would
be a huge help.

Is anyone able to confirm where I might place a breakpoint to step through
the tomcat code?

I would try constructors on RealmBase, AuthenticatorBase base classes or
their derived subclasses, e.g. BasicAuthenticator, SSLAuthenticator,
DataSourceRealm.

Try also - the authenticate() method on the DataSourceRealm ... that's
probably going to be called at some point :))

Hope that helps!

Cheers!
Neven

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

Re: Windows authentication : outdated link

2015-03-13 15:04 GMT+03:00 André Warnier a...@ice-sa.com:
 Hi.

 Errata :

 In the page
 http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#References
 (and also in the corresponding Tomcat 7 page), the link to

 Geronimo configuration for Windows authentication

 leads to :

 https://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController

 which returns :

 The requested URL
 /confluence/display/GMOxDOC21/using-spengo-in-geronimo.html was not found on
 this server.

 (neither does it work if one replaces the spengo parts by spnego..)


Apparently they replaced '-' with '+' and have lost the .html suffix.

https://cwiki.apache.org/confluence/display/GMOxDOC21/Using+SPNEGO+in+Geronimo#UsingSPNEGOinGeronimo-SettinguptheDomainControllerMachine

Best regards,
Konstantin Kolinko

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

Re: Issues with SSL to resolve poodle vulnerability

2015-03-13 Thread Daniel Mikusa

On Fri, Mar 13, 2015 at 10:17 AM, MICHELLE RENEE LARSON mr...@psu.edu
wrote:

 We use a software called iDashboards it is tomcat running on windows I
 have installed an SSL and when you go to the site
 https://idashboards-dev.outreach.psu.edu/idashboards/ it shows that the
 SSL is installed and you connect via https however when you go to an ssl
 checker it says no ssl if installed any idea why it would not show.



 Using sslshopper.com ssl checker





 idashboards-dev.outreach.psu.edu resolves to 146.186.231.156


While the DNS does resolve for me, the site does not seem accessible.  This
may or may not be intentional.  Also, looking at a site like
http://www.isitdownrightnow.com/idashboards-dev.outreach.psu.edu.html
show's it's not accessible.  Given that sslshopper.com is a public site,
it's probably having the same access issues.

Dan








 No SSL certificates were found on idashboards-dev.outreach.psu.edu. Make
 sure that the name resolves to the correct server and that the SSL port
 (default is 443) is open on your server's firewall.












 I have 448 and 8443 open on both the local firewall and on network
 firewall.



 We are running tomcat 7.0.35 on Server 2008 r2



 Here is the edited server.xml



 Connector port=443

protocol=org.apache.coyote.http11.Http11NioProtocol

SSLEnabled=true

maxThreads=150

scheme=https

secure=true

clientAuth=false

sslProtocol=TLS

keystoreFile=C:\SSL\keystore.jks

keystorePass=$@GCceate345

keyAlias=tomcat /







 Michelle larson

 Systems Administrator II

 Outreach Technology Services

 The Pennsylvania State University

 The 329 Bldg, Suite 311, Innovation Park

 University Park, PA 16802

 Phone: 814-863-6612

Re: Issues with SSL to resolve poodle vulnerability

2015-03-13 Thread Kaydell Leavitt

Unsubscribe please.

-- Kaydell
kayd...@yahoo.com



On Mar 13, 2015, at 8:17 AM, MICHELLE RENEE LARSON mr...@psu.edu wrote:

 We use a software called iDashboards it is tomcat running on windows I
 have installed an SSL and when you go to the site
 https://idashboards-dev.outreach.psu.edu/idashboards/ it shows that the
 SSL is installed and you connect via https however when you go to an ssl
 checker it says no ssl if installed any idea why it would not show.
 
 
 
 Using sslshopper.com ssl checker
 
 
 
   
 
 idashboards-dev.outreach.psu.edu resolves to 146.186.231.156
 
   
 
 
 
 
 No SSL certificates were found on idashboards-dev.outreach.psu.edu. Make
 sure that the name resolves to the correct server and that the SSL port
 (default is 443) is open on your server's firewall.
 
 
 
 
 
 
 
 
 
 
 
 
 I have 448 and 8443 open on both the local firewall and on network
 firewall.
 
 
 
 We are running tomcat 7.0.35 on Server 2008 r2
 
 
 
 Here is the edited server.xml
 
 
 
Connector port=443
 
   protocol=org.apache.coyote.http11.Http11NioProtocol
 
   SSLEnabled=true
 
   maxThreads=150
 
   scheme=https
 
   secure=true
 
   clientAuth=false
 
   sslProtocol=TLS
 
   keystoreFile=C:\SSL\keystore.jks
 
   keystorePass=$@GCceate345
 
   keyAlias=tomcat /
 
 
 
 
 
 
 
 Michelle larson
 
 Systems Administrator II
 
 Outreach Technology Services
 
 The Pennsylvania State University
 
 The 329 Bldg, Suite 311, Innovation Park
 
 University Park, PA 16802
 
 Phone: 814-863-6612
 


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

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-13 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rop,

On 3/12/15 7:10 PM, rop wrote:
 Hi Chris, Yes, we are applying salt before hashing (to prevent
 googling up many passwords from the hashes).

Depending upon how you are storing the salt, you may be able to use
Tomcat out of the box, now, because Tomcat can now do salted passwords
(it was way overdue).

 Override probably seemed like easiest way at the time, but maybe a
 better way now. Will check it out, thanks.

You will be better-off moving away from Realm and towards
CredentialHandler instead. Consider beginning to evaluate that for the
future.

- -chris

 On Thu, Mar 12, 2015 at 8:53 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Rop,
 
 On 3/12/15 3:33 PM, rop wrote:
 Finally, found the issue.
 
 Please bottom-post if you can. Also, please sign your posts.
 
 On Thu, Mar 12, 2015 at 6:18 PM, Mark Thomas
 ma...@apache.org wrote:
 
 On 12/03/2015 15:51, rop wrote:
 Ah, I got it now. Thanks, David.
 
 Yes, the a-b-c-d points are OK then.
 
 As a trouble-shoot action, I actually did an
 install-and-test binary search among the intermediate
 tomcat-versions to pinpoint exactly which version breaks
 our app.
 
 Turns out, up to 7.0.47 it still works OK. (7.0.48 and
 7.0.49 do not exist in the tomcat archive) And from
 7.0.50 it breaks.
 
 So apparently, between 47 and 50 some change occurred
 that breaks our login
 
 Nothing jumps out at me in the change log. I'd add that
 FORM auth is tested as part of every release so it isn't a
 general problem.
 
 In your shoes, I'd be firing up Eclipse and remote
 debugging my way through the authentication process.
 Alternatively, try creating the smallest/simplest possible
 WAR that exhibits the problem.
 
 The crucial change was in the method 
 RealmBase.compareCredentials(), which is new in 7.0.50 (the 
 comparison was much simpler before that).
 
 It is much more extensible, now.
 
 Dunno if we do something unusual here, but we just extend 
 DataSourceRealm, like MyDataSourceRealm, and implement the 
 message-digest for password-hashing in there, by simply
 overriding the digest() method.
 
 Do you need to extend the whole realm, or did you just want to 
 override Tomcat's default password-hashing algorithm?
 
 If you just want to tweak the hashing algorithm, you can write a 
 simpler class and not subclass DataSourceRealm. What does your
 Realm do besides change the password-comparison algorithm?
 
 Before 7.0.50, this worked fine *without* explicitly setting
 the DataSourceRealm.setDigest() property. It's always been
 null, and still worked.
 
 This was because it defaulted to MD5 and Tomcat always used 
 simplistic credential-hashing. It's much more sophisticated, now,
 and also supports things like Bcrypt, Scrypt, PBKDF2, etc.
 
 But the new method RealmBase.compareCredentials() assumes: if
 you use messageDigest, this property MUST be set. ( 
 compareCredentials() calls hasMessageDigest() which did not
 happen in earlier versions. )
 
 So the solution was to simply add the property digest in
 Realm digest=... ... which we didnt have there before.
 Then it works.
 
 Great. But I think you can do better. If your Realm merely changes
 the way hashing is done, please check-out the new features. You may
 be able to a) eliminate your class altogether due to new features
 or b) replace your Realm with a CredentialHandler that only does
 the mutation and comparison of credentials.
 
 We did this so you can use the same credential-mutations on *any* 
 realm, without having to subclass every Realm to do it.
 
 Hope that helps, -chris
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVAvnDAAoJEBzwKT+lPKRYswIQAK+OITerGZSKo0NWWtpDGZZk
yFbT2fwf4HfqveG0pP24pcF+1EJAkKJlPt+D/eonRw4REdVBjWlj5KOBVNSJSEcw
JS+2tcOYNdJFx/EYL1EvTOCB4mKuzwpyfegikfP6pj/hy1rBXGOzVVNpHPIoUQ5Q
ugkWqBckBZa/jVDwsvWbZUJPTuwYFs4HqdEfH4Y9NRvzBNz3a/cIjnRB75jAl+AY
0Wdcfe1YifFssVQv/jX8b+kUhVcrYQzS1EKzyJzuPcPYwF8X7sCLDB8QMkrB6Gkg
FMHZA48ytQSrGJyq+rZ62C97Y/nXsQ4EKsK4+cLwcinjfEJ5MhSvZGY7I8Vm+cQk
Xpika0vRNV8NtX+vqpdTS7lg/QeqZkUFn2KrDtpNyyS2e9lsbJ3laCcmDgg345VS
DY7icmTsuNbc9gcWMJzcf5AuSmf/U2GhhTgIza9mO9SkT/uckxOYX8q6bu1WT/8L
wSJeGPRI/VqIEik83X3dFWP6BcCguidjOB4J1uAowl1T1fKhrmVlsZ3LP9m9MWbO
0E4P7bRKIX3JlZvyqI2U2UFheFefj0vK/PCIUAttNDzuXENPvxigEiVrvYf5Qx37
JfVrW5cxHMGyUQ3YIVlZmRiwWT4hnZzbTLHxvs6/1mtu7Zr8267RcissgoEv5E7X
3X/MceB38qv4a3npJchq
=HqR1
-END PGP SIGNATURE-

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

Windows authentication : outdated link

2015-03-13 Thread André Warnier


Hi.

Errata :

In the page 
http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#References
(and also in the corresponding Tomcat 7 page), the link to

Geronimo configuration for Windows authentication

leads to :

https://cwiki.apache.org/GMOxDOC21/using-spengo-in-geronimo.html#UsingSpengoingeronimo-SettinguptheActiveDirectoryDomainController

which returns :

The requested URL /confluence/display/GMOxDOC21/using-spengo-in-geronimo.html was not 
found on this server.


(neither does it work if one replaces the spengo parts by spnego..)


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

Re: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem

2015-03-13 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/12/15 1:13 PM, Mark Thomas wrote:
 On 12/03/2015 15:20, Sascha Skorupa wrote:
 Hi,
 
 here:
 
 http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication


 
the same problem is described and the recommended solution is to use
sticky load balancing. But, the problem in a tomcat cluster is that the
session ID is generated after a successful authentication. The first
http response (401 with Authentication Header) does not contain a
session ID.
 
 How should sticky load balancing be configured or how to enforce
 session id generation before authentication?
 
 Most load-balancers have various options for doing this that don't 
 depend on the back-end server at all.

Perhaps an option in Tomcat that will force the creation of a session
when a DIGEST authentication is requested might be useful. This would
tie e.g. mod_jk to the proper back-end server.

I'm not sure how this could be done using mod_jk without such a
feature, or changes to mod_jk itself to annotate the request with the
chosen worker, which could then be converted into a cookie in order to
keep the node-hint associated with the client.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVAwIvAAoJEBzwKT+lPKRYOc4P/2+nCQm+qwhJpz5hxEFaxebx
Y34D5ZF9D4OEdGeaRKNj+mYfDPHDpkbI2Ks3bewf1esnIlA96F4oXPdkXMc2Gn/F
1ETNN78g5ulquya/AYmNjVq1fAtjoaiiisKpv5iM0DJIVA0EdH3T8yUoA9t4MwPc
ndnt89eFfCeFi3FcJCP6EE1TFib+qWsBsAAwSP1J6JttzCDHviDjLt4aTABwBhXf
AAPzD2kLZm69FjphNOLTqaFr0Ec8+uSCGjK+UuC8AgaXYScnxBg92Y80lgqPV77m
7A6TOIVx1O8e1/6Wj1JCk4YrTrjB+90nShkATgnXBy4/DO/jEtFP7QyRovCYbuwf
9kUdl/6IovpR4j4OyYQ8EUPQqXeT3fpKZDk4XiW3iqdRX+zSyBvi95Igd+H9QfEH
gK1cMmeXQEdEY0XlgXU82iVNyzbl+JWma8QswiSnXEdYdxPUTKuaZkpx2W/757ID
GFlYa87tbHQbfbSnBAx5SqaoIVKqZaob7fnVkD32b0uiaCqw7nxhuB8q/QeiY9e8
8lUoTrccj5Uo+5liBp5/0ztSjSkdIZmUQdLnGhaGDBA9t1zNeyOfbNSXQjHKeEJf
l/tl7GNgQ+56pGrlwmuJLPQRTyjwcx+6B9SmpUhJly4YaxMS13Tk77azwVnjCEV4
RQu1uvmH9wOhNCocyyAe
=TebI
-END PGP SIGNATURE-

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

Issues with SSL to resolve poodle vulnerability

2015-03-13 Thread MICHELLE RENEE LARSON

We use a software called iDashboards it is tomcat running on windows I
have installed an SSL and when you go to the site
https://idashboards-dev.outreach.psu.edu/idashboards/ it shows that the
SSL is installed and you connect via https however when you go to an ssl
checker it says no ssl if installed any idea why it would not show.

 

Using sslshopper.com ssl checker

 



idashboards-dev.outreach.psu.edu resolves to 146.186.231.156



 


No SSL certificates were found on idashboards-dev.outreach.psu.edu. Make
sure that the name resolves to the correct server and that the SSL port
(default is 443) is open on your server's firewall.


 

 


 


 

I have 448 and 8443 open on both the local firewall and on network
firewall.

 

We are running tomcat 7.0.35 on Server 2008 r2

 

Here is the edited server.xml

 

Connector port=443

   protocol=org.apache.coyote.http11.Http11NioProtocol

   SSLEnabled=true

   maxThreads=150

   scheme=https

   secure=true

   clientAuth=false

   sslProtocol=TLS

   keystoreFile=C:\SSL\keystore.jks

   keystorePass=$@GCceate345

   keyAlias=tomcat /

 

 

 

Michelle larson

Systems Administrator II

Outreach Technology Services

The Pennsylvania State University

The 329 Bldg, Suite 311, Innovation Park

University Park, PA 16802

Phone: 814-863-6612

Re: Issues with SSL to resolve poodle vulnerability

2015-03-13 Thread André Warnier


Kaydell Leavitt wrote:

Unsubscribe please.


1) don't top post.
2) scroll down to the very bottom and read the fine instructions repeated in every message 
on this list.


P.S.
Duh !



-- Kaydell
kayd...@yahoo.com



On Mar 13, 2015, at 8:17 AM, MICHELLE RENEE LARSON mr...@psu.edu wrote:


We use a software called iDashboards it is tomcat running on windows I
have installed an SSL and when you go to the site
https://idashboards-dev.outreach.psu.edu/idashboards/ it shows that the
SSL is installed and you connect via https however when you go to an ssl
checker it says no ssl if installed any idea why it would not show.



Using sslshopper.com ssl checker





idashboards-dev.outreach.psu.edu resolves to 146.186.231.156






No SSL certificates were found on idashboards-dev.outreach.psu.edu. Make
sure that the name resolves to the correct server and that the SSL port
(default is 443) is open on your server's firewall.












I have 448 and 8443 open on both the local firewall and on network
firewall.



We are running tomcat 7.0.35 on Server 2008 r2



Here is the edited server.xml



   Connector port=443

  protocol=org.apache.coyote.http11.Http11NioProtocol

  SSLEnabled=true

  maxThreads=150

  scheme=https

  secure=true

  clientAuth=false

  sslProtocol=TLS

  keystoreFile=C:\SSL\keystore.jks

  keystorePass=$@GCceate345

  keyAlias=tomcat /







Michelle larson

Systems Administrator II

Outreach Technology Services

The Pennsylvania State University

The 329 Bldg, Suite 311, Innovation Park

University Park, PA 16802

Phone: 814-863-6612




-
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

Re: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem

2015-03-13 Thread Rainer Jung


Am 13.03.2015 um 16:28 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/12/15 1:13 PM, Mark Thomas wrote:

On 12/03/2015 15:20, Sascha Skorupa wrote:

Hi,

here:

http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication




the same problem is described and the recommended solution is to use
sticky load balancing. But, the problem in a tomcat cluster is that the
session ID is generated after a successful authentication. The first
http response (401 with Authentication Header) does not contain a
session ID.


How should sticky load balancing be configured or how to enforce
session id generation before authentication?


Most load-balancers have various options for doing this that don't
depend on the back-end server at all.


Perhaps an option in Tomcat that will force the creation of a session
when a DIGEST authentication is requested might be useful. This would
tie e.g. mod_jk to the proper back-end server.

I'm not sure how this could be done using mod_jk without such a
feature, or changes to mod_jk itself to annotate the request with the
chosen worker, which could then be converted into a cookie in order to
keep the node-hint associated with the client.


Yes, mod_jk can help since version 1.2.38: Look for set_session_cookie 
on http://tomcat.apache.org/connectors-doc/reference/workers.html. Using 
that attribute you can let mod_jk set the cookie, if it doesn't find one 
already set by Tomcat. You need to also set session_cookie=JSESSIONID 
and session_cookie_path=/myapp where you adjust myapp to your context 
path.


Regards,

Rainer

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

Re: Windows authentication : outdated link