[keycloak-dev] questions on Marek/Hynek presentation
bburke at redhat.com
Fri May 19 11:28:31 EDT 2017
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 , 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.
>>>> * @ 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.
More information about the keycloak-dev