[keycloak-dev] Cleanup of 'Change password' screen in Account app
Stian Thorgersen
sthorger at redhat.com
Fri Nov 27 10:19:20 EST 2015
I guess at least the re-auth part is logic that belongs in the client that
performs the login.
Question though for authentication levels as well as authentication timeout
(or whatever you call it) shouldn't a rest service be able to say things
like I require the user to have authenticated with password + otp, and to
have authenticated within N minutes?
On 27 November 2015 at 16:13, Bill Burke <bburke at redhat.com> wrote:
> Why would you need re-auth for REST or even browser clients? Doesn't
> access token and refresh token timeouts handle this sort of thing?
>
> On 11/27/2015 7:25 AM, Stian Thorgersen wrote:
> > Hmm.. re-auth request for rest endpoints is even more tricky. I think a
> > rest endpoint would just have to return a 401? Then it's up to the
> > client to figure out that it needs to re-authenticate.
> >
> > On 27 November 2015 at 13:22, Vlastimil Elias <velias at redhat.com
> > <mailto:velias at redhat.com>> wrote:
> >
> >
> >
> > On 27.11.2015 12:28, Stian Thorgersen wrote:
> >>
> >>
> >> On 27 November 2015 at 12:16, Vlastimil Elias
> >> <<mailto:velias at redhat.com>velias at redhat.com
> >> <mailto:velias at redhat.com>> wrote:
> >>
> >> Hi,
> >>
> >> On 27.11.2015 11:45, Stian Thorgersen wrote:
> >>>
> >>>
> >>> On 27 November 2015 at 10:23, Vlastimil Elias
> >>> <<mailto:velias at redhat.com>velias at redhat.com
> >>> <mailto:velias at redhat.com>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have two proposals for cleanup of 'Change password'
> >>> screen in Account
> >>> app based on my experience with it:
> >>>
> >>> 1. remove Cancel button - it has no any meaning on this
> >>> screen/form, it
> >>> only reshowns form with empty fields. And also there is a
> >>> bug,
> >>> "Password" field is hidden when it is used, which makes
> >>> whole form unusable.
> >>>
> >>>
> >>> +1
> >>
> >> OK, I'm going to create JIRA and provide PR for this.
> >>
> >>>
> >>> 2. remove validation of current password (remove
> >>> "Password" field). Two
> >>> reasons for this:
> >>> - security impact of this check is small. If attacker
> >>> is able to
> >>> compromise Account app then he can always change email
> >>> and then use
> >>> "Forgot password" feature to change password
> >>> - user created over Identity Provider do not know old
> >>> password
> >>> (because it is not set) so he is not able to set password
> >>> using this screen
> >>> After we implement support for reauthentication
> >>> (KEYCLOAK-2076) then we
> >>> should set some reasonable reauth timeout for Account app
> >>> instead, this
> >>> will make it more secure at all.
> >>>
> >>>
> >>> -1 Reset password over email may not be enabled at all. We
> >>> already allow setting password for IdPs login without
> >>> requiring the existing password.
> >> Fair enough
> >>>
> >>> +1 To suggestion from Thomas - we should ask for password
> >>> when updating email at least when recover password over email
> >>> is enabled.
> >>
> >> Makes sense, but what to do if user has no password set at
> >> this point? Don't ask him, or reauthenticate him by other
> >> available mechanism?
> >>
> >> And there are also other "dangerous" operations in Account
> >> app. Eg. attacker who gains access to it can disable OTP
> >> without any recheck. This should be protected too.
> >> I believe whole Account app should be correctly protected by
> >> reauthentications. Question is if implement it somehow
> >> specifically in the app, or resolve this generally as part of
> >> KEYCLOAK-2076.
> >>
> >>
> >> Yep, you're right there's other dangerous operations as well.
> >> Re-authentication sounds like the correct approach, rather than
> >> requesting the password again. We could have two configurable
> >> timeouts in account management console. One that requires re-auth
> >> for anything (~30 min default), and another that requires re-auth
> >> for sensitive operations (~5 min).
> >>
> >> One thing with re-auth is that if it happens when a user submits a
> >> form, you then someone have to also remember the values of the
> >> form. Currently account management is stateless.
> >
> > Yep, implementing reauthentication schemes correctly in client apps
> > may be tricky, mainly for POST requests (and even worse posts with
> > file upload) and AJAX call handlers etc.
> > Beside Keycloak Account app we should try to provide reasonable
> > support in Keycloak adapters, but it may be tricky as related Java
> > EE specifications (JAAS subsystems, auth related things in Java
> > Servlet and EJB spec ) do not count with these more complicated
> > schemes too much.
> >
> > And I also thought if reauthentication scheme should be somehow
> > implemented on REST API levels also.
> > Eg. some REST endpoint operation will define that it needs reauth
> > with some timeout. If client app call it with Bearer token then it
> > should be able to tests last auth timestamp (which should be
> > possible as it may be in the token as claim) and propagate back info
> > that it needs reauth (how to map this to HTTP?). Support for this
> > should be added to the framework like RestEasy then.
> >
> > Vl.
> >
> >>
> >>
> >> Vlastimil
> >>
> >>>
> >>> It seems to be common practice to ask for current password
> >>> when updating the existing password.
> >>>
> >>>
> >>> If you agree then I can create JIRA issue for this and
> >>> provide PR.
> >>>
> >>> Vlastimil
> >>>
> >>> --
> >>> Vlastimil Elias
> >>> Principal Software Engineer
> >>> Developer Portal Engineering Team
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> <mailto:keycloak-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>>
> >>
> >> --
> >> Vlastimil Elias
> >> Principal Software Engineer
> >> Developer Portal Engineering Team
> >>
> >>
> >
> > --
> > Vlastimil Elias
> > Principal Software Engineer
> > Developer Portal Engineering Team
> >
> >
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151127/92589e42/attachment-0001.html
More information about the keycloak-dev
mailing list