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

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(a)gmail.com&gt; 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(a)redhat.com <stian(a)redhat.com&gt; any thoughts? > > On Fri, 15 Mar 2019 at 15:23, Jared Blashka <jblashka(a)redhat.com&gt; 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&gt; >> 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&gt; >>> wrote: >>> >>> > Ok, thanks for the clarification. >>> > >>> > On Tue, 12 Mar 2019 at 12:39, Stian Thorgersen <sthorger(a)redhat.com&gt; >>> > 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&gt; >>> 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 >>> >>