[keycloak-dev] questions on Marek/Hynek presentation

[Marek Posolda]

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#KeyAffinityService
>>> * @ 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.

Marek
>
> Bill