* Won't the regular case be that the load balancer generates the affinity cookie or doesn't have a cookie at all? HA-Proxy is quite popular and they have both options.

* @ 18:25 in bluejeans session, The "You are already logged in" screen. What happens when the use clicks "proceed"? Does the SAML or OIDC request continue as normal? Or are you calculating the URI on the application to redirect to, if so, why?

On Action Tokens: * What is the relationship between the RequiredAction SPI and ActionTokenHandler SPI? Does every RequiredAction have to have a corresponding ActionTokenHandler? * Why would a app developer need to implement an ActionTokenHandler? Wouldn't it be better for the Required Action SPI to provide the appropriate metadata so that the handler could be implemented by us? i.e. isOneTimeToken, email-template, etc, etc. I guess what I'm saying is that action tokens should be incorporated into the RequiredAction SPI. * Related to above. Required actions should be able to specify an "admin console template" and "login template". These would be the freemarker template to use to create the email that is sent to the user. "admin console" would be from an admin generating the action. "login" would be when user login initiates the action email. * On the Admin Console "Credential Reset" section. Required Action emails (now Action tokens) aren't necessarily "Credential Resets". Verify email is not a credential reset. etc. This need to be renamed and maybe put in another tab? * We will need a way to offload action processing to another external service. keycloak exists to mark that the action was completed, but all the processing for the action happens in an external application. A lot of people have existing applications they want to integrate with that perform action processing. Just something to think about. We need this for other areas of keycloak (i.e. registration). _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 5/19/17 10:57 AM, Marek Posolda wrote: > On 19/05/17 16:19, Bill Burke wrote: >> * Won't the regular case be that the load balancer generates the >> affinity cookie or doesn't have a cookie at all? HA-Proxy is quite >> popular and they have both options. > Yes, that's also what Sebastien Schuster from community mentioned in > other thread. That's why I've added StickySessionEncoderProvider as > SPI, so it's easily possible to disable Keycloak adding route to the > cookie, or sticky request based on something different than cookie > (eg. path parameter). > > However having Keycloak itself to choose the route has one big > performance advantage, that it can route to the node, who is owner of > the entry in the infinispan distributed cache. This includes also > support for rebalance (owner may change when new node joins/leaves > cluster, then you change route automatically). This is what Wildfly > is doing for Http sessions too. > > We discussed the integration with KeyAffinityService [1], which helps > with usecase when loadbalancer generates route to the cookie. It > ensures that generated session ID will be local to current node. > Hence loadbalancer can use request node as the route and session will > be local to it. But this doesn't handle rebalance, so IMO preferred > option is still to let Keycloak to append route. > > There is also infinispan grouping API I want to look at. > > [1] > http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityS... >> * @ 18:25 in bluejeans session, The "You are already logged in" screen. >> What happens when the use clicks "proceed"? Does the SAML or OIDC >> request continue as normal? Or are you calculating the URI on the >> application to redirect to, if so, why? > No, this is just link to client base URI, and then new flow can be > started from the application. ATM authenticationSession may be > already removed as user logged already in different browser tab etc, > so there is no flow to continue with. > > Currently there is just userSession available and the client > application used for "Back to application" is the last authenticated > client in userSession. I am going to improve it and use "client_id" > parameter in requests, so in case of expired session, already > authentication session etc, you would always know the client from the > "client_id" parameter. Details in the other ML thread "Provide a Link > to go Back to The Application on a Timeout" . > Why do you need this page? Why can't you just proceed with the OIDC/SAML protocol?

Bill

