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

Wed Mar 20 10:00:07 EDT 2019

Makes sense. Thanks for the input guys.
I'm on the right track then :)

On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda at redhat.com> wrote:

> On 20/03/2019 12:50, Stian Thorgersen wrote:
>
> 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?
>
> Yes, exactly. User session doesn't yet exists when "Post Login Flow" is
> executed. This flow exists exactly because of use-cases like this - having
> the ability to execute the hooks after broker authentication. For example
> some people wanted to execute TOTP after the authentication with "facebook"
> broker etc.
>
> Marek
>
>
> 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
>>>>>>>>
>>>>>>>
>