[keycloak-dev] questions on Marek/Hynek presentation

Bill Burke bburke at redhat.com
Fri May 19 11:40:06 EDT 2017



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


More information about the keycloak-dev mailing list