Password Updates and Authenticators in the new Account Console
by Václav Muzikář
Hello,
I wanted to discuss the new Account Console which is in development and how
it handles password updates and authenticators configuration (e.g. TOTP).
Currently, when a user wants to update their password [see attached A.png]
or configure authenticator [B.png] they cannot do it directly from the
Account Console. They need to be redirected back to Keycloak and perform it
there in form of Required Action [C.png, D.png] – which is technically the
login screen (it uses the same template). This also means there will be no
REST endpoints for changing passwords or managing authenticators.
IMHO this is not the best approach either for users or developers (who'll
be using Keycloak with their app). Let me explain why.
- It's not really user friendly. Redirecting from one application to
seemingly completely different application is never good and can be
confusing. I can imagine some less tech savvy users could even feel "in
danger" – one second you're securely managing your account and then you are
asked to change your password in some other application (that suspiciously
uses the same design as login screen).
- This approach doesn't feel seamless. You can change e.g. your name,
email, etc. directly from the Account Console. But not password and
authenticators...
- It's not an industry standard. I haven't ever encountered anywhere
that I'd have to be redirected from some profile managing app to completely
different app just to change password. Again – it's confusing for the users
to do something differently than they're used to and what they expect.
- Network traffic overhead. People accessing the Account Console will
often use some limited and slow internet connection. Needless redirecting
back and forth and loading the application again takes data and time.
- Missing REST endpoints limit developers. With a proper REST API devs
could e.g. fully integrate the Account Console functionality into their own
app (and effectively replacing the Console by their app). This also means
no CLI apps support. And I don't think REST API is less secure than
Required Actions – either way you're sending an HTTP request and how it's
secure depends on the same factors for both.
- We're stripping out core Account Console functionality. It was always
a central place to manage your account. Now it can do what? Change your
email and manage apps access? (We could as well replace it with bunch of
links to Required Actions. :P There're are already Required Actions for
changing email and name.)
I can see however one advantage of this approach. There's only one place
where users can change their passwords and authenticators – no need to
implement it second time when it's already implemented as Required Actions.
But this is actually not entirely true as e.g. password changing process
(incl. password policies etc.) is implemented in Admin Console too so there
needs to be some shared logic.
In general this approach practically benefits "only" the implementation
complexity – it's easier to do it this way and therefore less error prone.
WDYT? Should we keep the current approach?
Thank you!
V.
--
Václav Muzikář
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.
7 years
- 4
- 15
Connecting to an external database for a ProtocolMapper
by Thomas
I need help finding the correct direction of creating a ProtocolMapper that
reads from an external database.
We currently have a Spring microservice application that uses Spring OAuth2
secured services with a Spring OAuth2 server that adds claims to the access
token to implement extra claims for security. The application also reads
the extra claims from the user service database. This database doesn't
store user authentication credentials. User authentication data is in an
enterprise LDAP/AD that is read only. I will never be able to change the
read only LDAP. We would like to get rid of the Spring OAuth2 server.
So far, I've been able to import users into Keycloak from the LDAP and get
every microservice to respond correctly to a request from a valid token
from Keycloak once a login has happened. I've also been able to get a
ProtocolMapper running that adds hard coded claims to the user's access
token.
I would like to use a few custom Spring libraries that we have created for
other services to read data from the User Service Database. The libraries
all ready have implemented a ReadOnly Repository that has custom SQL
types. Particularly, arrays of strings and ints. As well as the Domain
model.
Should I create an EAR that includes the ProtocolMapper as a jar module?
What is the correct way to structure the EAR? Will using my other
libraries that use Spring work?
Thanks,
Thomas
7 years
- 2
- 1