[keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)

[Stian Thorgersen]

I wasn't even aware we had the 'Post Login Flow'.

>From the description I would think that Post Login Flow is being executed
before the user session is created, while there's an authentication
session. So should be fine.

Marek - can you confirm?

On Wed, 20 Mar 2019 at 12:38, Mauro de Wit <maurodewit at gmail.com> wrote:

> Isn't the 'Post login flow' in the IDP configuration the place for this?
> Or do we want to avoid this since this is triggered after authentication is
> complete and the session in created.
> If this is the case, can you point me in the right direction to create a
> hook into the redirect from the external broker?
>
> On Tue, 19 Mar 2019 at 10:59, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> You're right. In fact this should probably be split into two separate
>> authenticators. For realm limits it should be checked as a first part
>> (otherwise you have users authenticating and expensive password hashing
>> when it's already known the session won't be permitted).
>>
>> For regular sessions authenticator works well, but to be honest I
>> completely forgot about brokering. For realm limits it's fine as that
>> authenticator can happen prior to the redirect, but for users there's no
>> hook after the redirected back from the external broker today. There's the
>> first login flow, but that only happens on the first time.
>>
>> On Mon, 18 Mar 2019 at 10:59, Mauro de Wit <maurodewit at gmail.com> wrote:
>>
>>> Ok, I'm missing some fundamental understanding here. Please help :)
>>>
>>> In case of the browser flow, the authentication flow is executed upon
>>> loading a page using the browser. At this time checks are being performed
>>> to see if the user is already logged on. If this is the case, no
>>> authentication has to be performed and the user is presented the requested
>>> page.
>>> But if the user is not yet logged on, the cookie authenticator can't do
>>> anything usefull resulting in the next authenticator to trigger. Eventually
>>> the 'browser forms' authenticator presents a login screen.
>>>
>>> Given the fact that we need to deny the user access in case a session
>>> already exists for his/her account on another machine, we need to know who
>>> this user is. How can we know which user we are dealing with at the start
>>> of the flow?
>>> I can see this working for limiting the number of sessions for each
>>> realm, but not for limiting sessions bound to individual user accounts.
>>>
>>>
>>>
>>> On Mon, 18 Mar 2019 at 09:19, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> The authenticator should be added after the cookie authenticator, not
>>>> at the end. That will make it take affect for IdP logins as well. So it's a
>>>> matter of configuring it in two flows browser and direct grant.
>>>>
>>>> I appreciate it may not be the best usability, but I don't want to
>>>> introduce something special/hard-coded for this feature. A later
>>>> improvement could be to improve on the authentication flows. To have
>>>> different elements in a flow and not just executions as well as potentially
>>>> having some pre-flow checks that are done in all flows. I'd say this
>>>> approach is good enough though at least for now.
>>>>
>>>> On Mon, 18 Mar 2019 at 09:00, Mauro de Wit <maurodewit at gmail.com>
>>>> wrote:
>>>>
>>>>> That is indeed one of the downsides of this approach.
>>>>> But can a misconfiguration of this functionality do any harm, besides
>>>>> some inconsistent behavior between authentication methods?
>>>>>
>>>>> @stian at redhat.com <stian at redhat.com> any thoughts?
>>>>>
>>>>> On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> If this is done via an authenticator wouldn't you have to make sure
>>>>>> that this authenticator is present (and all the same settings are
>>>>>> maintained) in the browser flow as well as the direct access flow as well
>>>>>> as the login flows for all configured identity providers? It seems like it
>>>>>> would be quite easy to make a mistake in that process and misconfigure
>>>>>> something somewhere.
>>>>>>
>>>>>> On Fri, Mar 15, 2019 at 5:41 AM Mauro de Wit <maurodewit at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I've started to create a simple proof of concept and want to check
>>>>>>> if I
>>>>>>> have my facts straight.
>>>>>>> As previously discussed this functionality should be provided by a
>>>>>>> custom
>>>>>>> Authenticator that is configured in an authentication flow.
>>>>>>>
>>>>>>> What I've done so far is:
>>>>>>> - Created implementations for both the Authenticator and
>>>>>>> AuthenticatorFactory interfaces.
>>>>>>> - Added a set of ProviderConfigProperty instances that allow the
>>>>>>> desired
>>>>>>> configuration.
>>>>>>> - Perform the check if any session limits are exceeded inside the
>>>>>>> authenticate() method of the Authenticator class. (Any session
>>>>>>> invalidation
>>>>>>> will be performed here as well)
>>>>>>>
>>>>>>> Now, in order to use session limiting for regular username/password
>>>>>>> form
>>>>>>> logins, I have created a copy of the 'browser flow' and added this
>>>>>>> Authenticator as a 'required' execution at the end of the flow.
>>>>>>> In our case we allow IDP logins as well. And to use this
>>>>>>> functionality for
>>>>>>> these logins, I've created a new authentication flow containing just
>>>>>>> this
>>>>>>> Authenticator. Finally this flow is selected in the 'Post login
>>>>>>> flow' of
>>>>>>> the IDP configuration.
>>>>>>> For both scenarios the Authenticator seems to be triggered at the
>>>>>>> right
>>>>>>> time and I should be able to apply the session limiting rules.
>>>>>>>
>>>>>>> Any thoughts or comments so far?
>>>>>>>
>>>>>>> On Tue, 12 Mar 2019 at 14:53, Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Ok, thanks for the clarification.
>>>>>>> >
>>>>>>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <
>>>>>>> sthorger at redhat.com>
>>>>>>> > wrote:
>>>>>>> >
>>>>>>> >> It should be a pluggable part of the authentication flow and not a
>>>>>>> >> hardcoded element. There is no other way to plug in to the
>>>>>>> authentication
>>>>>>> >> flow other than creating an authenticator. An authenticator
>>>>>>> doesn't need to
>>>>>>> >> provide a challenge though so it can be used in this instance.
>>>>>>> >>
>>>>>>> >> On Tue, 12 Mar 2019 at 10:57, Mauro de Wit <maurodewit at gmail.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >>> Hello,
>>>>>>> >>>
>>>>>>> >>> I am sending this e-mail because I have some questions regarding
>>>>>>> the
>>>>>>> >>> enhancement request that enables configurable session limiting in
>>>>>>> >>> Keycloak
>>>>>>> >>> as discussed here:
>>>>>>> >>> https://issues.jboss.org/browse/KEYCLOAK-849 (The developer
>>>>>>> that Marc
>>>>>>> >>> Wijma
>>>>>>> >>> referred to in his comment as being available for this task is
>>>>>>> me btw :))
>>>>>>> >>>
>>>>>>> >>> In the comments a solution is proposed that makes use of a custom
>>>>>>> >>> Authenticator that is dropped into the authentication flow where
>>>>>>> it can
>>>>>>> >>> be
>>>>>>> >>> configured. While I can see the benefit of leveraging the
>>>>>>> existing
>>>>>>> >>> components as much as possible (including the configuration
>>>>>>> options in
>>>>>>> >>> that
>>>>>>> >>> flow), I am wondering if this is the best solution. As far as I
>>>>>>> can tell,
>>>>>>> >>> this component is not performing any authentication at all.
>>>>>>> Moreover this
>>>>>>> >>> functionality operates 'above' the authentication mechanisms and
>>>>>>> should
>>>>>>> >>> apply to all of them.
>>>>>>> >>> So is an Authenticator really the desired place to implement
>>>>>>> this? Or is
>>>>>>> >>> this just the quickest route, while not being the most desirable
>>>>>>> option
>>>>>>> >>> for
>>>>>>> >>> the long term? What would be an alternative approach be? That
>>>>>>> would place
>>>>>>> >>> this implementation and configuration in the existing Session
>>>>>>> >>> configuration
>>>>>>> >>> code for instance.
>>>>>>> >>>
>>>>>>> >>> I just now started investigating this task and looking into the
>>>>>>> options
>>>>>>> >>> that would meet our requirements. Hope to hear from you.
>>>>>>> >>>
>>>>>>> >>> Regards
>>>>>>> >>>
>>>>>>> >>> Mauro
>>>>>>> >>>
>>>>>>> >>> >
>>>>>>> >>> _______________________________________________
>>>>>>> >>> keycloak-dev mailing list
>>>>>>> >>> keycloak-dev at lists.jboss.org
>>>>>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> >>>
>>>>>>> >>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>