[keycloak-dev] questions on Marek/Hynek presentation

[Marek Posolda]

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#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.
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" .

- When you continue and click on "Back to application" you are 
automatically logged in in admin console. In case of our admin console, 
it will be better to not show the screen as the client URL 
"http://localhost:8181/auth/admin/master/console/index.html" is secured 
and automatically redirects to Keycloak and starts new flow.

However in other application, which don't have this behaviour (eg. the 
"js-console" example from our examples distribution), then automatically 
redirect to "http://localhost:8181/js-console" will just show you the 
application page, but you won't be authenticated at all, as new flow for 
SSO login won't start. This is what looks like confusing behaviour for 
users IMO.

Marek

>
> Bill