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 >

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

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

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(a)redhat.com&gt; 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(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 >>>> >>>

From the description I would think that Post Login Flow is being executed

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(a)redhat.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; >> 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(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 >>>>>> >>>>>

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(a)gmail.com&gt; 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(a)redhat.com&gt; > 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(a)gmail.com&gt; 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(a)redhat.com&gt; >>> 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(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 >>>>>>> >>>>>>

Ok, I've found some time to continue on the session limiting task. I've created a fork of the Keycloak repository from which I eventually will make a PR. But first I need to finalize my work (Still need to add event logging). Currently I am in the process of creating Integration tests for this mechanism and have it partly working. But I'm having trouble creating multiple sessions from a single test. Browsing through the existing tests I've not found any example how this is done. Can anyone point me to an existing example or provide me with information howto initiate multiple sessions? Here are the tests I've written: https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-sessio... Specifically, the UserSessionLimitsTest is requiring me to login multiple times. The RealmSessionTest is already working correctly as far as I can tell. Any help would be appreciated. On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit(a)gmail.com <mailto:maurodewit@gmail.com>> wrote: Makes sense. Thanks for the input guys. I'm on the right track then :) On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: 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(a)gmail.com <mailto:maurodewit@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(a)redhat.com <mailto:sthorger@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(a)gmail.com <mailto:maurodewit@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(a)redhat.com > <mailto:sthorger@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(a)gmail.com > <mailto:maurodewit@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(a)redhat.com > <mailto:stian@redhat.com> any thoughts? > > On Fri, 15 Mar 2019 at 15:23, Jared > Blashka <jblashka(a)redhat.com > <mailto:jblashka@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 > <mailto:maurodewit@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 > <mailto:maurodewit@gmail.com>> wrote: > > > Ok, thanks for the clarification. > > > > On Tue, 12 Mar 2019 at 12:39, > Stian Thorgersen > <sthorger(a)redhat.com > <mailto:sthorger@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 > <mailto:maurodewit@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 > <mailto:keycloak-dev@lists.jboss.org> > >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

Unfortunately this doesn't work. Deleting the cookies works, but still no new session is created. Had to navigate to the login page again though to delete the cookies, otherwise the URL didn't match and no cookies were deleted. Will give it a try now using the JAX RS or Oauth client now. On Mon, 1 Apr 2019 at 13:22, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > Maybe easiest is to login and then call : > > driver.manage().deleteAllCookies(); > > This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on > server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration. > > Marek > > On 01/04/2019 11:59, Mauro de Wit wrote: > > Ok, I've found some time to continue on the session limiting task. I've > created a fork of the Keycloak repository from which I eventually will make > a PR. But first I need to finalize my work (Still need to add event > logging). > Currently I am in the process of creating Integration tests for this > mechanism and have it partly working. > > But I'm having trouble creating multiple sessions from a single test. > Browsing through the existing tests I've not found any example how this is > done. > Can anyone point me to an existing example or provide me with information > howto initiate multiple sessions? > > Here are the tests I've written: > > https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-sessio... > > Specifically, the UserSessionLimitsTest is requiring me to login multiple > times. The RealmSessionTest is already working correctly as far as I can > tell. > Any help would be appreciated. > > > > > > > > On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit(a)gmail.com&gt; wrote: > >> Makes sense. Thanks for the input guys. >> I'm on the right track then :) >> >> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> >>> 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(a)gmail.com&gt; >>> 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(a)redhat.com&gt; >>>> 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(a)gmail.com&gt; >>>>> 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(a)redhat.com&gt; >>>>>> 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(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 >>>>>>>>>> >>>>>>>>> >>> >

Oauth client uses the direct grant flow though. We'll need tests for both flows. Deleting cookies should work, you may also be able to use a new webdriver instance with custom/different cookie store to allow controlling it On Tue, 2 Apr 2019, 10:31 Mauro de Wit, <maurodewit(a)gmail.com&gt; wrote: > Using the Oauth client to create mutliple sessions works :) > based my code on org.keycloak.testsuite.oauth.LogoutTest and this is > exactly what I need! > > On Tue, 2 Apr 2019 at 11:15, Mauro de Wit <maurodewit(a)gmail.com&gt; wrote: > >> Unfortunately this doesn't work. Deleting the cookies works, but still >> no new session is created. Had to navigate to the login page again though >> to delete the cookies, otherwise the URL didn't match and no cookies were >> deleted. >> Will give it a try now using the JAX RS or Oauth client now. >> >> On Mon, 1 Apr 2019 at 13:22, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> >>> Maybe easiest is to login and then call : >>> >>> driver.manage().deleteAllCookies(); >>> >>> This will delete all cookies, so you can login again within same browser (web driver) and the previous session is still valid (cookies were manually removed from browser, but session is still alive on >>> server-side as you did not logout). See for example LoginTest.loginExpiredCodeAndExpiredCookies() for some inspiration. >>> >>> Marek >>> >>> On 01/04/2019 11:59, Mauro de Wit wrote: >>> >>> Ok, I've found some time to continue on the session limiting task. I've >>> created a fork of the Keycloak repository from which I eventually will make >>> a PR. But first I need to finalize my work (Still need to add event >>> logging). >>> Currently I am in the process of creating Integration tests for this >>> mechanism and have it partly working. >>> >>> But I'm having trouble creating multiple sessions from a single test. >>> Browsing through the existing tests I've not found any example how this is >>> done. >>> Can anyone point me to an existing example or provide me with >>> information howto initiate multiple sessions? >>> >>> Here are the tests I've written: >>> >>> https://github.com/mfdewit/keycloak/tree/KEYCLOAK-849-configurable-sessio... >>> >>> Specifically, the UserSessionLimitsTest is requiring me to login >>> multiple times. The RealmSessionTest is already working correctly as far as >>> I can tell. >>> Any help would be appreciated. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, 20 Mar 2019 at 15:00, Mauro de Wit <maurodewit(a)gmail.com&gt; >>> wrote: >>> >>>> Makes sense. Thanks for the input guys. >>>> I'm on the right track then :) >>>> >>>> On Wed, 20 Mar 2019 at 14:59, Marek Posolda <mposolda(a)redhat.com&gt; >>>> wrote: >>>> >>>>> 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(a)gmail.com&gt; >>>>> 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(a)redhat.com&gt; >>>>>> 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(a)gmail.com&gt; >>>>>>> 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(a)redhat.com&gt; 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(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 >>>>>>>>>>>> >>>>>>>>>>> >>>>> >>>