You said .. "> Actually, the better analogy is that there is an application that can > tell you whether or not 1+1=2, and you're asking it to explain why the > numbers they entered don't total up to 2"
when a user account is disabled after exceeded limits retry .. i couldn't display "account disabled" but rather "email / password invalid (due to the issue below) the right analogy is .. 1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due to lack of the needed feature). Sure .. if if i'm the client .. i will ask 1+1 = 10? That's the issue. > Date: Tue, 19 May 2015 10:34:48 -0400 > From: dcker...@verizon.net > To: users@tomcat.apache.org > Subject: Re: Tomcat valve JAAS : form error page displayed first before > response reaches back to Tomcat valve > > On 5/19/2015 10:26 AM, Kim Ming Yap wrote: > > 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. > > But what you're asking it to do goes way beyond authentication. All > authentication does is tell you if a user should be allowed to access > certain resources. Nothing more. Asking it to tell you why they are > not allowed to access it is an additional function that can hurt your > security. > > > > > > 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. > > Actually, the better analogy is that there is an application that can > tell you whether or not 1+1=2, and you're asking it to explain why the > numbers they entered don't total up to 2. > > > > > > 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 > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