On 5/19/17 11:25 AM, Marek Posolda wrote: > On 19/05/17 16:58, Bill Burke wrote: >> >> >> >> On 5/19/17 10:57 AM, Marek Posolda wrote: >>> On 19/05/17 16:19, Bill Burke wrote: >>>> * Won't the regular case be that the load balancer generates the >>>> affinity cookie or doesn't have a cookie at all? HA-Proxy is quite >>>> popular and they have both options. >>> Yes, that's also what Sebastien Schuster from community mentioned >>> in other thread. That's why I've added StickySessionEncoderProvider >>> as SPI, so it's easily possible to disable Keycloak adding route to >>> the cookie, or sticky request based on something different than >>> cookie (eg. path parameter). >>> >>> However having Keycloak itself to choose the route has one big >>> performance advantage, that it can route to the node, who is owner >>> of the entry in the infinispan distributed cache. This includes >>> also support for rebalance (owner may change when new node >>> joins/leaves cluster, then you change route automatically). This is >>> what Wildfly is doing for Http sessions too. >>> >>> We discussed the integration with KeyAffinityService [1], which >>> helps with usecase when loadbalancer generates route to the cookie. >>> It ensures that generated session ID will be local to current node. >>> Hence loadbalancer can use request node as the route and session >>> will be local to it. But this doesn't handle rebalance, so IMO >>> preferred option is still to let Keycloak to append route. >>> >>> There is also infinispan grouping API I want to look at. >>> >>> [1] >>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityS... >>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen. >>>> What happens when the use clicks "proceed"? Does the SAML or OIDC >>>> request continue as normal? Or are you calculating the URI on the >>>> application to redirect to, if so, why? >>> No, this is just link to client base URI, and then new flow can be >>> started from the application. ATM authenticationSession may be >>> already removed as user logged already in different browser tab >>> etc, so there is no flow to continue with. >>> >>> Currently there is just userSession available and the client >>> application used for "Back to application" is the last >>> authenticated client in userSession. I am going to improve it and >>> use "client_id" parameter in requests, so in case of expired >>> session, already authentication session etc, you would always know >>> the client from the "client_id" parameter. Details in the other ML >>> thread "Provide a Link to go Back to The Application on a Timeout" . >>> >> >> Why do you need this page? Why can't you just proceed with the >> OIDC/SAML protocol? > You mean redirect automatically to the client, which will start new > OIDC/SAML flow and then authenticate you automatically due to SSO? > > Yes, in cases like our admin console, it will be better behaviour > then showing "You are already logged in" . But that's just because > client base URI, (or client redirect URI) are secured URLs and > automatically redirects to Keycloak and starts the flow. > > But in many applications, this is not the case. For example, you have > single page JS application on "http://host/js-app", which is itself > not secured URL. So after confirm the expired username/password form, > you would redirect to the "http://host/js-app", but you won't be > authenticated there. This looks like quite confusing behaviour for > the user IMO. > > Showing "You are already logged in" looks like good compromise. In > many cases it is just additional splash screen, but at least it don't > confuse users in case that client redirect URI are not secured URLs. > Not following. Maybe i need to review the presentation again as maybe I'm confused when the "already logged in" screen is shown.

Bill

