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