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

Matthias Wessendorf matzew at apache.org
Thu Jun 20 08:31:17 EDT 2013


On Thu, Jun 20, 2013 at 2:28 PM, Kris Borchers <kris at redhat.com> 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.
>

yep, I am with out there :)



>
> On Jun 20, 2013, at 7:15 AM, Matthias Wessendorf <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" -v
>
> ==> I get the protected page
>
>
> curl -k --basic -b cookies.txt -c cookies.txt -u badUser:badPasswd "
> 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> 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>
>> 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 theSet-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
>> 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
>>
>
>
>
> --
> 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
> 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130620/7ac9d59f/attachment.html 


More information about the aerogear-dev mailing list