tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
Date Mon, 18 May 2015 22:01:31 GMT
Hash: SHA256

Ming Yap,

On 5/18/15 4:56 PM, Kim Ming Yap wrote:
> Now here's comes to crucial point and question when comes to JAAS.
> I know the benefit of JAAS - a pluggable authentication and 
> authorization module.
> Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where
> the loginmodule has no access to those most important objects -
> sessions, request etc?

... because JAAS does not require you to be running within a web
context. You can use JAAS in a think client. Or from a command-line
client. Or whatever. In those cases, what would you use for the
request or session?

> I did a bit of research .. hence other web container like JBoss, 
> Oracle WebLogic has to build an extended version of their 
> authentication module to capture those important objects ..
> I just don't comprehend this.This is mind boggling.

Pluggable authentication and authorization is kind of an unattainable
goal when you want it to work across any use case. You just happen to
be thinking of the web-based authentication use case, here, and it's
not matching up with your expectations.

What if you wanted to use some information about a TLS certificate for
authentication? Does the JAAS module now need to have access to the
X.509 certificate as well? What about a Smart Card? Where does that
fit into your web-based view of JAAS?

It's just more complicated than you think, unfortunately.

> I have spent almost 4 weeks on trying to solve this basic problem 
> when comes to form based authentication using JAAS.
> 1. Valid credential -> no issue2. Credential disabled due to gt 3 
> retry -> This message propagate to the error page3. Invalid user
> id -> This message propagate to error page4. Invalid password ->
> This message propagate to error page

You should do some reading about user-enumeration vulnerabilities and
similar things. You probably don't want to give this kind of
information to a user. Hint: the user might be an adversary, and any
information you give them them is something they can use to gain
access to your system.

For example: if I enter as my username and you
tell me "user does not exist", I can keep trying usernames until I get
one that does exist. Great, now I know the user exists and I can keep
trying passwords until I get in. If you tell me "credentials
disabled", then I will know when I've tripped some kind of maximum
login-attempt trigger that will (likely) disable the user for a while.
So, I'll adjust my attack strategy so that I only try each user 3
times because I know that after that, they will be disabled.

If you have a hard business requirement to tell the user why they
aren't being permitted to login, you might want to go back to whoever
wrote those requirements and ask them to review them from a security

- -chris
Version: GnuPG v2
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message