I think Tomcat should provide interfaces for different scenarios .. that's my 
opinion.
So coming back to my web form-based authentication problem, is there a solution 
to it?

I still want to solve my problem 😏
Please advice.Thanks.

> 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
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U
> Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt
> VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9
> K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R
> xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1
> ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ
> CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl
> tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1
> eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9
> ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh
> BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb
> kgPkqUPohzH02HWcg6E2
> =q5gu
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
                                          

Reply via email to