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

Mauro de Wit maurodewit at gmail.com
Mon Mar 18 04:00:39 EDT 2019


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


More information about the keycloak-dev mailing list