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

[Stan Silvert]

On 8/27/2019 10:17 AM, Václav Muzikář wrote:
> 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.
I think the solution to that is just to make your Login theme match the 
look and feel of your Account theme.  You can do that already.

I wouldn't want the complexity of having a separate AIA 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.
>>>