Re: [keycloak-dev] User actions

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Thursday, 19 September, 2013 4:33:49 AM Subject: Re: [keycloak-dev] User actions Should these emails be text rather than pretty HTML? On 9/16/2013 5:34 PM, Gabriel Cardoso wrote: > 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 > -- 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