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