[aerogear-dev] Basic/Digest issue with the Controller or AG Security?

[Summers Pittman]

On 06/20/2013 08:28 AM, Kris Borchers wrote:
> I can agree that sending incorrect credentials should not work. You 
> shouldn't be sending credentials again if you have a valid cookie but 
> if you do and they are wrong, I agree that you should not be 
> authenticated. The question then is, should the cookie be invalidated 
> or if I try again with the cookie but without credentials, should it 
> work. I would probably lean toward invalidating the cookie and forcing 
> the auth process to start over, I think.
That makes the most sense.  HTTP Basic doesn't require a cookie so 
whatever we do here is rather arbitrary...
>
> On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <matzew at apache.org 
> <mailto:matzew at apache.org>> wrote:
>
>> I have tried an internal service, tried the similar like about (with 
>> basic/curl)
>>
>> curl -k --basic -b cookies.txt -c cookies.txt -u goodUser:goodPasswd 
>> "https://something.redhat.com <https://something.redhat.com/>" -v
>>
>> ==> I get the protected page
>>
>>
>> curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd 
>> "https://something.redhat.com <https://something.redhat.com/>" -v
>>
>> ==> I am NOT getting the protected page :)
>>
>>
>> Not sure, but I do like the fact that the second curl is not 
>> successful :-)
>>
>>
>>
>>
>>
>> On Thu, Jun 20, 2013 at 2:04 PM, Kris Borchers <kris at redhat.com 
>> <mailto:kris at redhat.com>> wrote:
>>
>>     Isn't this how Basic auth works? Once you log in you get a cookie
>>     and you don't have to authenticate anymore until that cooke
>>     expires (usually at the end of a session). This is my experience
>>     in browsers at least and is how I would expect it to work. If I
>>     have a valid cookie, I should not have to log in again.
>>
>>     On Jun 20, 2013, at 6:59 AM, Matthias Wessendorf
>>     <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>>
>>>     Hi,
>>>
>>>     when looking into HTTP Basic/Digest for iOS, Christos noticed a
>>>     problem with that, on the Controller demo (using AG-Security).
>>>
>>>     I have checked his issues and they are "visible" in cURL
>>>     "environment" as well.
>>>
>>>     Steps to reproduce
>>>
>>>       * Clone the AG-Controller demo
>>>         <https://github.com/aerogear/aerogear-controller-demo>
>>>       * Update the |web.xml| to use the BASIC Filter (here
>>>         <https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/webapp/WEB-INF/web.xml#L34-L41> and
>>>         here
>>>         <https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/webapp/WEB-INF/web.xml#L78-L82>).
>>>       * Make /*SURE*/ that the Digiest section is commented out :-)
>>>       * Deploy the |WAR| to your JBoss Application Server
>>>
>>>     Now some tests with BASIC (and the default user |john:123|):
>>>
>>>     |curl -u "john:123" "http://localhost:8080/aerogear-controller-demo/autobots" -v
>>>     |
>>>
>>>     This works, as expected!
>>>
>>>     |curl -u "john:007" "http://localhost:8080/aerogear-controller-demo/autobots" -v
>>>     |
>>>
>>>     This does /*NOT*/ work, as expected!
>>>
>>>
>>>           <https://gist.github.com/matzew/6111c42ff5d73f18097e#cookies->Cookies
>>>           ?
>>>
>>>     Christos and I noticed the server does return the
>>>     |Set-Cookie:| response header, so the cookie can/will be stored
>>>     on the client.
>>>
>>>     Now let's do this:
>>>
>>>     |curl --basic -b cookies.txt -c cookies.txt -u john:123 \
>>>     "http://localhost:8080/aerogear-controller-demo/autobots" -v
>>>     |
>>>
>>>     Perfect, works as well
>>>
>>>     But now, let's do this:
>>>
>>>     |curl --basic -b cookies.txt -c cookies.txt -u john:007 \
>>>     "http://localhost:8080/aerogear-controller-demo/autobots" -v
>>>     |
>>>
>>>     Unfortunatley, this works as well, since the session is reused,
>>>     due to the cookies... So, when the session is stored on the
>>>     client, it is possible to switch the credentials "on the fly".
>>>
>>>
>>>         <https://gist.github.com/matzew/6111c42ff5d73f18097e#question--comments>Question
>>>         / Comments
>>>
>>>      *
>>>
>>>         Not really sure, but for Basic/Digest should the server
>>>         really send |Set-Cookie:| response header back to the client ?
>>>
>>>      *
>>>
>>>         Not sure this is something on the controller, AG-Security or
>>>         even PicketLink, but perhaps the|Set-Cookie:| could be
>>>         removed, when sending the response for Basic/Digest
>>>
>>>     Ant thoughts on this ?
>>>
>>>     -- 
>>>     Matthias Wessendorf
>>>
>>>     blog: http://matthiaswessendorf.wordpress.com/
>>>     sessions: http://www.slideshare.net/mwessendorf
>>>     twitter: http://twitter.com/mwessendorf
>>>     _______________________________________________
>>>     aerogear-dev mailing list
>>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>     _______________________________________________
>>     aerogear-dev mailing list
>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>> -- 
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130620/0550fe99/attachment-0001.html