good question.lol
l...@bsoft.com.cn From: Kim Ming Yap Date: 2015-05-19 06:23 To: Tomcat Users List Subject: RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve 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 >
