[keycloak-dev] Keycloak session limiting (KEYCLOAK-849) (BA-93)
Marek Posolda
mposolda at redhat.com
Wed Mar 20 09:59:08 EDT 2019
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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:stian at redhat.com> any
> thoughts?
>
> On Fri, 15 Mar 2019 at 15:23, Jared Blashka
> <jblashka at redhat.com <mailto: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
> <mailto: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
> <mailto:maurodewit at gmail.com>> wrote:
>
> > Ok, thanks for the clarification.
> >
> > On Tue, 12 Mar 2019 at 12:39, Stian
> Thorgersen <sthorger at redhat.com
> <mailto: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
> <mailto: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
> <mailto:keycloak-dev at lists.jboss.org>
> >>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list