You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kim Ming Yap <ya...@hotmail.com> on 2015/05/18 00:44:47 UTC
Tomcat valve JAAS : form error page displayed first before response
reaches back to Tomcat valve
Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
BASIC UNDERSTANDING:
The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
SOLUTION:
Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
(refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
Due to that the ready custom error message cannot be used
SAMPLE CODES:
1. web.xml
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
2. Custom valve and defined in META-INF/context.xml
public class SecurityValve extends ValveBase {
public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
}
1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
I would really appreciate any help.Thanks.
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
ok. i see the light ..
Thanks a zillion! 😊
> Date: Tue, 19 May 2015 15:56:47 +0100
> From: markt@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>
> On 19/05/2015 15:51, David kerber wrote:
> > On 5/19/2015 10:46 AM, Kim Ming Yap wrote:
> >>
> >> 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.
> >
> > The point we're making is that if a user's authentication is not valid,
> > you should NOT be telling them why, just tell them it's invalid and
> > maybe tell them to contact the administrator.
> >
> > Giving them any more information is just setting yourself up to be a
> > victim of much quicker brute-force attacks, because you're giving them
> > lots of help.
>
> +1.
>
> And the chances of any such features making it into Tomcat are slim to
> none. I for one would veto any such proposal (for the exact reasons
> David outlines above).
>
> It is possible that, if the GSoC project to implement JASPIC succeeds
> (and that isn't looking very likely right now), a side-effect may be
> that JASPIC makes it easier to implement custom authenticators but even
> then if you want to go down the route of detailed explanations for
> authentication failures you will be on your own.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before response
reaches back to Tomcat valve
Posted by Mark Thomas <ma...@apache.org>.
On 19/05/2015 15:51, David kerber wrote:
> On 5/19/2015 10:46 AM, Kim Ming Yap wrote:
>>
>> 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.
>
> The point we're making is that if a user's authentication is not valid,
> you should NOT be telling them why, just tell them it's invalid and
> maybe tell them to contact the administrator.
>
> Giving them any more information is just setting yourself up to be a
> victim of much quicker brute-force attacks, because you're giving them
> lots of help.
+1.
And the chances of any such features making it into Tomcat are slim to
none. I for one would veto any such proposal (for the exact reasons
David outlines above).
It is possible that, if the GSoC project to implement JASPIC succeeds
(and that isn't looking very likely right now), a side-effect may be
that JASPIC makes it easier to implement custom authenticators but even
then if you want to go down the route of detailed explanations for
authentication failures you will be on your own.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by David kerber <dc...@verizon.net>.
On 5/19/2015 10:46 AM, Kim Ming Yap wrote:
>
> 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.
The point we're making is that if a user's authentication is not valid,
you should NOT be telling them why, just tell them it's invalid and
maybe tell them to contact the administrator.
Giving them any more information is just setting yourself up to be a
victim of much quicker brute-force attacks, because you're giving them
lots of help.
>
>> Date: Tue, 19 May 2015 10:34:48 -0400
>> From: dckerber@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: chris@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:
>>>>>> chris@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 obama@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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
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: dckerber@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: chris@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:
> >>>> chris@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 obama@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-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by David kerber <dc...@verizon.net>.
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: chris@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:
>>>> chris@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 obama@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
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: chris@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:
> >> chris@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 obama@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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:
>> chris@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 obama@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by "lwyd@bsoft.com.cn" <lw...@bsoft.com.cn>.
good question.lol
lwyd@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: chris@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 obama@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
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: chris@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 obama@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 obama@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
ok. cool :) i understand better.
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?
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 ..
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
There's no way to propagate the above error messages to the error page from JAAS login module since this module has no access to those important aforementioned objects.
Hence i turn to valve (storing ThreadLocal). But as you can see, the error page gets displayed first even before i can store them in the session object.
Without this feature, the only error message i can display is for example:
"Incorrect email or password."
But this is incorrect if the account is disabled.
So i'm just flabbergasted that there's a JAAS module but without access to those basic objects used in any web development.
This is beyond mind boggling ..
Any insights?
> Date: Mon, 18 May 2015 16:08:41 -0400
> From: chris@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 11:43 AM, Kim Ming Yap wrote:
> > so who control the data flow?
>
> The data is really just a data stream. Anyone dumping data into that
> stream "controls the flow". Any component with access to the
> OutputStream to the client can inject something into it.
>
> The method call flow doesn't place any restrictions on what each
> component is allowed to put into that OutputStream.
>
> > Does the data flow has stages just like control flow?
>
> It's the Wild West: any component can do anything it wants.
>
> > Or is it just the http web server? As long as there are output
> > stream going out .. the http web server will server those output
> > stream to the client's browser?
>
> Exactly.
>
> > Basically no control stages when comes to data flow?
>
> Correct. There are basically two stages:
>
> 1. Before the response has been "committed"
> 2. After the response has been "committed"
>
> The "committment" of the response occurs when either of the following
> things happen:
>
> a. The response buffer fills up (container flushes buffer)
> b. A component explicitly flushes the response buffer
>
> Before the response has been committed, you can add/modify/remove
> response headers, change the response status code (e.g. 200 OK),
> request the creation of an HttpSession, and a few other things. After
> the response has been committed, you can do none of those things: only
> sending bytes to the response stream will work after that.
>
> But again, the only things that triggers the "commit" of the response
> if the response buffer filling up (or an explicit flush() call). Any
> component can cause that event to occur, and no other components are
> notified that it's about to happen.
>
> You can check to see if the response has been committed, but you can't
> do anything effective to stop it.
>
> - -chris
>
> >> Date: Mon, 18 May 2015 14:54:24 +0100 From: markt@apache.org To:
> >> users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form
> >> error page displayed first before response reaches back to Tomcat
> >> valve
> >>
> >> On 18/05/2015 13:57, Kim Ming Yap wrote:
> >>> Wow .. that really confuses me.
> >>>
> >>> I've studied the Java EE component and the basic understanding
> >>> of flow is as follows (if i do not flush the data)
> >>>
> >>> client request --> web container (encapsulate request/response)
> >>> --> filter (contain request/response object) --> Servlet (JSP)
> >>> --> filter (request / response object here can be modified here
> >>> for eventual display on browser) --> client browser
> >>>
> >>> On the way back the client browser, if i do a break point just
> >>> immediately after the dofilter() method and stop there, the JSP
> >>> page is not displayed.
> >>>
> >>> So if i get your right: 1. If the above is done without
> >>> flushing the data .. then yes. That JSP page is not displayed
> >>> since i stop at the breakpoint.
> >>
> >> Correct. The entire response is contained in the output buffer at
> >> that point.
> >>
> >>> 2. However if i do a flush before the break point, data will be
> >>> send to the client eventhough my code stops at the break
> >>> point?
> >>
> >> Correct. On the first write to the client, the HTTP Response
> >> headers will be written. This is the point at which the response
> >> is considered to be committed. The first write may also include
> >> some/all of the response body.
> >>
> >> Flushing can be explicit (the application calls it) or implicit
> >> (the container calls flush because - for example - there is no
> >> more space in the output buffer).
> >>
> >>> I thought the data flow is part of the control flow ..
> >>>
> >>> Gee .. i got this wrong all the while Think i'm seeing the
> >>> light ..
> >>
> >> Happy to help.
> >>
> >> Mark
> >>
> >>
> >>>
> >>>
> >>>> Date: Mon, 18 May 2015 13:43:14 +0100 From: markt@apache.org
> >>>> To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS :
> >>>> form error page displayed first before response reaches back
> >>>> to Tomcat valve
> >>>>
> >>>> On 18/05/2015 13:31, Kim Ming Yap wrote:
> >>>>>
> >>>>> Thanks Mark for your suggestion. I'm still confused over
> >>>>> the last part where you mentioned that 'i am confusing
> >>>>> myself between control and data'. The response object
> >>>>> contains output stream (data) to be displayed. Always the
> >>>>> case.
> >>>>
> >>>> No.
> >>>>
> >>>> The response contains a reference to the output stream. The
> >>>> output stream can be flushed to the client *at any point*.
> >>>> There is no guarantee that it will "contain the [data] to be
> >>>> displayed".
> >>>>
> >>>> The (incorrect) sequences you list below describe the control
> >>>> flow. The data flow (when the application reads the request
> >>>> body, when the application writes the request body and when
> >>>> the request body is written to the client) is completely
> >>>> separate.
> >>>>
> >>>>> If i enter valid credential .. you'll noticed the flow
> >>>>> exactly as indicated on my email (I've traced is using
> >>>>> system.out.println)
> >>>>>
> >>>>> request --> valve --> JAAS --> filter --> JSP --> response
> >>>>> --> filter --> JAAS --> valve --> browser
> >>>>
> >>>> Again, no. JAAS does not call the filter. Your valve calls
> >>>> the Authenticator which calls JAAS and then (via some
> >>>> additional objects) the Authenticator calls the filter.
> >>>>
> >>>> Neither the request nor the response are part of the
> >>>> processing chain. They are objects that are passed up and
> >>>> down the chain.
> >>>>
> >>>>
> >>>>> If invalid credential ..
> >>>>>
> >>>>> request --> valve --> JAAS --> response --> valve (break
> >>>>> point and stop here) .. yet JSP error page displayed.
> >>>>>
> >>>>> So this is really confusing.
> >>>>
> >>>> Take a look at the updated diagrams here:
> >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
> >>>>
> >>>>> The response always contains data to be displayed on the
> >>>>> client browser.
> >>>>
> >>>> No it does not. See comment above re control flow vs data
> >>>> flow.
> >>>>
> >>>>> How did the JSP error page displayed when on its way back
> >>>>> to the client browser .. i did a break point stop at the
> >>>>> valve.
> >>>>
> >>>> See point above re control flow vs data flow.
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>>>
> >>>>> Hm ..
> >>>>>
> >>>>>
> >>>>>> Date: Mon, 18 May 2015 11:14:19 +0100 From:
> >>>>>> markt@apache.org To: users@tomcat.apache.org Subject: Re:
> >>>>>> Tomcat valve JAAS : form error page displayed first
> >>>>>> before response reaches back to Tomcat valve
> >>>>>>
> >>>>>> On 17/05/2015 23:44, Kim Ming Yap wrote:
> >>>>>>> Hi,I'm building a website using form based
> >>>>>>> authentication integrating with JAAS for user based
> >>>>>>> authentication. I don't have issue when a successful
> >>>>>>> credential is authenticated. Rather I'm having
> >>>>>>> difficulty understanding the flow of JAAS back to the
> >>>>>>> client should the form based authentication failed.
> >>>>>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat
> >>>>>>> JAAS Realm OBJECTIVE:Custom error captured in JAAS
> >>>>>>> login module to propagate to error page
> >>>>>>
> >>>>>> You are unlikely to get much help from Tomcat with this
> >>>>>> since propagating back custom errors is considered poor
> >>>>>> security practise (an attacker should not be able to tell
> >>>>>> why authentication failed).
> >>>>>>
> >>>>>>> BASIC UNDERSTANDING: The Tomcat JAAS layer is not
> >>>>>>> integrated with the web container layer. Hence the
> >>>>>>> former does not have access to request, session etc.
> >>>>>>
> >>>>>> JAAS is integrated as a Realm - i.e. something that
> >>>>>> validates credentials provided by an Authenticator. The
> >>>>>> Authenticator has full access to the request and the
> >>>>>> response. You may want to consider a custom
> >>>>>> Authenticator.
> >>>>>>
> >>>>>>> SOLUTION: Using ThreadLocal which capture the custom
> >>>>>>> error message in JAAS layer to be used when the flow
> >>>>>>> reaches back to the custom valve on the way back to the
> >>>>>>> browser.
> >>>>>>
> >>>>>> You need to be careful you don't trigger memory leaks
> >>>>>> when using ThreadLocals.
> >>>>>>
> >>>>>>> PROBELM:Understanding of basic request/response flow
> >>>>>>> involving Tomcat and JAAS a. request --> valve --> JAAS
> >>>>>>> --> Filter --> Servlet/JSP b. response <-- valve
> >>>>>>> (**) <-- JAAS <-- Filter <-- Servlet/JSP
> >>>>>>
> >>>>>> I suspect that order is wrong.
> >>>>>>
> >>>>>> JAAS is called by the Authenticator (which is a valve).
> >>>>>> The Authenticator then calls the Filter (via a few other
> >>>>>> layers).
> >>>>>>
> >>>>>> You might want to check the ordering of your valve and
> >>>>>> the Authenticator.
> >>>>>>
> >>>>>>> (refer to above clause b)ThreadLocal in the JAAS layer
> >>>>>>> managed to capture the custom error message and it i
> >>>>>>> managed to print it after the getNext() method of the
> >>>>>>> custom valve. Thought of adding this custom error as an
> >>>>>>> attribute in the session object. However I noticed that
> >>>>>>> the error page is already displayed before i could add
> >>>>>>> this cusom error (immediately after the getNext
> >>>>>>> method).
> >>>>>>
> >>>>>> The error page will be handled by the webapp or the
> >>>>>> ErrorReportingValve - both of whichh may get called
> >>>>>> before your Valve depending on how the Valve is
> >>>>>> configured.
> >>>>>>
> >>>>>>> Due to that the ready custom error message cannot be
> >>>>>>> used SAMPLE CODES: 1. web.xml <login-config>
> >>>>>>> <auth-method>FORM</auth-method> <form-login-config>
> >>>>>>> <form-login-page>/login.jsp</form-login-page>
> >>>>>>> <form-error-page>/login-redirect-error.jsp?error=true</form-erro
> r-page>
> >>>>>>> </form-login-config> </login-config> 2. Custom valve
> >>>>>>> and defined in META-INF/context.xml public class
> >>>>>>> SecurityValve extends ValveBase { public void
> >>>>>>> invoke(Request request, Response response) throws
> >>>>>>> IOException, ServletException {
> >>>>>>> getNext().invoke(request, response);
> >>>>>>> system.out.println("after getNext()"); --> break point
> >>>>>>> (BP) } } 1. Did a break point on SecurityValve
> >>>>>>> (indicated at BP) 2. On forms, i purposely enter
> >>>>>>> wrong credential and submit 3. Break point
> >>>>>>> stops at BP 4. login-redirect-error.jsp displayed
> >>>>>>> already 5. Since it stop at break point BP in
> >>>>>>> SecurityValve, the response back to client flow has not
> >>>>>>> reached the browser. Yet the login-redirect-error.jsp
> >>>>>>> is already displayed QUESTIONS: How can the
> >>>>>>> login-redirect-error.jsp be displayed on the browser
> >>>>>>> when the response flowing back to client stop at break
> >>>>>>> point BP? The flow back to the client is not fully done
> >>>>>>> yet.
> >>>>>>
> >>>>>> You are confusing control and data. The data goes back to
> >>>>>> the client as soon as the output is flushed (which can
> >>>>>> happen in the Servlet/JSP).
> >>>>>>
> >>>>>>> I would really appreciate any help.Thanks.
> >>>>>>
> >>>>>> Set a break point in a JSP / Servlet and look at the
> >>>>>> stack trace to see which Valves the request/response flow
> >>>>>> through in which order.
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> - ----
> >>>>>>
> >>>>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>>>> For additional commands, e-mail:
> >>>>>> users-help@tomcat.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> - --
> >>>>
> >>>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail:
> >>>> users-help@tomcat.apache.org
> >>>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVWkbJAAoJEBzwKT+lPKRYdQMQAJIgdQNJXAKoIgp1xFnZBtc6
> ng2KtqSxQLltn2aos5R2hqaTN/mcDsWcQ7f+umFBrKYAtu13bP6qvlkkI2ruNQE8
> 6Gi1xa7ThUnYZ69Ih4D+5cl3uPDSM5nIV5jR+lUTyk0cPsioI92A8h9llXSQV/Ym
> qMknTJ1m35BIi7UI2Fqmf4yRXURCECskINe1tWaYiId66+26hYXIB+N2nBy7k0cv
> +/WAae6dYRRmq1sAvi5q6VY1+qJigtCyin6HPA6TccnRkfbSqzxRHCoKJg8QMYMZ
> EgKOlHew+dcpuE4ZiN+ced6vxEIv96DurwOS00z7tQyHNfrZZGkXGUQTEi/Q5F+J
> CJVXKj/H05tJ3+a017lfT51Nr0xVjJRAxuuFxjbfDa2P53Xk0+FO/Hw4e65cB+uc
> FcUx+BoyaBYJ4y2JYPlcFCU5tTibYkEbkXIeOmiXUuUPRa0vQvgelFQrhS4gltSk
> OXB89x5nWcmqukaw6GOAVLJo/feJwqC9oapfJSLcIXWloKqS8MjVse/GOAKr61b0
> GXIUQmSGJPvFgnYt8FiPyGE+1Nh19UPtCJ0TBsaIUheDilr34BxEX1X6EqmYRCjA
> iNpedmlyMtqCX0w28QJa4l2e5rn6mIIxYEuytdNAih3tqxiuuneDzCwz5c7RKSsk
> KD5iQxwCKSr1D1CJyMKX
> =Z87j
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ming Yap,
On 5/18/15 11:43 AM, Kim Ming Yap wrote:
> so who control the data flow?
The data is really just a data stream. Anyone dumping data into that
stream "controls the flow". Any component with access to the
OutputStream to the client can inject something into it.
The method call flow doesn't place any restrictions on what each
component is allowed to put into that OutputStream.
> Does the data flow has stages just like control flow?
It's the Wild West: any component can do anything it wants.
> Or is it just the http web server? As long as there are output
> stream going out .. the http web server will server those output
> stream to the client's browser?
Exactly.
> Basically no control stages when comes to data flow?
Correct. There are basically two stages:
1. Before the response has been "committed"
2. After the response has been "committed"
The "committment" of the response occurs when either of the following
things happen:
a. The response buffer fills up (container flushes buffer)
b. A component explicitly flushes the response buffer
Before the response has been committed, you can add/modify/remove
response headers, change the response status code (e.g. 200 OK),
request the creation of an HttpSession, and a few other things. After
the response has been committed, you can do none of those things: only
sending bytes to the response stream will work after that.
But again, the only things that triggers the "commit" of the response
if the response buffer filling up (or an explicit flush() call). Any
component can cause that event to occur, and no other components are
notified that it's about to happen.
You can check to see if the response has been committed, but you can't
do anything effective to stop it.
- -chris
>> Date: Mon, 18 May 2015 14:54:24 +0100 From: markt@apache.org To:
>> users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form
>> error page displayed first before response reaches back to Tomcat
>> valve
>>
>> On 18/05/2015 13:57, Kim Ming Yap wrote:
>>> Wow .. that really confuses me.
>>>
>>> I've studied the Java EE component and the basic understanding
>>> of flow is as follows (if i do not flush the data)
>>>
>>> client request --> web container (encapsulate request/response)
>>> --> filter (contain request/response object) --> Servlet (JSP)
>>> --> filter (request / response object here can be modified here
>>> for eventual display on browser) --> client browser
>>>
>>> On the way back the client browser, if i do a break point just
>>> immediately after the dofilter() method and stop there, the JSP
>>> page is not displayed.
>>>
>>> So if i get your right: 1. If the above is done without
>>> flushing the data .. then yes. That JSP page is not displayed
>>> since i stop at the breakpoint.
>>
>> Correct. The entire response is contained in the output buffer at
>> that point.
>>
>>> 2. However if i do a flush before the break point, data will be
>>> send to the client eventhough my code stops at the break
>>> point?
>>
>> Correct. On the first write to the client, the HTTP Response
>> headers will be written. This is the point at which the response
>> is considered to be committed. The first write may also include
>> some/all of the response body.
>>
>> Flushing can be explicit (the application calls it) or implicit
>> (the container calls flush because - for example - there is no
>> more space in the output buffer).
>>
>>> I thought the data flow is part of the control flow ..
>>>
>>> Gee .. i got this wrong all the while Think i'm seeing the
>>> light ..
>>
>> Happy to help.
>>
>> Mark
>>
>>
>>>
>>>
>>>> Date: Mon, 18 May 2015 13:43:14 +0100 From: markt@apache.org
>>>> To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS :
>>>> form error page displayed first before response reaches back
>>>> to Tomcat valve
>>>>
>>>> On 18/05/2015 13:31, Kim Ming Yap wrote:
>>>>>
>>>>> Thanks Mark for your suggestion. I'm still confused over
>>>>> the last part where you mentioned that 'i am confusing
>>>>> myself between control and data'. The response object
>>>>> contains output stream (data) to be displayed. Always the
>>>>> case.
>>>>
>>>> No.
>>>>
>>>> The response contains a reference to the output stream. The
>>>> output stream can be flushed to the client *at any point*.
>>>> There is no guarantee that it will "contain the [data] to be
>>>> displayed".
>>>>
>>>> The (incorrect) sequences you list below describe the control
>>>> flow. The data flow (when the application reads the request
>>>> body, when the application writes the request body and when
>>>> the request body is written to the client) is completely
>>>> separate.
>>>>
>>>>> If i enter valid credential .. you'll noticed the flow
>>>>> exactly as indicated on my email (I've traced is using
>>>>> system.out.println)
>>>>>
>>>>> request --> valve --> JAAS --> filter --> JSP --> response
>>>>> --> filter --> JAAS --> valve --> browser
>>>>
>>>> Again, no. JAAS does not call the filter. Your valve calls
>>>> the Authenticator which calls JAAS and then (via some
>>>> additional objects) the Authenticator calls the filter.
>>>>
>>>> Neither the request nor the response are part of the
>>>> processing chain. They are objects that are passed up and
>>>> down the chain.
>>>>
>>>>
>>>>> If invalid credential ..
>>>>>
>>>>> request --> valve --> JAAS --> response --> valve (break
>>>>> point and stop here) .. yet JSP error page displayed.
>>>>>
>>>>> So this is really confusing.
>>>>
>>>> Take a look at the updated diagrams here:
>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
>>>>
>>>>> The response always contains data to be displayed on the
>>>>> client browser.
>>>>
>>>> No it does not. See comment above re control flow vs data
>>>> flow.
>>>>
>>>>> How did the JSP error page displayed when on its way back
>>>>> to the client browser .. i did a break point stop at the
>>>>> valve.
>>>>
>>>> See point above re control flow vs data flow.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> Hm ..
>>>>>
>>>>>
>>>>>> Date: Mon, 18 May 2015 11:14:19 +0100 From:
>>>>>> markt@apache.org To: users@tomcat.apache.org Subject: Re:
>>>>>> Tomcat valve JAAS : form error page displayed first
>>>>>> before response reaches back to Tomcat valve
>>>>>>
>>>>>> On 17/05/2015 23:44, Kim Ming Yap wrote:
>>>>>>> Hi,I'm building a website using form based
>>>>>>> authentication integrating with JAAS for user based
>>>>>>> authentication. I don't have issue when a successful
>>>>>>> credential is authenticated. Rather I'm having
>>>>>>> difficulty understanding the flow of JAAS back to the
>>>>>>> client should the form based authentication failed.
>>>>>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat
>>>>>>> JAAS Realm OBJECTIVE:Custom error captured in JAAS
>>>>>>> login module to propagate to error page
>>>>>>
>>>>>> You are unlikely to get much help from Tomcat with this
>>>>>> since propagating back custom errors is considered poor
>>>>>> security practise (an attacker should not be able to tell
>>>>>> why authentication failed).
>>>>>>
>>>>>>> BASIC UNDERSTANDING: The Tomcat JAAS layer is not
>>>>>>> integrated with the web container layer. Hence the
>>>>>>> former does not have access to request, session etc.
>>>>>>
>>>>>> JAAS is integrated as a Realm - i.e. something that
>>>>>> validates credentials provided by an Authenticator. The
>>>>>> Authenticator has full access to the request and the
>>>>>> response. You may want to consider a custom
>>>>>> Authenticator.
>>>>>>
>>>>>>> SOLUTION: Using ThreadLocal which capture the custom
>>>>>>> error message in JAAS layer to be used when the flow
>>>>>>> reaches back to the custom valve on the way back to the
>>>>>>> browser.
>>>>>>
>>>>>> You need to be careful you don't trigger memory leaks
>>>>>> when using ThreadLocals.
>>>>>>
>>>>>>> PROBELM:Understanding of basic request/response flow
>>>>>>> involving Tomcat and JAAS a. request --> valve --> JAAS
>>>>>>> --> Filter --> Servlet/JSP b. response <-- valve
>>>>>>> (**) <-- JAAS <-- Filter <-- Servlet/JSP
>>>>>>
>>>>>> I suspect that order is wrong.
>>>>>>
>>>>>> JAAS is called by the Authenticator (which is a valve).
>>>>>> The Authenticator then calls the Filter (via a few other
>>>>>> layers).
>>>>>>
>>>>>> You might want to check the ordering of your valve and
>>>>>> the Authenticator.
>>>>>>
>>>>>>> (refer to above clause b)ThreadLocal in the JAAS layer
>>>>>>> managed to capture the custom error message and it i
>>>>>>> managed to print it after the getNext() method of the
>>>>>>> custom valve. Thought of adding this custom error as an
>>>>>>> attribute in the session object. However I noticed that
>>>>>>> the error page is already displayed before i could add
>>>>>>> this cusom error (immediately after the getNext
>>>>>>> method).
>>>>>>
>>>>>> The error page will be handled by the webapp or the
>>>>>> ErrorReportingValve - both of whichh may get called
>>>>>> before your Valve depending on how the Valve is
>>>>>> configured.
>>>>>>
>>>>>>> Due to that the ready custom error message cannot be
>>>>>>> used SAMPLE CODES: 1. web.xml <login-config>
>>>>>>> <auth-method>FORM</auth-method> <form-login-config>
>>>>>>> <form-login-page>/login.jsp</form-login-page>
>>>>>>> <form-error-page>/login-redirect-error.jsp?error=true</form-erro
r-page>
>>>>>>> </form-login-config> </login-config> 2. Custom valve
>>>>>>> and defined in META-INF/context.xml public class
>>>>>>> SecurityValve extends ValveBase { public void
>>>>>>> invoke(Request request, Response response) throws
>>>>>>> IOException, ServletException {
>>>>>>> getNext().invoke(request, response);
>>>>>>> system.out.println("after getNext()"); --> break point
>>>>>>> (BP) } } 1. Did a break point on SecurityValve
>>>>>>> (indicated at BP) 2. On forms, i purposely enter
>>>>>>> wrong credential and submit 3. Break point
>>>>>>> stops at BP 4. login-redirect-error.jsp displayed
>>>>>>> already 5. Since it stop at break point BP in
>>>>>>> SecurityValve, the response back to client flow has not
>>>>>>> reached the browser. Yet the login-redirect-error.jsp
>>>>>>> is already displayed QUESTIONS: How can the
>>>>>>> login-redirect-error.jsp be displayed on the browser
>>>>>>> when the response flowing back to client stop at break
>>>>>>> point BP? The flow back to the client is not fully done
>>>>>>> yet.
>>>>>>
>>>>>> You are confusing control and data. The data goes back to
>>>>>> the client as soon as the output is flushed (which can
>>>>>> happen in the Servlet/JSP).
>>>>>>
>>>>>>> I would really appreciate any help.Thanks.
>>>>>>
>>>>>> Set a break point in a JSP / Servlet and look at the
>>>>>> stack trace to see which Valves the request/response flow
>>>>>> through in which order.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
- ----
>>>>>>
>>>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVWkbJAAoJEBzwKT+lPKRYdQMQAJIgdQNJXAKoIgp1xFnZBtc6
ng2KtqSxQLltn2aos5R2hqaTN/mcDsWcQ7f+umFBrKYAtu13bP6qvlkkI2ruNQE8
6Gi1xa7ThUnYZ69Ih4D+5cl3uPDSM5nIV5jR+lUTyk0cPsioI92A8h9llXSQV/Ym
qMknTJ1m35BIi7UI2Fqmf4yRXURCECskINe1tWaYiId66+26hYXIB+N2nBy7k0cv
+/WAae6dYRRmq1sAvi5q6VY1+qJigtCyin6HPA6TccnRkfbSqzxRHCoKJg8QMYMZ
EgKOlHew+dcpuE4ZiN+ced6vxEIv96DurwOS00z7tQyHNfrZZGkXGUQTEi/Q5F+J
CJVXKj/H05tJ3+a017lfT51Nr0xVjJRAxuuFxjbfDa2P53Xk0+FO/Hw4e65cB+uc
FcUx+BoyaBYJ4y2JYPlcFCU5tTibYkEbkXIeOmiXUuUPRa0vQvgelFQrhS4gltSk
OXB89x5nWcmqukaw6GOAVLJo/feJwqC9oapfJSLcIXWloKqS8MjVse/GOAKr61b0
GXIUQmSGJPvFgnYt8FiPyGE+1Nh19UPtCJ0TBsaIUheDilr34BxEX1X6EqmYRCjA
iNpedmlyMtqCX0w28QJa4l2e5rn6mIIxYEuytdNAih3tqxiuuneDzCwz5c7RKSsk
KD5iQxwCKSr1D1CJyMKX
=Z87j
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
You said
"The error page will be handled by the webapp or the ErrorReportingValve - both of whichh may get called before your Valve depending on how the Valve is configured."
How do i ensure that my custom valve is called before the the ErrorReportingValve?Is there some settings i can set?
Thanks for your help.
> From: yapkm01@hotmail.com
> To: users@tomcat.apache.org
> Subject: RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> Date: Mon, 18 May 2015 11:43:02 -0400
>
> so who control the data flow?
> Does the data flow has stages just like control flow?
> Or is it just the http web server? As long as there are output stream going out .. the http web server will server those output stream to the client's browser?
> Basically no control stages when comes to data flow?
>
>
> > Date: Mon, 18 May 2015 14:54:24 +0100
> > From: markt@apache.org
> > To: users@tomcat.apache.org
> > Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> >
> > On 18/05/2015 13:57, Kim Ming Yap wrote:
> > > Wow .. that really confuses me.
> > >
> > > I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data)
> > >
> > > client request --> web container (encapsulate request/response) --> filter (contain request/response object) --> Servlet (JSP) --> filter (request / response object here can be modified here for eventual display on browser) --> client browser
> > >
> > > On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed.
> > >
> > > So if i get your right:
> > > 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint.
> >
> > Correct. The entire response is contained in the output buffer at that
> > point.
> >
> > > 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point?
> >
> > Correct. On the first write to the client, the HTTP Response headers
> > will be written. This is the point at which the response is considered
> > to be committed. The first write may also include some/all of the
> > response body.
> >
> > Flushing can be explicit (the application calls it) or implicit (the
> > container calls flush because - for example - there is no more space in
> > the output buffer).
> >
> > > I thought the data flow is part of the control flow ..
> > >
> > > Gee .. i got this wrong all the while
> > > Think i'm seeing the light ..
> >
> > Happy to help.
> >
> > Mark
> >
> >
> > >
> > >
> > >> Date: Mon, 18 May 2015 13:43:14 +0100
> > >> From: markt@apache.org
> > >> To: users@tomcat.apache.org
> > >> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> > >>
> > >> On 18/05/2015 13:31, Kim Ming Yap wrote:
> > >>>
> > >>> Thanks Mark for your suggestion.
> > >>> I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'.
> > >>> The response object contains output stream (data) to be displayed. Always the case.
> > >>
> > >> No.
> > >>
> > >> The response contains a reference to the output stream. The output
> > >> stream can be flushed to the client *at any point*. There is no
> > >> guarantee that it will "contain the [data] to be displayed".
> > >>
> > >> The (incorrect) sequences you list below describe the control flow. The
> > >> data flow (when the application reads the request body, when the
> > >> application writes the request body and when the request body is written
> > >> to the client) is completely separate.
> > >>
> > >>> If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println)
> > >>>
> > >>> request --> valve --> JAAS --> filter --> JSP --> response --> filter --> JAAS --> valve --> browser
> > >>
> > >> Again, no. JAAS does not call the filter. Your valve calls the
> > >> Authenticator which calls JAAS and then (via some additional objects)
> > >> the Authenticator calls the filter.
> > >>
> > >> Neither the request nor the response are part of the processing chain.
> > >> They are objects that are passed up and down the chain.
> > >>
> > >>
> > >>> If invalid credential ..
> > >>>
> > >>> request --> valve --> JAAS --> response --> valve (break point and stop here) .. yet JSP error page displayed.
> > >>>
> > >>> So this is really confusing.
> > >>
> > >> Take a look at the updated diagrams here:
> > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
> > >>
> > >>> The response always contains data to be displayed on the client browser.
> > >>
> > >> No it does not. See comment above re control flow vs data flow.
> > >>
> > >>> How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve.
> > >>
> > >> See point above re control flow vs data flow.
> > >>
> > >> Mark
> > >>
> > >>
> > >>>
> > >>> Hm ..
> > >>>
> > >>>
> > >>>> Date: Mon, 18 May 2015 11:14:19 +0100
> > >>>> From: markt@apache.org
> > >>>> To: users@tomcat.apache.org
> > >>>> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> > >>>>
> > >>>> On 17/05/2015 23:44, Kim Ming Yap wrote:
> > >>>>> Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
> > >>>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> > >>>>> OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
> > >>>>
> > >>>> You are unlikely to get much help from Tomcat with this since
> > >>>> propagating back custom errors is considered poor security practise (an
> > >>>> attacker should not be able to tell why authentication failed).
> > >>>>
> > >>>>> BASIC UNDERSTANDING:
> > >>>>> The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
> > >>>>
> > >>>> JAAS is integrated as a Realm - i.e. something that validates
> > >>>> credentials provided by an Authenticator. The Authenticator has full
> > >>>> access to the request and the response. You may want to consider a
> > >>>> custom Authenticator.
> > >>>>
> > >>>>> SOLUTION:
> > >>>>> Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
> > >>>>
> > >>>> You need to be careful you don't trigger memory leaks when using
> > >>>> ThreadLocals.
> > >>>>
> > >>>>> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
> > >>>>> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
> > >>>>
> > >>>> I suspect that order is wrong.
> > >>>>
> > >>>> JAAS is called by the Authenticator (which is a valve). The
> > >>>> Authenticator then calls the Filter (via a few other layers).
> > >>>>
> > >>>> You might want to check the ordering of your valve and the Authenticator.
> > >>>>
> > >>>>> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
> > >>>>> However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
> > >>>>
> > >>>> The error page will be handled by the webapp or the ErrorReportingValve
> > >>>> - both of whichh may get called before your Valve depending on how the
> > >>>> Valve is configured.
> > >>>>
> > >>>>> Due to that the ready custom error message cannot be used
> > >>>>> SAMPLE CODES:
> > >>>>> 1. web.xml
> > >>>>> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
> > >>>>> 2. Custom valve and defined in META-INF/context.xml
> > >>>>> public class SecurityValve extends ValveBase {
> > >>>>> public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
> > >>>>> }
> > >>>>> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
> > >>>>> QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
> > >>>>
> > >>>> You are confusing control and data. The data goes back to the client as
> > >>>> soon as the output is flushed (which can happen in the Servlet/JSP).
> > >>>>
> > >>>>> I would really appreciate any help.Thanks.
> > >>>>
> > >>>> Set a break point in a JSP / Servlet and look at the stack trace to see
> > >>>> which Valves the request/response flow through in which order.
> > >>>>
> > >>>> Mark
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
so who control the data flow?
Does the data flow has stages just like control flow?
Or is it just the http web server? As long as there are output stream going out .. the http web server will server those output stream to the client's browser?
Basically no control stages when comes to data flow?
> Date: Mon, 18 May 2015 14:54:24 +0100
> From: markt@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>
> On 18/05/2015 13:57, Kim Ming Yap wrote:
> > Wow .. that really confuses me.
> >
> > I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data)
> >
> > client request --> web container (encapsulate request/response) --> filter (contain request/response object) --> Servlet (JSP) --> filter (request / response object here can be modified here for eventual display on browser) --> client browser
> >
> > On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed.
> >
> > So if i get your right:
> > 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint.
>
> Correct. The entire response is contained in the output buffer at that
> point.
>
> > 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point?
>
> Correct. On the first write to the client, the HTTP Response headers
> will be written. This is the point at which the response is considered
> to be committed. The first write may also include some/all of the
> response body.
>
> Flushing can be explicit (the application calls it) or implicit (the
> container calls flush because - for example - there is no more space in
> the output buffer).
>
> > I thought the data flow is part of the control flow ..
> >
> > Gee .. i got this wrong all the while
> > Think i'm seeing the light ..
>
> Happy to help.
>
> Mark
>
>
> >
> >
> >> Date: Mon, 18 May 2015 13:43:14 +0100
> >> From: markt@apache.org
> >> To: users@tomcat.apache.org
> >> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> >>
> >> On 18/05/2015 13:31, Kim Ming Yap wrote:
> >>>
> >>> Thanks Mark for your suggestion.
> >>> I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'.
> >>> The response object contains output stream (data) to be displayed. Always the case.
> >>
> >> No.
> >>
> >> The response contains a reference to the output stream. The output
> >> stream can be flushed to the client *at any point*. There is no
> >> guarantee that it will "contain the [data] to be displayed".
> >>
> >> The (incorrect) sequences you list below describe the control flow. The
> >> data flow (when the application reads the request body, when the
> >> application writes the request body and when the request body is written
> >> to the client) is completely separate.
> >>
> >>> If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println)
> >>>
> >>> request --> valve --> JAAS --> filter --> JSP --> response --> filter --> JAAS --> valve --> browser
> >>
> >> Again, no. JAAS does not call the filter. Your valve calls the
> >> Authenticator which calls JAAS and then (via some additional objects)
> >> the Authenticator calls the filter.
> >>
> >> Neither the request nor the response are part of the processing chain.
> >> They are objects that are passed up and down the chain.
> >>
> >>
> >>> If invalid credential ..
> >>>
> >>> request --> valve --> JAAS --> response --> valve (break point and stop here) .. yet JSP error page displayed.
> >>>
> >>> So this is really confusing.
> >>
> >> Take a look at the updated diagrams here:
> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
> >>
> >>> The response always contains data to be displayed on the client browser.
> >>
> >> No it does not. See comment above re control flow vs data flow.
> >>
> >>> How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve.
> >>
> >> See point above re control flow vs data flow.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Hm ..
> >>>
> >>>
> >>>> Date: Mon, 18 May 2015 11:14:19 +0100
> >>>> From: markt@apache.org
> >>>> To: users@tomcat.apache.org
> >>>> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> >>>>
> >>>> On 17/05/2015 23:44, Kim Ming Yap wrote:
> >>>>> Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
> >>>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> >>>>> OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
> >>>>
> >>>> You are unlikely to get much help from Tomcat with this since
> >>>> propagating back custom errors is considered poor security practise (an
> >>>> attacker should not be able to tell why authentication failed).
> >>>>
> >>>>> BASIC UNDERSTANDING:
> >>>>> The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
> >>>>
> >>>> JAAS is integrated as a Realm - i.e. something that validates
> >>>> credentials provided by an Authenticator. The Authenticator has full
> >>>> access to the request and the response. You may want to consider a
> >>>> custom Authenticator.
> >>>>
> >>>>> SOLUTION:
> >>>>> Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
> >>>>
> >>>> You need to be careful you don't trigger memory leaks when using
> >>>> ThreadLocals.
> >>>>
> >>>>> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
> >>>>> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
> >>>>
> >>>> I suspect that order is wrong.
> >>>>
> >>>> JAAS is called by the Authenticator (which is a valve). The
> >>>> Authenticator then calls the Filter (via a few other layers).
> >>>>
> >>>> You might want to check the ordering of your valve and the Authenticator.
> >>>>
> >>>>> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
> >>>>> However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
> >>>>
> >>>> The error page will be handled by the webapp or the ErrorReportingValve
> >>>> - both of whichh may get called before your Valve depending on how the
> >>>> Valve is configured.
> >>>>
> >>>>> Due to that the ready custom error message cannot be used
> >>>>> SAMPLE CODES:
> >>>>> 1. web.xml
> >>>>> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
> >>>>> 2. Custom valve and defined in META-INF/context.xml
> >>>>> public class SecurityValve extends ValveBase {
> >>>>> public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
> >>>>> }
> >>>>> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
> >>>>> QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
> >>>>
> >>>> You are confusing control and data. The data goes back to the client as
> >>>> soon as the output is flushed (which can happen in the Servlet/JSP).
> >>>>
> >>>>> I would really appreciate any help.Thanks.
> >>>>
> >>>> Set a break point in a JSP / Servlet and look at the stack trace to see
> >>>> which Valves the request/response flow through in which order.
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before response
reaches back to Tomcat valve
Posted by Mark Thomas <ma...@apache.org>.
On 18/05/2015 13:57, Kim Ming Yap wrote:
> Wow .. that really confuses me.
>
> I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data)
>
> client request --> web container (encapsulate request/response) --> filter (contain request/response object) --> Servlet (JSP) --> filter (request / response object here can be modified here for eventual display on browser) --> client browser
>
> On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed.
>
> So if i get your right:
> 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint.
Correct. The entire response is contained in the output buffer at that
point.
> 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point?
Correct. On the first write to the client, the HTTP Response headers
will be written. This is the point at which the response is considered
to be committed. The first write may also include some/all of the
response body.
Flushing can be explicit (the application calls it) or implicit (the
container calls flush because - for example - there is no more space in
the output buffer).
> I thought the data flow is part of the control flow ..
>
> Gee .. i got this wrong all the while
> Think i'm seeing the light ..
Happy to help.
Mark
>
>
>> Date: Mon, 18 May 2015 13:43:14 +0100
>> From: markt@apache.org
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>>
>> On 18/05/2015 13:31, Kim Ming Yap wrote:
>>>
>>> Thanks Mark for your suggestion.
>>> I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'.
>>> The response object contains output stream (data) to be displayed. Always the case.
>>
>> No.
>>
>> The response contains a reference to the output stream. The output
>> stream can be flushed to the client *at any point*. There is no
>> guarantee that it will "contain the [data] to be displayed".
>>
>> The (incorrect) sequences you list below describe the control flow. The
>> data flow (when the application reads the request body, when the
>> application writes the request body and when the request body is written
>> to the client) is completely separate.
>>
>>> If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println)
>>>
>>> request --> valve --> JAAS --> filter --> JSP --> response --> filter --> JAAS --> valve --> browser
>>
>> Again, no. JAAS does not call the filter. Your valve calls the
>> Authenticator which calls JAAS and then (via some additional objects)
>> the Authenticator calls the filter.
>>
>> Neither the request nor the response are part of the processing chain.
>> They are objects that are passed up and down the chain.
>>
>>
>>> If invalid credential ..
>>>
>>> request --> valve --> JAAS --> response --> valve (break point and stop here) .. yet JSP error page displayed.
>>>
>>> So this is really confusing.
>>
>> Take a look at the updated diagrams here:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
>>
>>> The response always contains data to be displayed on the client browser.
>>
>> No it does not. See comment above re control flow vs data flow.
>>
>>> How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve.
>>
>> See point above re control flow vs data flow.
>>
>> Mark
>>
>>
>>>
>>> Hm ..
>>>
>>>
>>>> Date: Mon, 18 May 2015 11:14:19 +0100
>>>> From: markt@apache.org
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>>>>
>>>> On 17/05/2015 23:44, Kim Ming Yap wrote:
>>>>> Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
>>>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
>>>>> OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
>>>>
>>>> You are unlikely to get much help from Tomcat with this since
>>>> propagating back custom errors is considered poor security practise (an
>>>> attacker should not be able to tell why authentication failed).
>>>>
>>>>> BASIC UNDERSTANDING:
>>>>> The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
>>>>
>>>> JAAS is integrated as a Realm - i.e. something that validates
>>>> credentials provided by an Authenticator. The Authenticator has full
>>>> access to the request and the response. You may want to consider a
>>>> custom Authenticator.
>>>>
>>>>> SOLUTION:
>>>>> Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
>>>>
>>>> You need to be careful you don't trigger memory leaks when using
>>>> ThreadLocals.
>>>>
>>>>> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
>>>>> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
>>>>
>>>> I suspect that order is wrong.
>>>>
>>>> JAAS is called by the Authenticator (which is a valve). The
>>>> Authenticator then calls the Filter (via a few other layers).
>>>>
>>>> You might want to check the ordering of your valve and the Authenticator.
>>>>
>>>>> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
>>>>> However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
>>>>
>>>> The error page will be handled by the webapp or the ErrorReportingValve
>>>> - both of whichh may get called before your Valve depending on how the
>>>> Valve is configured.
>>>>
>>>>> Due to that the ready custom error message cannot be used
>>>>> SAMPLE CODES:
>>>>> 1. web.xml
>>>>> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
>>>>> 2. Custom valve and defined in META-INF/context.xml
>>>>> public class SecurityValve extends ValveBase {
>>>>> public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
>>>>> }
>>>>> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
>>>>> QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
>>>>
>>>> You are confusing control and data. The data goes back to the client as
>>>> soon as the output is flushed (which can happen in the Servlet/JSP).
>>>>
>>>>> I would really appreciate any help.Thanks.
>>>>
>>>> Set a break point in a JSP / Servlet and look at the stack trace to see
>>>> which Valves the request/response flow through in which order.
>>>>
>>>> Mark
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
Wow .. that really confuses me.
I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data)
client request --> web container (encapsulate request/response) --> filter (contain request/response object) --> Servlet (JSP) --> filter (request / response object here can be modified here for eventual display on browser) --> client browser
On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed.
So if i get your right:
1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint.
2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point?
I thought the data flow is part of the control flow ..
Gee .. i got this wrong all the while
Think i'm seeing the light ..
> Date: Mon, 18 May 2015 13:43:14 +0100
> From: markt@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>
> On 18/05/2015 13:31, Kim Ming Yap wrote:
> >
> > Thanks Mark for your suggestion.
> > I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'.
> > The response object contains output stream (data) to be displayed. Always the case.
>
> No.
>
> The response contains a reference to the output stream. The output
> stream can be flushed to the client *at any point*. There is no
> guarantee that it will "contain the [data] to be displayed".
>
> The (incorrect) sequences you list below describe the control flow. The
> data flow (when the application reads the request body, when the
> application writes the request body and when the request body is written
> to the client) is completely separate.
>
> > If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println)
> >
> > request --> valve --> JAAS --> filter --> JSP --> response --> filter --> JAAS --> valve --> browser
>
> Again, no. JAAS does not call the filter. Your valve calls the
> Authenticator which calls JAAS and then (via some additional objects)
> the Authenticator calls the filter.
>
> Neither the request nor the response are part of the processing chain.
> They are objects that are passed up and down the chain.
>
>
> > If invalid credential ..
> >
> > request --> valve --> JAAS --> response --> valve (break point and stop here) .. yet JSP error page displayed.
> >
> > So this is really confusing.
>
> Take a look at the updated diagrams here:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
>
> > The response always contains data to be displayed on the client browser.
>
> No it does not. See comment above re control flow vs data flow.
>
> > How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve.
>
> See point above re control flow vs data flow.
>
> Mark
>
>
> >
> > Hm ..
> >
> >
> >> Date: Mon, 18 May 2015 11:14:19 +0100
> >> From: markt@apache.org
> >> To: users@tomcat.apache.org
> >> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
> >>
> >> On 17/05/2015 23:44, Kim Ming Yap wrote:
> >>> Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
> >>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> >>> OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
> >>
> >> You are unlikely to get much help from Tomcat with this since
> >> propagating back custom errors is considered poor security practise (an
> >> attacker should not be able to tell why authentication failed).
> >>
> >>> BASIC UNDERSTANDING:
> >>> The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
> >>
> >> JAAS is integrated as a Realm - i.e. something that validates
> >> credentials provided by an Authenticator. The Authenticator has full
> >> access to the request and the response. You may want to consider a
> >> custom Authenticator.
> >>
> >>> SOLUTION:
> >>> Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
> >>
> >> You need to be careful you don't trigger memory leaks when using
> >> ThreadLocals.
> >>
> >>> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
> >>> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
> >>
> >> I suspect that order is wrong.
> >>
> >> JAAS is called by the Authenticator (which is a valve). The
> >> Authenticator then calls the Filter (via a few other layers).
> >>
> >> You might want to check the ordering of your valve and the Authenticator.
> >>
> >>> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
> >>> However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
> >>
> >> The error page will be handled by the webapp or the ErrorReportingValve
> >> - both of whichh may get called before your Valve depending on how the
> >> Valve is configured.
> >>
> >>> Due to that the ready custom error message cannot be used
> >>> SAMPLE CODES:
> >>> 1. web.xml
> >>> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
> >>> 2. Custom valve and defined in META-INF/context.xml
> >>> public class SecurityValve extends ValveBase {
> >>> public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
> >>> }
> >>> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
> >>> QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
> >>
> >> You are confusing control and data. The data goes back to the client as
> >> soon as the output is flushed (which can happen in the Servlet/JSP).
> >>
> >>> I would really appreciate any help.Thanks.
> >>
> >> Set a break point in a JSP / Servlet and look at the stack trace to see
> >> which Valves the request/response flow through in which order.
> >>
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before response
reaches back to Tomcat valve
Posted by Mark Thomas <ma...@apache.org>.
On 18/05/2015 13:31, Kim Ming Yap wrote:
>
> Thanks Mark for your suggestion.
> I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'.
> The response object contains output stream (data) to be displayed. Always the case.
No.
The response contains a reference to the output stream. The output
stream can be flushed to the client *at any point*. There is no
guarantee that it will "contain the [data] to be displayed".
The (incorrect) sequences you list below describe the control flow. The
data flow (when the application reads the request body, when the
application writes the request body and when the request body is written
to the client) is completely separate.
> If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println)
>
> request --> valve --> JAAS --> filter --> JSP --> response --> filter --> JAAS --> valve --> browser
Again, no. JAAS does not call the filter. Your valve calls the
Authenticator which calls JAAS and then (via some additional objects)
the Authenticator calls the filter.
Neither the request nor the response are part of the processing chain.
They are objects that are passed up and down the chain.
> If invalid credential ..
>
> request --> valve --> JAAS --> response --> valve (break point and stop here) .. yet JSP error page displayed.
>
> So this is really confusing.
Take a look at the updated diagrams here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
> The response always contains data to be displayed on the client browser.
No it does not. See comment above re control flow vs data flow.
> How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve.
See point above re control flow vs data flow.
Mark
>
> Hm ..
>
>
>> Date: Mon, 18 May 2015 11:14:19 +0100
>> From: markt@apache.org
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>>
>> On 17/05/2015 23:44, Kim Ming Yap wrote:
>>> Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
>>> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
>>> OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
>>
>> You are unlikely to get much help from Tomcat with this since
>> propagating back custom errors is considered poor security practise (an
>> attacker should not be able to tell why authentication failed).
>>
>>> BASIC UNDERSTANDING:
>>> The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
>>
>> JAAS is integrated as a Realm - i.e. something that validates
>> credentials provided by an Authenticator. The Authenticator has full
>> access to the request and the response. You may want to consider a
>> custom Authenticator.
>>
>>> SOLUTION:
>>> Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
>>
>> You need to be careful you don't trigger memory leaks when using
>> ThreadLocals.
>>
>>> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
>>> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
>>
>> I suspect that order is wrong.
>>
>> JAAS is called by the Authenticator (which is a valve). The
>> Authenticator then calls the Filter (via a few other layers).
>>
>> You might want to check the ordering of your valve and the Authenticator.
>>
>>> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
>>> However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
>>
>> The error page will be handled by the webapp or the ErrorReportingValve
>> - both of whichh may get called before your Valve depending on how the
>> Valve is configured.
>>
>>> Due to that the ready custom error message cannot be used
>>> SAMPLE CODES:
>>> 1. web.xml
>>> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
>>> 2. Custom valve and defined in META-INF/context.xml
>>> public class SecurityValve extends ValveBase {
>>> public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
>>> }
>>> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
>>> QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
>>
>> You are confusing control and data. The data goes back to the client as
>> soon as the output is flushed (which can happen in the Servlet/JSP).
>>
>>> I would really appreciate any help.Thanks.
>>
>> Set a break point in a JSP / Servlet and look at the stack trace to see
>> which Valves the request/response flow through in which order.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
Posted by Kim Ming Yap <ya...@hotmail.com>.
Thanks Mark for your suggestion.
I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'.
The response object contains output stream (data) to be displayed. Always the case.
If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println)
request --> valve --> JAAS --> filter --> JSP --> response --> filter --> JAAS --> valve --> browser
If invalid credential ..
request --> valve --> JAAS --> response --> valve (break point and stop here) .. yet JSP error page displayed.
So this is really confusing.
The response always contains data to be displayed on the client browser.
How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve.
Hm ..
> Date: Mon, 18 May 2015 11:14:19 +0100
> From: markt@apache.org
> To: users@tomcat.apache.org
> Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
>
> On 17/05/2015 23:44, Kim Ming Yap wrote:
> > Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
> > SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> > OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
>
> You are unlikely to get much help from Tomcat with this since
> propagating back custom errors is considered poor security practise (an
> attacker should not be able to tell why authentication failed).
>
> > BASIC UNDERSTANDING:
> > The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
>
> JAAS is integrated as a Realm - i.e. something that validates
> credentials provided by an Authenticator. The Authenticator has full
> access to the request and the response. You may want to consider a
> custom Authenticator.
>
> > SOLUTION:
> > Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
>
> You need to be careful you don't trigger memory leaks when using
> ThreadLocals.
>
> > PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
> > a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
>
> I suspect that order is wrong.
>
> JAAS is called by the Authenticator (which is a valve). The
> Authenticator then calls the Filter (via a few other layers).
>
> You might want to check the ordering of your valve and the Authenticator.
>
> > (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
> > However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
>
> The error page will be handled by the webapp or the ErrorReportingValve
> - both of whichh may get called before your Valve depending on how the
> Valve is configured.
>
> > Due to that the ready custom error message cannot be used
> > SAMPLE CODES:
> > 1. web.xml
> > <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
> > 2. Custom valve and defined in META-INF/context.xml
> > public class SecurityValve extends ValveBase {
> > public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
> > }
> > 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
> > QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
>
> You are confusing control and data. The data goes back to the client as
> soon as the output is flushed (which can happen in the Servlet/JSP).
>
> > I would really appreciate any help.Thanks.
>
> Set a break point in a JSP / Servlet and look at the stack trace to see
> which Valves the request/response flow through in which order.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat valve JAAS : form error page displayed first before response
reaches back to Tomcat valve
Posted by Mark Thomas <ma...@apache.org>.
On 17/05/2015 23:44, Kim Ming Yap wrote:
> Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed.
> SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
> OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
You are unlikely to get much help from Tomcat with this since
propagating back custom errors is considered poor security practise (an
attacker should not be able to tell why authentication failed).
> BASIC UNDERSTANDING:
> The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc.
JAAS is integrated as a Realm - i.e. something that validates
credentials provided by an Authenticator. The Authenticator has full
access to the request and the response. You may want to consider a
custom Authenticator.
> SOLUTION:
> Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser.
You need to be careful you don't trigger memory leaks when using
ThreadLocals.
> PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
> a. request --> valve --> JAAS --> Filter --> Servlet/JSP b. response <-- valve (**) <-- JAAS <-- Filter <-- Servlet/JSP
I suspect that order is wrong.
JAAS is called by the Authenticator (which is a valve). The
Authenticator then calls the Filter (via a few other layers).
You might want to check the ordering of your valve and the Authenticator.
> (refer to above clause b)ThreadLocal in the JAAS layer managed to capture the custom error message and it i managed to print it after the getNext() method of the custom valve. Thought of adding this custom error as an attribute in the session object.
> However I noticed that the error page is already displayed before i could add this cusom error (immediately after the getNext method).
The error page will be handled by the webapp or the ErrorReportingValve
- both of whichh may get called before your Valve depending on how the
Valve is configured.
> Due to that the ready custom error message cannot be used
> SAMPLE CODES:
> 1. web.xml
> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-redirect-error.jsp?error=true</form-error-page> </form-login-config> </login-config>
> 2. Custom valve and defined in META-INF/context.xml
> public class SecurityValve extends ValveBase {
> public void invoke(Request request, Response response) throws IOException, ServletException { getNext().invoke(request, response); system.out.println("after getNext()"); --> break point (BP) }
> }
> 1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i purposely enter wrong credential and submit 3. Break point stops at BP 4. login-redirect-error.jsp displayed already 5. Since it stop at break point BP in SecurityValve, the response back to client flow has not reached the browser. Yet the login-redirect-error.jsp is already displayed
> QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser when the response flowing back to client stop at break point BP? The flow back to the client is not fully done yet.
You are confusing control and data. The data goes back to the client as
soon as the output is flushed (which can happen in the Servlet/JSP).
> I would really appreciate any help.Thanks.
Set a break point in a JSP / Servlet and look at the stack trace to see
which Valves the request/response flow through in which order.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org