[keycloak-dev] Password Updates and Authenticators in the new Account Console

[Václav Muzikář]

Ok. In this case maybe we could focus at least on minimizing the impact on
the UXD as you mentioned. Would it make sense to have some sort of theme
options for AIAs? This way it could somehow "mimic" the look and feel of
the Account Console. Currently, AIA's use the login theme.

On Tue, Aug 27, 2019 at 2:53 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> AIAs should primarily be used for credentials and just isn't needed for
> everything. They should be considered when extensions is needed, when it
> may be a flow, when rest api and screens are complex. That's credentials
> and social account linking. I just don't see the need for them elsewhere.
>
> Update profile doesn't need to be an AIA, with the exception of update
> email which we may need a better flow for (prove you're the user and also
> verify the new email prior to update).
>
> Device activity is same. You can't add, only remove. API is simple.
>
> On Tue, 27 Aug 2019, 14:46 Václav Muzikář, <vmuzikar at redhat.com> wrote:
>
>> Ok, thank you for the explanation.
>>
>> Obvious question then is – shouldn't we use AIA for everything as Stan
>> suggested? I mean e.g. basic profile updates (first and last name, email,
>> ...) – we already have this as AIA, correct? And I can imagine Device
>> Activity (which is meant to be part of the new Account Console) could be
>> AIA/Required Action too – a Keycloak admin decides users need to verify
>> their device list next time they login. The same for Applications.
>>
>> On Tue, Aug 27, 2019 at 1:18 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Firstly - AIAs are required and necessary so we need to do those
>>> regardless. That means the first version of the account console can and
>>> should leverage those for all actions regardless with updating credentials.
>>> In the future we can discuss extending on it that's fine, but it should be
>>> out of scope for this round. Defining duplicated UIs, REST APIs, testing,
>>> etc. will be additional work that we don't have time to do now regardless.
>>> Just creating a flexible REST API around credential updates will be hard
>>> enough and time consuming.
>>>
>>> With regards to UXD impact of AIAs vs direct actions. As I said before
>>> not all credentials can be updated directly through a REST API, so you
>>> would end up with a mix of some credentials updated directly in account
>>> console and some through AIAs. This is a very minor UXD issue and we are
>>> talking about actions not done regularly by users. We should focus our
>>> energy on improving UXD around AIAs rather than alternative approaches. So
>>> I'd rather see discussions around improving AIA experience.
>>>
>>> With regards to security, there's two issues. First if someone gets a
>>> hold of a bearer token they should not be able to hijack someones account.
>>> If we allow a access token to change credentials it is very easy to
>>> completely hijack an account. Secondly as we're talking about an SSO
>>> solution it's important that an app has only access to what it needs to
>>> have access to. That means no applications should have direct access to
>>> users credentials, which they would need to have to be able to update
>>> through a REST API.
>>>
>>> With regards to custom authenticators. AIAs allow implementing a custom
>>> authenticator with FreeMarker templates and Java code. Without AIAs you
>>> also need to implement React stuff. Worse is that you need to duplicate the
>>> effort on login and testing, which for some authenticators can be quite
>>> complex.
>>>
>>> With regards to flexbility AIAs allows a lot more flexiblity into flows
>>> around updating credentials. This enables us in the future to flexibly
>>> build flows around how credentials are updated. For instance adding a OTP
>>> may mean proving that your are the user by authenticating. Updating
>>> password may require a different way. We will also want to have this
>>> flexible so it can be configured/changed on a per-case basis. For instance
>>> some may want to allow updating password if you can enter the existing
>>> password, some may want to send an SMS with a code, etc.. This is stuff
>>> that the authentication flows need to support, but the account console
>>> doesn't and it will be very time consuming (and duplicating effort) to
>>> allow that in both places.
>>>
>>> Finally, bear in mind that redirects to the auth server really is
>>> expected. We have already today people that want to build their own login
>>> pages in their apps, just because they don't get used to the new way of
>>> doing things, or the UXD/design team has created some wireframes that does
>>> it with an embedded login form.
>>>
>>> On Tue, 27 Aug 2019 at 12:50, Václav Muzikář <vmuzikar at redhat.com>
>>> wrote:
>>>
>>>> Thanks Stian for your reply!
>>>>
>>>> On Tue, Aug 27, 2019 at 11:04 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> We've had this discussion many times already, so not sure why this is
>>>>> coming up again.
>>>>>
>>>>
>>>> I must have somehow missed all of the discussions, I'm sorry for that.
>>>>
>>>> Let me add a few comments below.
>>>>
>>>>
>>>>>
>>>>> On Thu, 22 Aug 2019, 17:40 Václav Muzikář, <vmuzikar at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> 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).
>>>>>>
>>>>>> I disagree - it depends on how it's done. With a SSO solution
>>>>> regardless you are using redirects to login so doing redirects for other
>>>>> account related activities is expected.
>>>>>
>>>>
>>>> Maybe this is just my opinion – I'm no UXD expert (maybe we should ask
>>>> some for their professional opinion) – but I bet I'm not the only one who
>>>> find this a bit clumsy and confusing.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>    - 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.
>>>>>>
>>>>>> Google used this approach a lot. I've also seen it elsewhere.
>>>>>
>>>>
>>>> I'm not sure what you mean by Google used it. Doesn't seem to me like
>>>> that. They allow to change passwords directly inside their "Account
>>>> Console" – see https://youtu.be/H2XteMSN_kU
>>>> Yes, they redirect user to the SSO to reauthenticate them. But this is
>>>> basically what OIDC's promp=login does, it's no way near AIA. User doesn't
>>>> change their password through the login screen.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>    - 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.
>>>>>>
>>>>>> There's very little overhead here. Images and such are already cached.
>>>>>
>>>>>>
>>>>>>    - 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.
>>>>>>
>>>>>> Required actions is for complex actions that would be costly and time
>>>>> consuming to implement in your own apps. Some actions is not possible such
>>>>> as webauthn and some actions such as password updates is not wanted as it
>>>>> provides access to passwords in clear text to other applications. It also
>>>>> opens up for more flexible requirements for some actions such as enter
>>>>> password to update OTP. Verify email to update password. Etc.
>>>>>
>>>>
>>>> I believe that could be up to the developer if they decide to fully
>>>> rely on Keycloak Account Console regarding sensitive data or if they want
>>>> to proxy it through their own account management app (and therefore fully
>>>> and seamlessly integrate it) and use REST API to update it in Keycloak.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>    - 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.
>>>>>>
>>>>>
>>>>> It benefits implementation as well as custom authenticators. It's not
>>>>> even possible to create a rest endpoint for everything such as web authn.
>>>>> It would be very complex with custom flows and authenticators to even do a
>>>>> custom account app. It increases security. Etc. Etc.
>>>>>
>>>>
>>>> Yes, I understand that e.g. configuring web authn is not possible
>>>> directly in the Account Console. But at least managing the authenticators
>>>> (seeing the list of authenticators, removing them, ...) should be possible
>>>> through Account Console (and REST API) no matter how complex is the process
>>>> of adding that authenticator.
>>>>
>>>> Also, isn't the new Account Console designed to be deeply
>>>> extended/modified by developers? Complex flows shouldn't be a problem. Or
>>>> am I wrong?
>>>>
>>>> Maybe a silly question – but how exactly is AIA safer than REST API?
>>>> Are we implying that a REST API secured by Keycloak is insecure?
>>>> Yes, I know that with REST API we potentially give opportunity to 3rd
>>>> party apps to use and exploit it more easier that AIA – but after all
>>>> everything can be exploited. But a REST API especially in combination with
>>>> Keycloak AuthZ services is secured quite enough, isn't it?
>>>>
>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Václav Muzikář
>>>> Senior Quality Engineer
>>>> Keycloak / Red Hat Single Sign-On
>>>> Red Hat Czech s.r.o.
>>>>
>>>
>>
>> --
>> Václav Muzikář
>> Senior Quality Engineer
>> Keycloak / Red Hat Single Sign-On
>> Red Hat Czech s.r.o.
>>
>

-- 
Václav Muzikář
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.