Sorry .. you can call me Kim. Yes. I know Mark suggested a custom authenticator .. but how would it help me?
The basic thing which i need is simple. In the login module, i need access to session, request objects .. How can having a custom authenticator help me? What i need is a simple API in the login module to get these objects. Think of it this way. There's a callback for username and password. A simple solution is to have a callback for those session, request objects. Now i know that the standard API security doesn't have this. Maybe Tomcat can provide this API .. a callback to get this object. By the way, you mentioned about it's more complicated than that. Sure. But here's the point. The need here is basic and is the most fundamental thing used in any web application to do authentication and is used by all world wide application to do authentication. Sure, issue of security etc. But your are forgoing the fundamental on account of that. Think of it this way. You've build some really good math algorithm to solve some advanced issue while all i need is 1+1 = 2 and that is not achievable. I would get the fundamental rights first before moving on to more advanced needs like TLS certificate etc. That's why when i started looking at this issue, well lots of complaints on this. Just google it. Just my thoughts. > 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 >
