Date: Tue, 19 May 2015 09:10:57 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ming Yap,
(Please let me know if I'm using your given name properly... you
haven't identified yourself in the body of your messages, so I only
have your email address for identification purposes. I wouldn't want
to be calling you by the wrong name.)
On 5/18/15 6:23 PM, Kim Ming Yap wrote:
I think Tomcat should provide interfaces for different scenarios
.. that's my opinion.
Tomcat can't dictate the JAAS interfaces. It can only implement and/or
call them. You are right that Tomcat might be able to provide some
convenience items for you, but you'd have to be a bit more specific
about what you'd like.
So coming back to my web form-based authentication problem, is
there a solution to it?
Mark suggested a custom Authenticator. I'd start by looking at one of
the existing authenticators -- depending upon the authenticator you
are currently using (likely FormAuthenticator, based upon your initial
post).
Note that FormAuthenticator.authenticate is probably much more
complicated that you imagined.
- -chris
Date: Mon, 18 May 2015 18:01:31 -0400 From:
ch...@christopherschultz.net To: users@tomcat.apache.org Subject:
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
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 ob...@whitehouse.gov 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 perspective.
-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 v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVWzZhAAoJEBzwKT+lPKRYTFMQAIPiKQEbsLInQNq+UI94Odb/
CRuw40xsGuxkoNQHkb/rMCZm2hiQT9KJFb//H2tzLQjHMzjF3CmyWyTtghv+p3LN
Flo6x4yb6fCdc220Bh9SrW/kOkimEXjfcpRL0AygEHEOSabkRJBzUvJZwN2dSWhm
wyEukEW3fRw6+LMOZiL1jPgaqfuwR8CRRmBBDWHlnN6BuR+0I5m3pEA1oLENHcUn
evHbP6YQOwbxoVa7zlTDGEUZLp6a1q518b6HuEZY5iip1M0pqiMgDZReao3xkWCW
sLB6DYee3Xz/VE9e6/QX/5RVGmB6TkBulxZiygbuthuZsUEXdUzuf4wNbB2B+uuB
q3DPKeGHftqquDbirimrTnfEA/6xfkiz+pMx4Ts/w7ibXMEcDPKSrT945iOuV8/A
lJFtHofQicfJhNdxq58W1nRmQPawZh8PQi8MxF/YybMwZ5k3udy7x3mxmub0xGEj
KOJ6Ibs7KORwyHKb3t2x6MdkKYGbhfTQFz4NuG4i5nKOZa1vwMbnnHW+yNY16/SI
lVhLh9jdrW6IUxEKAI2BbOXohjVClqCNncqxAyLK4bwM/b2SK1c7JlEW2RrJ2jgm
dKcZ5xh+nj4FLi3IapiRJbzWQyPkmITbeg6b/om4VFpdJW/P514oBsoKhxzbOIA6
gqAvSQSVPu41Mtrkcom2
=rK6r
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
