[keycloak-dev] Cross-DC and codeToToken request

Wed May 24 02:38:23 EDT 2017

The spec does not mention redirects on the token endpoint, it might cause troubles because the token issuer does not match the DC-specific DNS name anymore and some people argue introducing DNS-specific names is a bad idea because people might start using them directly defeating the original purpose of cross-DC. There's also the issue of library not following redirects Marek and Stian mentioned. I could imagine server-to-server forwarding being easier to implement (although it also required DC-specific names) but performance-wise it is probably inferior to just requesting the session data from the other DC and answering yourself.

Mit freundlichen Grüßen / Best regards

 Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn 

> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Dienstag, 23. Mai 2017 17:34
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> stian at redhat.com
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> 
> What about redirection?  client makes code-to-token request and possibly gets a
> 302 and Location header back as response.  Is that better or worse than server-to-
> server request forwarding?
> 
> 
> On 5/23/17 9:36 AM, Schuster Sebastian (INST/ESY1) wrote:
> > As long as it is not user claims or other sensitive stuff, I am fine. Is the idea then
> to perform a redirect to another DC (with a DC-specific DNS name, not sure
> redirects on token endpoint are covered by the spec) or to have the load balancer
> of one DC forward directly to another DC (also not sure this is a common
> approach)?
> >
> > Mit freundlichen Grüßen / Best regards
> >
> >   Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
> > Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
> > 30 726112-100 | Sebastian.Schuster at bosch-si.com
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
> > B
> > Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Bill Burke [mailto:bburke at redhat.com]
> >> Sent: Dienstag, 23. Mai 2017 15:11
> >> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> >> stian at redhat.com
> >> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >>
> >> No reason the code couldn't be "smarter" though.  Something simple
> >> and signed that has balancing/routing information in it.
> >>
> >>
> >> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
> >>> I would like to argue against 1). Putting token content into the
> >>> authcode kind of
> >> changes the flow to be more like the implicit flow.
> >>> OIDC/OAuth2 offers the code flow especially to protect information
> >>> in the
> >> tokens. Some claims could be sensitive and/or personal information
> >>> and I think they should not be in the code. Furthermore, enforcing
> >>> the single use
> >> of codes becomes even harder if they can be exchanged
> >>> to tokens without looking up state first. Relaxing the one-time
> >>> requirement is
> >> clearly against the spec and one should at least try hard to
> >>> fulfill it IMHO.
> >>>
> >>> Best regards,
> >>> Sebastian
> >>>
> >>> Mit freundlichen Grüßen / Best regards
> >>>
> >>>    Sebastian Schuster
> >>>
> >>> Engineering and Support (INST/ESY1)
> >>> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785
> >>> Berlin |
> >> GERMANY | www.bosch-si.com
> >>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> >>> Sebastian.Schuster at bosch-
> >> si.com
> >>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
> >>> 148411 B
> >>> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> >>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
> >>>> Sent: Montag, 22. Mai 2017 19:30
> >>>> To: Bill Burke <bburke at redhat.com>
> >>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> >>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >>>>
> >>>> 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
> >>>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev