-
Notifications
You must be signed in to change notification settings - Fork 12
Implement account management in Keycloak #42
Comments
The Bad NewsI spent quite a bit of time yesterday researching just how we would do the backend validation for account management. I'm still not certain exactly how we'd do this, but I can say it will be a lot of work. Keycloak's account management screens are a completely different If anyone is interested in the gory details, most of the from these two classes:
My first thought was to just In addition, here are a couple findings on their mailing list that basically confirm what I'm finding:
The Good NewsKeycloak recognizes this is a problem. They have a feature request out a Profile SPI, which sounds like it would it would meet our needs. As to when this become a reality, it is hard to say. The best I can find it the following, posted on a comment of a related issue on 12/02/2016
What's Next?We need to have a deeper discussion around our options, and what issues may arise with each. Sorry this isn't as straightforward as I though it would be. |
It was decided at today's standup that we will hold off on account management. For now, I will just disable account management for all users in the HMDA realm. |
Really glad we didn't take this on. Not only is Keycloak 3.x likely going to include a Profile SPI for consistent account validation, but also New Account Management: Per http://blog.keycloak.org/2016/12/keycloak-250cr1-released.html:
As for when, doesn't sound like they have a timeline yet. All they say is:
|
@hkeeler Before, were you able to override AccountFormService in keycloak's 3.4.3.final version? |
@vanOmega, we do not override Keycloak is supposed to have a big account management refactor in the works. If and when that happens, we'll post details back here on this issue. |
Keycloak comes we a default set of account management screens, all managed under the
account
theme. Like thelogin
theme, we'll need to brand these pages to USWDS standards.In addition, I think we'll need to limit Keycloak's default functionality by quite a bit. They give the user a lot of insight into the system, and I don't think it is necessary. It even exposes the Google Authenticator functionality, which we're not even using.
I was hopeful that much of this could be controlled via built-in roles, but it is not granular enough. Your options are basically:
This will require a bit more research, but I believe the high-level tasks are:
Modify the base template, removing the sidebar with all the links. We should decide what navigation elements we do need here.
Modify the Edit Account screen, allowing only the following fields:
Decide whether we want to keep the Change Password screen. I say this because there is already a Forgot Password? link and Reset password page that's part of the
login
templates.To add a bit of confusion to this mix, their reset flows are different. The
login
version makes you confirm via email, while theaccount
version lets you put in old and new password all at once, and saves right on the spot. I think it would be weird to support both.I favor keeping the current the email confirmation based password reset, and just dumping the
account
version, but I'm open to discussion.Move the Java-based email domain validation logic into it's own library so it can be used in both the
account
andlogin
providers.Enforce the page restrictions on the backend as well. We should make sure user's are not able to browse directly to the pages we've removed the links to.
For your viewing pleasure, here are the default version of the account management screens.
The text was updated successfully, but these errors were encountered: