<html><body><div><br></div><div><br>Am 27. Januar 2015 um 10:49 schrieb Stian Thorgersen <stian@redhat.com>:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content"><br><br>----- Original Message -----<br></span></span><blockquote class="quoted-plain-text" type="cite">From: "Michael Gerber" <<a href="mailto:gerbermichi@me.com" data-mce-href="mailto:gerbermichi@me.com">gerbermichi@me.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">To: "Bill Burke" <<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">Cc: "Stian Thorgersen" <<a href="mailto:stian@redhat.com" data-mce-href="mailto:stian@redhat.com">stian@redhat.com</a>>, <a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></blockquote><blockquote class="quoted-plain-text" type="cite">Sent: Tuesday, January 27, 2015 10:33:09 AM</blockquote><blockquote class="quoted-plain-text" type="cite">Subject: Re: [keycloak-dev] Rest password can cause cookie not found</blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">Am 26. Januar 2015 um 20:49 schrieb Bill Burke <<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a>>:</blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> On 1/26/2015 1:31 PM, Michael Gerber wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">>>> Am 26.01.2015 um 18:36 schrieb Bill Burke <<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a></blockquote><blockquote class="quoted-plain-text" type="cite">>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>> <mailto:<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>:</blockquote><blockquote class="quoted-plain-text" type="cite">>>> On 1/26/2015 12:12 PM, Michael Gerber wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a></blockquote><blockquote class="quoted-plain-text" type="cite">>>>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> <mailto:<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>:</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>> ----- Original Message -----</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> From: "Bill Burke" <<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" data-mce-href="mailto:bburke@redhat.com">bburke@redhat.com</a>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> To: <a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> <mailto:<a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> Wouldn't this work?</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> 1) store "state" of state cookie in user session.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> 2) embed user session and state of state cookie in URL</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>>> Of course this screws up your "shorter URL" crusade.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>> I'm not following - the problem isn't remembering the state</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>> variable in Keycloak, that's already sorted as we already store all</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>> the query params passed by the client in the client session (state,</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>>> redirect_uri, etc). The problem is storing it on the adapter side.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> I think I get it...</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 1. Send email</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 2. Close browser</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 3. Open browser</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 4. Click email link</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 5. Reset password</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 6. Redirect back to app</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> 7. App barfs because of state cookie</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> Persistent state cookie sounds like cleanest and simplest solution. I</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> just worry we'll introduce different bugs, or if we're opening up some</blockquote><blockquote class="quoted-plain-text" type="cite">>>>>> kind of security hole. Maybe I'm just paranoid.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> That doesn't work if the user uses two different browsers. This is</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> the case in a lot of companies (at least in Switzerland :)) where the</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> users are forced to use ie (default) but rather work with firefox.</blockquote><blockquote class="quoted-plain-text" type="cite">>>> Unless we extend the protocol, or don’t redirect from the email, I</blockquote><blockquote class="quoted-plain-text" type="cite">>>> don’t see a fix.</blockquote><blockquote class="quoted-plain-text" type="cite">>> If the password reset process would redirect without the code and state</blockquote><blockquote class="quoted-plain-text" type="cite">>> param, than the adapter would redirect back to the keycloak, and</blockquote><blockquote class="quoted-plain-text" type="cite">>> keycloak can authenticate the user with its identity cookie…</blockquote><blockquote class="quoted-plain-text" type="cite">>> But I don’t know if that is ok with the protocol.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> So maybe have a session cookie that is set by the auth server. If that</blockquote><blockquote class="quoted-plain-text" type="cite">> cookie is set when clicking the email url, redirect with code, if not,</blockquote><blockquote class="quoted-plain-text" type="cite">> redirect without it.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">That sounds good, what do the other think about this fallback option?</blockquote><blockquote class="quoted-plain-text" type="cite">I can update the JIRA issue if anybody is happy with that solution.</blockquote><span class="body-text-content"><span class="body-text-content"><br>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.<br><br>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.<br><br>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".</span></span></div></div></blockquote></div><div>Why do you want to make sure that no identity cookie is generated? </div><div>Wouldn't it be nice to generate the cookie and display a message to the user with a link to the desired redirect uri?</div><div>So, the user can still redirect to the uri without a login?</div><div><br></div><div>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?</div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content"><br><br></span></span><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> --</blockquote><blockquote class="quoted-plain-text" type="cite">> Bill Burke</blockquote><blockquote class="quoted-plain-text" type="cite">> JBoss, a division of Red Hat</blockquote><blockquote class="quoted-plain-text" type="cite">> <a href="http://bill.burkecentral.com" data-mce-href="http://bill.burkecentral.com">http://bill.burkecentral.com</a></blockquote></div></div></blockquote></div></body></html>