On 19/05/17 17:53, Marek Posolda wrote:
> On 19/05/17 17:40, Bill Burke wrote:
>>
>>
>> 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#KeyAffinityS...
>>>>>>>
>>>>>>>> * @ 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?
> The authenticationSession doesn't exists. It was already logged-in. Now
> we have single authenticationSession in the browser as it's tracked with
> the cookie. Support for more authentication sessions within browser can
> be done, but will be quite tricky with tracking session by the cookie
> and not sure it worth the effort for the corner cases like this?
Should I go for something like this? We can have more
"client-contexts" in single authentication session. Each
client-context is per browser tab. The state of authenticators,
executions etc is shared, but client-context is unique per browser
tab. So will need to reference client_context with the query
parameter, so authentication session can find correct context based on
this parameter. Also KC_RESTART cookie can be improved to support for
multiple clients, so in every browser tab you will be able to restart
correct authentication session.
I meant "restart correct client-context",
so you will be authenticated
to correct client with correct "state" parameter etc.
This will be another few days of work, but should be fine. I can work
on it together with KEYCLOAK-4016 (adding client_id parameter).
WDYT?
Marek
>
> Previous behaviour had more clientSessions in different browser tabs. So
> login in 2 tabs was possible, but after login in tab2, it created
> another userSession and overwrite the previous userSession including
> cookies etc. This had other issues like mentioned in this JIRA
>
https://issues.jboss.org/browse/KEYCLOAK-4097
>
> Marek
>> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev