3 a.m.
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(a)redhat.com <stian(a)redhat.com> any thoughts?
On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka(a)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(a)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(a)gmail.com> wrote:
>
> > Ok, thanks for the clarification.
> >
> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger(a)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(a)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(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>