[keycloak-dev] questions on Marek/Hynek presentation

[Bill Burke]

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#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.
>
Not following.  Maybe i need to review the presentation again as maybe 
I'm confused when the "already logged in" screen is shown.

Bill