[keycloak-dev] Rest password can cause cookie not found

[Stian Thorgersen]

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 27 January, 2015 4:05:14 PM
> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> 
> 
> 
> Am 27. Januar 2015 um 10:49 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> 
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 10:33:09 AM
> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke at redhat.com>:
> >
> >
> > On 1/26/2015 1:31 PM, Michael Gerber wrote:
> >>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com
> >>>
> >>> <mailto:bburke at redhat.com>>:
> >>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
> >>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com
> >>>>>
> >>>>> <mailto:bburke at redhat.com>>:
> >>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> <mailto:keycloak-dev at lists.jboss.org>
> >>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
> >>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> >>>>>>> Wouldn't this work?
> >>>>>>> 1) store "state" of state cookie in user session.
> >>>>>>> 2) embed user session and state of state cookie in URL
> >>>>>>> Of course this screws up your "shorter URL" crusade.
> >>>>>> I'm not following - the problem isn't remembering the state
> >>>>>> variable in Keycloak, that's already sorted as we already store all
> >>>>>> the query params passed by the client in the client session (state,
> >>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
> >>>>> I think I get it...
> >>>>> 1. Send email
> >>>>> 2. Close browser
> >>>>> 3. Open browser
> >>>>> 4. Click email link
> >>>>> 5. Reset password
> >>>>> 6. Redirect back to app
> >>>>> 7. App barfs because of state cookie
> >>>>> Persistent state cookie sounds like cleanest and simplest solution. I
> >>>>> just worry we'll introduce different bugs, or if we're opening up some
> >>>>> kind of security hole. Maybe I'm just paranoid.
> >>>> That doesn't work if the user uses two different browsers. This is
> >>>> the case in a lot of companies (at least in Switzerland :)) where the
> >>>> users are forced to use ie (default) but rather work with firefox.
> >>> Unless we extend the protocol, or don’t redirect from the email, I
> >>> don’t see a fix.
> >> If the password reset process would redirect without the code and state
> >> param, than the adapter would redirect back to the keycloak, and
> >> keycloak can authenticate the user with its identity cookie…
> >> But I don’t know if that is ok with the protocol.
> >
> > So maybe have a session cookie that is set by the auth server. If that
> > cookie is set when clicking the email url, redirect with code, if not,
> > redirect without it.
> >
> That sounds good, what do the other think about this fallback option?
> I can update the JIRA issue if anybody is happy with that solution.
> 
> I'm happy with the idea of setting a session cookie so we can detect if a
> user is using the same browser to complete the flow. However, I don't think
> we should redirect back to the application.
> 
> In this case the user most likely wants to use a different browser for the
> application. For example a user uses Firefox to open the application, click
> on recover password, but then due to company policies IE is registered as
> the default OS browser so links in emails are opened in IE instead. In this
> case the user wants to close IE after resetting the password and go back to
> Firefox to use the application.
> 
> In the case the user is completing the password reset flow in a different
> browser it would be better to update the password, make sure no identity
> cookie or user session is created in the new browser, then just display a
> message "Your password has been updated".
> Why do you want to make sure that no identity cookie is generated?
> Wouldn't it be nice to generate the cookie and display a message to the user
> with a link to the desired redirect uri?
> So, the user can still redirect to the uri without a login?

In the above example the user wanted to login with Firefox, not IE, so why create a SSO session in IE.

You can't redirect back to the application without a code or error, as it's an oauth callback url. If the application has a base url registered we can add a back to application link, but in this case I assume the user is going to want to close IE and go back to Firefox.

> 
> I read that you want to release 1.1.0 Final in the next view days. So I guess
> this bug/feature will be implemented in 1.2.0?
> 
> 
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com