[keycloak-dev] User actions

Wed Sep 18 19:57:19 EDT 2013

1) Can you please keep the keycloak GIT repo in sync with your 
styles/html?  I sent you a private email on this I believe.

2) I recently had to report a lost authenticator for my World of 
Warcraft account.  Yes, they use password + TOTP :)  I'll send a 
separate email on what options they had for doing this.  Might be 
interesting to discuss.

On 9/18/2013 4:13 PM, Gabriel Cardoso wrote:
> 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 at redhat.com>
>>> To: keycloak-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>> Gabriel Cardoso
>>> GateIn Portal | User Experience Designer
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>
>
> --
> Gabriel Cardoso
> GateIn Portal | User Experience Designer
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com