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

[Václav Muzikář]

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.