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

[Stian Thorgersen]

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
>>>
>>