Re: [keycloak-dev] User actions

I've implemented the following screens to cover this flow: - http://ejsclient-cardosogabriel.rhcloud.com/saas-forgot-password.html User comes here from the link "Forgot password" in the login page. Click submit to see the feedback of success. - http://ejsclient-cardosogabriel.rhcloud.com/saas-password-reset.html After clicking the link in the email, the user can update his password. - http://ejsclient-cardosogabriel.rhcloud.com/saas-login.html After clicking submit in the "Password reset" screen, the user is redirected to the login page and sees that his password was saved. Now he can log in to Keycloak. Gabriel On Sep 17, 2013, at 5:42 AM, Stian Thorgersen wrote: > Yes, the flow should be: > > * User tries to login to an application and realizes that he doesn't remember password > * Click on reset password > * A page shows that an email has been sent to the user (including a link to resend) > * The user then receives an email with a link that the user clicks on > * When the user has clicked on the link the user is brought to the reset password form and can insert a new password (and password confirmation) > * When the user submits the reset password form the user is logged in to the realm and redirected to the application > > How long the user has to click the link in the email depends on the Realm settings. By default I think it should be 15 minutes (or something along those lines). > > There's also other cases: > > * Admin initiates reset on behalf of user - in this case a user gets a email, but once the password is changed the user is redirected to the account management pages > * In the above scenario if there was not a validated email associated with the user the user is given a temporary password by the admin - on the first login with this temporary password the user is required to change it > * A password could have expired, in which case the user is required to change it on next long > > ----- Original Message ----- >> From: "Gabriel Cardoso" <gcardoso(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Monday, 16 September, 2013 10:34:55 PM >> Subject: Re: [keycloak-dev] User actions >> >> Hi Stian, >> >> With regards to the "Reset password" flow, will we send the password written >> in the email to the user? How long can the user use this temporary password? >> >> I know that some services do this, but the most common flow that I've seen in >> a quick benchmarking was an email with link that takes the user to a page to >> enter and save the new password (see images below). >> >> I just want to clarify this point before prototyping. >> >> >> Thanks, >> Gabriel >> >> On Sep 11, 2013, at 9:33 AM, Bill Burke wrote: >> >> >> >> >> >> >> On 9/11/2013 8:27 AM, Bill Burke wrote: >> >> >> >> >> >> >> >> >> On 9/11/2013 8:24 AM, Stian Thorgersen wrote: >> >> >> >> >> Unless someone else has already started to work on (or is very interested) I >> plan to work on account workflows. This work includes: >> >> >> >> >> >> >> >> >> >> * Email verification >> >> >> >> >> * Reset password >> >> >> >> >> * Configure TOTP after registration if required by realm >> >> >> >> >> * Marking user as requiring actions before they can login to applications >> >> >> >> >> >> >> >> >> >> I've outlined a proposal on: >> >> >> >> >> >> >> >> >> >> https://github.com/keycloak/keycloak/wiki/User-Actions >> >> >> >> >> >> >> >> >> >> Finally, when an account is in the state of requiring actions (read the above >> wiki page to understand what I'm talking about!) the user should have access >> to the account management pages, but not to applications themselves. I was >> thinking in this case the accessCodeId could be passed as a query parameter, >> which would allow the account management pages to verify that the user is >> logged in, but at the same not enable SSO to applications (as the cookie >> isn't set yet). An alternative I was thinking of was that the >> SkeletonKeyToken could have the status added to it, but I don't like that >> approach as that would require applications to check the status. Any other >> suggestions? >> >> >> >> >> >> >> >> >> >> >> Not sure you need to do that. User has an "enabled" property. If that >> >> >> is not good enough, we could add a enum state variable to it. SSO/OAuth >> >> >> logins would ensure that the user was in the appropriate state and >> >> >> forward to the appropriate pages. It needs to do this anyways. >> >> >> >> >> Sorry, disregard my previous email. I read your blurb too quick. >> >> Yes, you would need to pass along the accessCodeId along to the account >> management pages if an action is required. Another option might be to >> set a session cookie for the accessCode and destroying this cookie when >> the browser is finally redirected back to the application. >> >> The application should not be aware of Keycloak auth server specifics, >> so I don't think adding account state to the SkeletonKeyToken is a good >> idea at the moment. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> Gabriel Cardoso >> GateIn Portal | User Experience Designer >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Gabriel Cardoso GateIn Portal | User Experience Designer _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev