On 01/12/17 14:53, Bill Burke wrote:
On Wed, Nov 29, 2017 at 9:09 AM, Marek Posolda
<mposolda(a)redhat.com> wrote:
> On 29/11/17 14:44, Stian Thorgersen wrote:
>> I would target this to 3.4.2. I don't want to delay the 3.4.1 release
>> if we can help it.
>>
>> I'd also suggest some (short if possible) random key (or a counter?!)
>> rather than relying on protocol specific values. 'state' is not
>> actually required in OAuth right? It's just recommended.
> Yes, it's not required. And same for SAML. Was wondering about the same.
> Will use the random key or counter. Thinking if counter doesn't have
> some corner case issues (EG. If 2 tabs are opened concurrently after
> logout and will try to use same counter value as authSession update from
> tab2 won't be yet visible in tab1).
>
the "state" parameter IS required. Its how the client can figure out
that it initiated the login or not.
I don't understand your solution...BTW, going back to auth_session_id
within the URL instead of a cookie like we used to do would fix this
too :). If you're already going to add a "client-id" query parameter,
why not just revert back to the old way of doing this?
Yes, it would fix it to add
the ID to the URL. That's the plan.
But at the same time, we also need the cookie as we need sticky session
for cluster and especially for cross-dc. Hence to be able to continue
existing authenticationSession flow, you will need both:
- AUTH_SESSION_ID cookie, which would allow to lookup
"RootAuthenticationSessionModel" from the infinispan cache
- The state in the URL, which would allow to lookup the children
AuthenticationSessionModel within RootAuthenticationSessionModel.
I've added more details in the other mail. Hope not too much :)
Marek
--
Bill Burke
Red Hat