On 5/19/17 11:36 AM, Marek Posolda wrote: > On 19/05/17 17:28, Bill Burke wrote: >> >> >> >> On 5/19/17 11:25 AM, Marek Posolda wrote: >>> On 19/05/17 16:58, Bill Burke wrote: >>>> >>>> >>>> >>>> On 5/19/17 10:57 AM, Marek Posolda wrote: >>>>> On 19/05/17 16:19, Bill Burke wrote: >>>>>> * Won't the regular case be that the load balancer generates the >>>>>> affinity cookie or doesn't have a cookie at all? HA-Proxy is quite >>>>>> popular and they have both options. >>>>> Yes, that's also what Sebastien Schuster from community mentioned >>>>> in other thread. That's why I've added >>>>> StickySessionEncoderProvider as SPI, so it's easily possible to >>>>> disable Keycloak adding route to the cookie, or sticky request >>>>> based on something different than cookie (eg. path parameter). >>>>> >>>>> However having Keycloak itself to choose the route has one big >>>>> performance advantage, that it can route to the node, who is >>>>> owner of the entry in the infinispan distributed cache. This >>>>> includes also support for rebalance (owner may change when new >>>>> node joins/leaves cluster, then you change route automatically). >>>>> This is what Wildfly is doing for Http sessions too. >>>>> >>>>> We discussed the integration with KeyAffinityService [1], which >>>>> helps with usecase when loadbalancer generates route to the >>>>> cookie. It ensures that generated session ID will be local to >>>>> current node. Hence loadbalancer can use request node as the >>>>> route and session will be local to it. But this doesn't handle >>>>> rebalance, so IMO preferred option is still to let Keycloak to >>>>> append route. >>>>> >>>>> There is also infinispan grouping API I want to look at. >>>>> >>>>> [1] >>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityS... >>>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen. >>>>>> What happens when the use clicks "proceed"? Does the SAML or OIDC >>>>>> request continue as normal? Or are you calculating the URI on the >>>>>> application to redirect to, if so, why? >>>>> No, this is just link to client base URI, and then new flow can >>>>> be started from the application. ATM authenticationSession may be >>>>> already removed as user logged already in different browser tab >>>>> etc, so there is no flow to continue with. >>>>> >>>>> Currently there is just userSession available and the client >>>>> application used for "Back to application" is the last >>>>> authenticated client in userSession. I am going to improve it and >>>>> use "client_id" parameter in requests, so in case of expired >>>>> session, already authentication session etc, you would always >>>>> know the client from the "client_id" parameter. Details in the >>>>> other ML thread "Provide a Link to go Back to The Application on >>>>> a Timeout" . >>>>> >>>> >>>> Why do you need this page? Why can't you just proceed with the >>>> OIDC/SAML protocol? >>> You mean redirect automatically to the client, which will start new >>> OIDC/SAML flow and then authenticate you automatically due to SSO? >>> >>> Yes, in cases like our admin console, it will be better behaviour >>> then showing "You are already logged in" . But that's just because >>> client base URI, (or client redirect URI) are secured URLs and >>> automatically redirects to Keycloak and starts the flow. >>> >>> But in many applications, this is not the case. For example, you >>> have single page JS application on "http://host/js-app", which is >>> itself not secured URL. So after confirm the expired >>> username/password form, you would redirect to the >>> "http://host/js-app", but you won't be authenticated there. This >>> looks like quite confusing behaviour for the user IMO. >>> >>> Showing "You are already logged in" looks like good compromise. In >>> many cases it is just additional splash screen, but at least it >>> don't confuse users in case that client redirect URI are not >>> secured URLs. >>> >> Not following. Maybe i need to review the presentation again as >> maybe I'm confused when the "already logged in" screen is shown. > Easy to reproduce: > - Go to "http://localhost:8181/auth/admin" in browser tab 1 > - Open tab 2 and go again to "http://localhost:8181/auth/admin" here > - Finish login as admin/admin in tab 2. You are logged in admin console > - Go back to tab 1 and try to login as admin/admin again. Now it's > displayed "You are already logged in" . > Why does this happen? Why can't Keycloak just finish the OIDC protocol? Is it because you don't want to ignore the username/password screen?

Bill

