[keycloak-dev] Cross-DC and codeToToken request

[Stian Thorgersen]

On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
> > On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
> >
> >> Followup on some previous emails I sent this week around sticky sessions
> >> and OIDC backchannel requests.
> >>
> >> In shortcut, it would be ideal if we can achieve that backchannel
> >> requests (code-to-token, refresh token, logouts etc) can participate in
> >> same sticky session like the browser request. It may be possible in some
> >> cases (our adapters, some loadbalancers, see previous email I sent this
> >> week) but not everytime. And looks we would need to support the case
> >> when it's not possible.
> >>
> >> I can start with code-to-token request as it's slightly more complicated
> >> then the others due to the reasons:
> >>
> >> 1) code must be single-use per OAuth2 / OIDC specification
> >>
> >> 2) userSession may not yet be available. In case that we use ASYNC
> >> channel for communication between datacenters for transfer userSession
> >> (which I think should be the default due to performance reasons), then
> >> this example flow can happen:
> >> - user successfully authenticated and userSession was created on DC1.
> >> - code-to-token request is sent by the adapter to DC2. Note that this
> >> request is usually sent very quickly after userSession is created.
> >> - DC2 didn't yet received the message from DC1 about the new
> >> userSession. So this userSession not yet available here.
> >>
> >> Questions:
> >> 1) Could we remove a need from code-to-token endpoint to lookup
> >> userSession? I see this as an option as long as code itself is JWT
> >> signed with realm HMAC key encapsulating some info about user,
> >> session_state etc. Among other things, this would require some
> >> refactoring of protocolMappers (as userSession won't be available when
> >> tokens are generated). But isn't it bad for security to have some claims
> >> directly to the code? It is query parameter, which may end visible in
> >> browser history. IMO this is not big issue, but not 100% sure..
> >>
> > Wouldn't the code also become rather big?
> >
> > I reckon protocol mappers should be refactored regardless though. The
> > details should be in the code and token not in the user session.
>
> For protocol mappers, the reason why the user session need to be
> available is that some component might be storing temporary information
> within the session that needs to be mapped to the token.  Any example is
> a broker login that doesn't want or need to import into database, but
> instead stores in in the session.  Doesn't kerberos store stuff in the
> session that can be mapped to the token?  Finally, eventually we will
> want import-less brokering where the user is created within the session
> and destroyed with the session so we dont' have to hit the DB and import.
>

True, so we basically will need to make sure the user session exists and is
persisted. I reckon on-demand replication if technically possible the best
option.


>
> >
> >> 2) Another option is let the code-to-token endpoint wait until
> >> userSession is available. Then we would need support for asynchronous
> >> requests? I can see blocking undertow workers in waiting (something
> >> based on java.util.concurrent.Future) can be an issue and potential for
> >> DoS? Still even with asynchronous, the request times can be quite long.
> >>
> > I like this option. Could we combine this with on demand replication?
> With
> > a configurable timeout this would be nifty IMO.
>
>
>
> >
> >
> >> 3) Can we encourage people to use sticky sessions at least for
> >> code-to-token endpoint? We can add the route directly to the code
> >> itself, so the URL will look like:
> >> http://apphost/app?code=123.node1&state=456 . Many loadbalancers seem
> to
> >> support sticky session based on URL part. But there is also
> >> response_mode=form_post when the code won't be available in the URI.
> >
> > May work for some, but I doubt it'll work for everyone.
>
> imo, this is something that should be added to the spec.  That the code
> contains the callback URI.
>
> >
> >
> >> 4) Is it ok to have option to relax on code one-time use? Otherwise in
> >> cross-DC and without sticky session, the every code exchange may require
> >> SYNC request to another DCs to doublecheck code was not used already.
> >> Not good for performance..
> >>
> > Maybe this is OK. Confidential apps needs credentials and then
> > there's Proof Key for Code Exchange for public clients. Although the
> latter
> > may be another issue in cross-DC?
> >
> >
> >> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> >> Marek
>
> I think 1 and 4 will hobble us for future things we want to do.
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>