On 19/05/17 17:53, Marek Posolda wrote: > On 19/05/17 17:40, Bill Burke wrote: >> >> >> On 5/19/17 11:36 AM, Marek Posolda wrote: >>> On 19/05/17 17:28, Bill Burke wrote: >>>> >>>> >>>> On 5/19/17 11:25 AM, Marek Posolda wrote: >>>>> On 19/05/17 16:58, Bill Burke wrote: >>>>>> >>>>>> >>>>>> On 5/19/17 10:57 AM, Marek Posolda wrote: >>>>>>> On 19/05/17 16:19, Bill Burke wrote: >>>>>>>> * Won't the regular case be that the load balancer generates the >>>>>>>> affinity cookie or doesn't have a cookie at all? HA-Proxy is >>>>>>>> quite >>>>>>>> popular and they have both options. >>>>>>> Yes, that's also what Sebastien Schuster from community mentioned >>>>>>> in other thread. That's why I've added >>>>>>> StickySessionEncoderProvider as SPI, so it's easily possible to >>>>>>> disable Keycloak adding route to the cookie, or sticky request >>>>>>> based on something different than cookie (eg. path parameter). >>>>>>> >>>>>>> However having Keycloak itself to choose the route has one big >>>>>>> performance advantage, that it can route to the node, who is >>>>>>> owner of the entry in the infinispan distributed cache. This >>>>>>> includes also support for rebalance (owner may change when new >>>>>>> node joins/leaves cluster, then you change route automatically). >>>>>>> This is what Wildfly is doing for Http sessions too. >>>>>>> >>>>>>> We discussed the integration with KeyAffinityService [1], which >>>>>>> helps with usecase when loadbalancer generates route to the >>>>>>> cookie. It ensures that generated session ID will be local to >>>>>>> current node. Hence loadbalancer can use request node as the >>>>>>> route and session will be local to it. But this doesn't handle >>>>>>> rebalance, so IMO preferred option is still to let Keycloak to >>>>>>> append route. >>>>>>> >>>>>>> There is also infinispan grouping API I want to look at. >>>>>>> >>>>>>> [1] >>>>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityS... >>>>>>> >>>>>>>> * @ 18:25 in bluejeans session, The "You are already logged >>>>>>>> in" screen. >>>>>>>> What happens when the use clicks "proceed"? Does the SAML or >>>>>>>> OIDC >>>>>>>> request continue as normal? Or are you calculating the URI on the >>>>>>>> application to redirect to, if so, why? >>>>>>> No, this is just link to client base URI, and then new flow can >>>>>>> be started from the application. ATM authenticationSession may be >>>>>>> already removed as user logged already in different browser tab >>>>>>> etc, so there is no flow to continue with. >>>>>>> >>>>>>> Currently there is just userSession available and the client >>>>>>> application used for "Back to application" is the last >>>>>>> authenticated client in userSession. I am going to improve it and >>>>>>> use "client_id" parameter in requests, so in case of expired >>>>>>> session, already authentication session etc, you would always >>>>>>> know the client from the "client_id" parameter. Details in the >>>>>>> other ML thread "Provide a Link to go Back to The Application on >>>>>>> a Timeout" . >>>>>>> >>>>>> Why do you need this page? Why can't you just proceed with the >>>>>> OIDC/SAML protocol? >>>>> You mean redirect automatically to the client, which will start new >>>>> OIDC/SAML flow and then authenticate you automatically due to SSO? >>>>> >>>>> Yes, in cases like our admin console, it will be better behaviour >>>>> then showing "You are already logged in" . But that's just because >>>>> client base URI, (or client redirect URI) are secured URLs and >>>>> automatically redirects to Keycloak and starts the flow. >>>>> >>>>> But in many applications, this is not the case. For example, you >>>>> have single page JS application on "http://host/js-app", which is >>>>> itself not secured URL. So after confirm the expired >>>>> username/password form, you would redirect to the >>>>> "http://host/js-app", but you won't be authenticated there. This >>>>> looks like quite confusing behaviour for the user IMO. >>>>> >>>>> Showing "You are already logged in" looks like good compromise. In >>>>> many cases it is just additional splash screen, but at least it >>>>> don't confuse users in case that client redirect URI are not >>>>> secured URLs. >>>>> >>>> Not following. Maybe i need to review the presentation again as >>>> maybe I'm confused when the "already logged in" screen is shown. >>> Easy to reproduce: >>> - Go to "http://localhost:8181/auth/admin" in browser tab 1 >>> - Open tab 2 and go again to "http://localhost:8181/auth/admin" here >>> - Finish login as admin/admin in tab 2. You are logged in admin >>> console >>> - Go back to tab 1 and try to login as admin/admin again. Now it's >>> displayed "You are already logged in" . >>> >> Why does this happen? Why can't Keycloak just finish the OIDC >> protocol? Is it because you don't want to ignore the >> username/password screen? > The authenticationSession doesn't exists. It was already logged-in. Now > we have single authenticationSession in the browser as it's tracked with > the cookie. Support for more authentication sessions within browser can > be done, but will be quite tricky with tracking session by the cookie > and not sure it worth the effort for the corner cases like this? Should I go for something like this? We can have more "client-contexts" in single authentication session. Each client-context is per browser tab. The state of authenticators, executions etc is shared, but client-context is unique per browser tab. So will need to reference client_context with the query parameter, so authentication session can find correct context based on this parameter. Also KC_RESTART cookie can be improved to support for multiple clients, so in every browser tab you will be able to restart correct authentication session.

This will be another few days of work, but should be fine. I can work on it together with KEYCLOAK-4016 (adding client_id parameter). WDYT? Marek > > Previous behaviour had more clientSessions in different browser tabs. So > login in 2 tabs was possible, but after login in tab2, it created > another userSession and overwrite the previous userSession including > cookies etc. This had other issues like mentioned in this JIRA > https://issues.jboss.org/browse/KEYCLOAK-4097 > > Marek >> Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev