3:24 a.m.
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..
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.
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.
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..
For now, I can see some combination of 1,3,4 as a way to go. WDYT?
Marek
8:12 a.m.
Don't you have same problem with refresh token?
On 5/19/17 4:24 AM, Marek Posolda 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..
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.
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.
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..
For now, I can see some combination of 1,3,4 as a way to go. WDYT?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:21 a.m.
Yes, it is in all backchannel requests you mentioned in the other mail.
Just wanted to start with code-to-token request as it is "special" due
the fact that:
- code is single-use per specs and this should be ensured for all DCs
though.
- userSession may not be yet available in case of ASYNC replication. So
was thinking about possibility to avoid lookup userSession at all in
code-to-token request (details below) and other options.
Marek
On 19/05/17 15:12, Bill Burke wrote:
Don't you have same problem with refresh token?
On 5/19/17 4:24 AM, Marek Posolda 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..
>
> 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.
>
> 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.
>
> 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..
>
> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:30 a.m.
On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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.
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.
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:16 a.m.
On 5/22/17 3:30 AM, Stian Thorgersen wrote:
On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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.
> 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
12:29 p.m.
On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
On 5/22/17 3:30 AM, Stian Thorgersen wrote:
> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:32 a.m.
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Montag, 22. Mai 2017 19:30
To: Bill Burke <bburke(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>
>
> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
> > On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:34 a.m.
On 22/05/17 19:29, Stian Thorgersen wrote:
>> 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.
Regarding this, I was thinking about adding separate callback method to
protocolMappers SPI, which will be invoked at the time when OAuth code
is generated (and before it is sent to the application). This would be
done in browser request and userSession will be available here. So the
mappers, which need userSession (UserSessionNoteMapper etc) will add the
claim into the code JWT. Then later code-to-token endpoint will just
copy those claims from the code JWT to the token JWT. The claims, which
don't need user session (eg. UserAttributeMapper) won't do anything in
the new code JWT callback, but claims will be added to the token in the
code-to-token endpoint directly from UserModel in same way like it is now.
Anyway, I don't know if it handles all the corner cases and future
scenarios (in-memory UserModel etc), so will try to go the "on-demand
replication of userSession" path. We will see if that's sufficient.
Marek
3:41 a.m.
On 22/05/17 15:16, Bill Burke wrote:
>> 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.
Ok, I understand 1 may be problematic for some scenarios and won't do
it. But what exactly is a blocker for relax on code one-time use?
I am thinking that code will be still single-use by default as it's
required per OAuth2/OIDC specs. However admins, who prefer performance
over security, may choose to relax strict code one-time use. This may be
new option - not sure whether configurable per realm or per client. I
can see it's likely ok in some environments (private corporate networks
etc) ?
Marek
4:16 a.m.
On 22/05/17 09:30, Stian Thorgersen wrote:
On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@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?
Just did some simple testing. For the
HMAC signed code, the code with 10
JSON claims has:
header size: 84
content size: 524
signature size: 87
Total length of code parameter would be 697 characters. As long as URL
is shorter than 2000 characters, it should work fine in all the
browsers, so we should be ok?
Not sure whether we need to use "code as JWT" path. Even if we require
on-demand replication of userSession and hence the userSession will be
available in code-to-token endpoint, having code as JWT may be still
helpful for some things (sticky sessions etc).
I reckon protocol mappers should be refactored regardless though. The
details should be in the code and token not in the user session.
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.
+1
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
<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.
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?
You mean that PKCE will be another issue
in cross-dc? I am not seeing
anything more problematic then other scenarios? For server-side, it
requires userSession available in code-to-token endpoint as that's where
codeChallenge is saved. However that should be the case anyway.
Marek
For now, I can see some combination of 1,3,4 as a way to go. WDYT?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
5:29 a.m.
Another argument against providing claims in the code is that it can be stolen by rogue
mobile apps and PKCE does not help here as it only prevents using stolen codes. Encrypting
the code could help, but this might also have impact on code size. Maybe it is best to
first try the on-demand replication approach and see if it nails it before introducing
another configuration switch that could be set wrong and the associated code?
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
bounces(a)lists.jboss.org] On Behalf Of Marek Posolda
Sent: Dienstag, 23. Mai 2017 10:41
To: Bill Burke <bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
On 22/05/17 15:16, Bill Burke wrote:
>>> 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.
Ok, I understand 1 may be problematic for some scenarios and won't do it. But
what exactly is a blocker for relax on code one-time use?
I am thinking that code will be still single-use by default as it's required per
OAuth2/OIDC specs. However admins, who prefer performance over security, may
choose to relax strict code one-time use. This may be new option - not sure
whether configurable per realm or per client. I can see it's likely ok in some
environments (private corporate networks
etc) ?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:56 a.m.
Yes, security is another thing, which I was slightly worried regarding
this. +1 to first try on-demand replication approach.
Marek
On 23/05/17 12:29, Schuster Sebastian (INST/ESY1) wrote:
Another argument against providing claims in the code is that it can
be stolen by rogue mobile apps and PKCE does not help here as it only prevents using
stolen codes. Encrypting the code could help, but this might also have impact on code
size. Maybe it is best to first try the on-demand replication approach and see if it nails
it before introducing another configuration switch that could be set wrong and the
associated code?
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
> bounces(a)lists.jboss.org] On Behalf Of Marek Posolda
> Sent: Dienstag, 23. Mai 2017 10:41
> To: Bill Burke <bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>
> On 22/05/17 15:16, Bill Burke wrote:
>>>> 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.
> Ok, I understand 1 may be problematic for some scenarios and won't do it. But
> what exactly is a blocker for relax on code one-time use?
>
> I am thinking that code will be still single-use by default as it's required per
> OAuth2/OIDC specs. However admins, who prefer performance over security, may
> choose to relax strict code one-time use. This may be new option - not sure
> whether configurable per realm or per client. I can see it's likely ok in some
> environments (private corporate networks
> etc) ?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:54 a.m.
On 23 May 2017 at 11:16, Marek Posolda <mposolda(a)redhat.com> wrote:
On 22/05/17 09:30, Stian Thorgersen wrote:
On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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?
Just did some simple testing. For the HMAC signed code, the code with 10
JSON claims has:
header size: 84
content size: 524
signature size: 87
Total length of code parameter would be 697 characters. As long as URL is
shorter than 2000 characters, it should work fine in all the browsers, so
we should be ok?
Not sure whether we need to use "code as JWT" path. Even if we require
on-demand replication of userSession and hence the userSession will be
available in code-to-token endpoint, having code as JWT may be still
helpful for some things (sticky sessions etc).
I reckon protocol mappers should be refactored regardless though. The
details should be in the code and token not in the user session.
>
> 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.
+1
>
> 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.
>
> 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?
You mean that PKCE will be another issue in cross-dc? I am not seeing
anything more problematic then other scenarios? For server-side, it
requires userSession available in code-to-token endpoint as that's where
codeChallenge is saved. However that should be the case anyway.
Probably not a new problem, but it's yet another update to user session.
Marek
>
> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
7:55 a.m.
Marek - are we not just storing the details we need to know what mappers to
invoke? There's no actually claims in there right?
On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Another argument against providing claims in the code is that it can
be
stolen by rogue mobile apps and PKCE does not help here as it only prevents
using stolen codes. Encrypting the code could help, but this might also
have impact on code size. Maybe it is best to first try the on-demand
replication approach and see if it nails it before introducing another
configuration switch that could be set wrong and the associated code?
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
> bounces(a)lists.jboss.org] On Behalf Of Marek Posolda
> Sent: Dienstag, 23. Mai 2017 10:41
> To: Bill Burke <bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>
> On 22/05/17 15:16, Bill Burke wrote:
> >>> 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.
>
> Ok, I understand 1 may be problematic for some scenarios and won't do
it. But
> what exactly is a blocker for relax on code one-time use?
>
> I am thinking that code will be still single-use by default as it's
required per
> OAuth2/OIDC specs. However admins, who prefer performance over security,
may
> choose to relax strict code one-time use. This may be new option - not
sure
> whether configurable per realm or per client. I can see it's likely ok
in some
> environments (private corporate networks
> etc) ?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:11 a.m.
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Montag, 22. Mai 2017 19:30
> To: Bill Burke <bburke(a)redhat.com>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>
> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>
>>
>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:36 a.m.
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(a)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@redhat.com]
Sent: Dienstag, 23. Mai 2017 15:11
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
stian(a)redhat.com
Cc: keycloak-dev <keycloak-dev(a)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@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(a)lists.jboss.org [mailto:keycloak-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>> Sent: Montag, 22. Mai 2017 19:30
>> To: Bill Burke <bburke(a)redhat.com>
>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>
>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>
>>>
>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:34 a.m.
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(a)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@redhat.com]
> Sent: Dienstag, 23. Mai 2017 15:11
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
> stian(a)redhat.com
> Cc: keycloak-dev <keycloak-dev(a)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@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(a)lists.jboss.org [mailto:keycloak-dev-
>>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>>> Sent: Montag, 22. Mai 2017 19:30
>>> To: Bill Burke <bburke(a)redhat.com>
>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>
>>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>>
>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:11 p.m.
Doesn't that count on the client actually following the redirect? I don't
think most http libraries do that automatically.
On 23 May 2017 at 17:34, Bill Burke <bburke(a)redhat.com> wrote:
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(a)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@redhat.com]
>> Sent: Dienstag, 23. Mai 2017 15:11
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
>> stian(a)redhat.com
>> Cc: keycloak-dev <keycloak-dev(a)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@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(a)lists.jboss.org [mailto:keycloak-dev-
>>>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>>>> Sent: Montag, 22. Mai 2017 19:30
>>>> To: Bill Burke <bburke(a)redhat.com>
>>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>
>>>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>>>
>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>
>>>>>> On 19 May 2017 at 10:24, Marek Posolda
<mposolda(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
1:11 p.m.
Doesn't the code only have to contain client_id, scope, etc.? Then the
protocol mappers can be evaluated when the token is generated rather than
when the code is generated?
On 23 May 2017 at 15:11, Bill Burke <bburke(a)redhat.com> wrote:
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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>> Sent: Montag, 22. Mai 2017 19:30
>> To: Bill Burke <bburke(a)redhat.com>
>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>
>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>
>>
>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>
>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
2:43 p.m.
Nope, right now OAuth code just references userSession and client. ATM
code itself is not JWT.
Marek
On 23/05/17 14:55, Stian Thorgersen wrote:
Marek - are we not just storing the details we need to know what
mappers to invoke? There's no actually claims in there right?
On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@bosch-si.com>> wrote:
Another argument against providing claims in the code is that it
can be stolen by rogue mobile apps and PKCE does not help here as
it only prevents using stolen codes. Encrypting the code could
help, but this might also have impact on code size. Maybe it is
best to first try the on-demand replication approach and see if it
nails it before introducing another configuration switch that
could be set wrong and the associated code?
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 <http://www.bosch-si.com>
Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100 <tel:%2B49%2030%20726112-100> |
Sebastian.Schuster(a)bosch-si.com
<mailto:Sebastian.Schuster@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(a)lists.jboss.org
<mailto:keycloak-dev-bounces@lists.jboss.org>
[mailto:keycloak-dev- <mailto:keycloak-dev->
>bounces(a)lists.jboss.org <mailto:bounces@lists.jboss.org>] On
Behalf Of Marek Posolda
> Sent: Dienstag, 23. Mai 2017 10:41
> To: Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>;
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>
> On 22/05/17 15:16, Bill Burke wrote:
> >>> 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.
>
> Ok, I understand 1 may be problematic for some scenarios and
won't do it. But
> what exactly is a blocker for relax on code one-time use?
>
> I am thinking that code will be still single-use by default as
it's required per
> OAuth2/OIDC specs. However admins, who prefer performance over
security, may
> choose to relax strict code one-time use. This may be new option
- not sure
> whether configurable per realm or per client. I can see it's
likely ok in some
> environments (private corporate networks
> etc) ?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
3:05 p.m.
Isn't redirection problematic especially with 3rd party adapters, as
their libraries may not redirect request automatically? For example
Apache Http Client redirects automatically, but it's possible to
configure max amount of redirects or disable it entirely AFAIK.
Marek
On 23/05/17 17:34, Bill Burke wrote:
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(a)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@redhat.com]
>> Sent: Dienstag, 23. Mai 2017 15:11
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
>> stian(a)redhat.com
>> Cc: keycloak-dev <keycloak-dev(a)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@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(a)lists.jboss.org [mailto:keycloak-dev-
>>>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>>>> Sent: Montag, 22. Mai 2017 19:30
>>>> To: Bill Burke <bburke(a)redhat.com>
>>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>
>>>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>>>
>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>> On 19 May 2017 at 10:24, Marek Posolda
<mposolda(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:25 p.m.
I meant if we are planning to change it. I don't see why it would need to
contain actual claims, but rather could it not just contain the details to
generate the claims?
On 23 May 2017 at 21:43, Marek Posolda <mposolda(a)redhat.com> wrote:
Nope, right now OAuth code just references userSession and client.
ATM
code itself is not JWT.
Marek
On 23/05/17 14:55, Stian Thorgersen wrote:
Marek - are we not just storing the details we need to know what mappers
to invoke? There's no actually claims in there right?
On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster(a)bosch-si.com> wrote:
> Another argument against providing claims in the code is that it can be
> stolen by rogue mobile apps and PKCE does not help here as it only prevents
> using stolen codes. Encrypting the code could help, but this might also
> have impact on code size. Maybe it is best to first try the on-demand
> replication approach and see if it nails it before introducing another
> configuration switch that could be set wrong and the associated code?
>
> 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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
> > bounces(a)lists.jboss.org] On Behalf Of Marek Posolda
> > Sent: Dienstag, 23. Mai 2017 10:41
> > To: Bill Burke <bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
> > Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >
> > On 22/05/17 15:16, Bill Burke wrote:
> > >>> 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.
> >
> > Ok, I understand 1 may be problematic for some scenarios and won't do
> it. But
> > what exactly is a blocker for relax on code one-time use?
> >
> > I am thinking that code will be still single-use by default as it's
> required per
> > OAuth2/OIDC specs. However admins, who prefer performance over
> security, may
> > choose to relax strict code one-time use. This may be new option - not
> sure
> > whether configurable per realm or per client. I can see it's likely ok
> in some
> > environments (private corporate networks
> > etc) ?
> >
> > Marek
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
1:38 a.m.
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(a)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@redhat.com]
Sent: Dienstag, 23. Mai 2017 17:34
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
stian(a)redhat.com
Cc: keycloak-dev <keycloak-dev(a)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(a)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@redhat.com]
>> Sent: Dienstag, 23. Mai 2017 15:11
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>;
>> stian(a)redhat.com
>> Cc: keycloak-dev <keycloak-dev(a)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@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(a)lists.jboss.org [mailto:keycloak-dev-
>>>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>>>> Sent: Montag, 22. Mai 2017 19:30
>>>> To: Bill Burke <bburke(a)redhat.com>
>>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>
>>>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>>>
>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>> On 19 May 2017 at 10:24, Marek Posolda
<mposolda(a)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(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:53 a.m.
Wouldn’t that mean it would have to hit the database or Infinispan to retrieve additional
information from somewhere or are protocol mappers pure functions? In the first case,
storing additional information in the code is not that helpful anymore as state needs to
be retrieved anyways. In the second case, the code would have to be encrypted as an
attacker could derive claims from details in the code, too.
I actually started wondering whether code-to-token is a good use case for
retrieving/caching the user session. I would assume the client holds on to a token it
retrieved until it expires which means it might not come back to the token endpoint until
its DNS cache expires, possibly causing it to end up at another DC next time it comes
back. Depends on token lifetime vs. DNS cache expiration, of course. On the other hand, it
might go to the userinfo endpoint in between…
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<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Mittwoch, 24. Mai 2017 06:25
To: Marek Posolda <mposolda(a)redhat.com>
Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>; Bill Burke
<bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
I meant if we are planning to change it. I don't see why it would need to contain
actual claims, but rather could it not just contain the details to generate the claims?
On 23 May 2017 at 21:43, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
Nope, right now OAuth code just references userSession and client. ATM code itself is not
JWT.
Marek
On 23/05/17 14:55, Stian Thorgersen wrote:
Marek - are we not just storing the details we need to know what mappers to invoke?
There's no actually claims in there right?
On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
Another argument against providing claims in the code is that it can be stolen by rogue
mobile apps and PKCE does not help here as it only prevents using stolen codes. Encrypting
the code could help, but this might also have impact on code size. Maybe it is best to
first try the on-demand replication approach and see if it nails it before introducing
another configuration switch that could be set wrong and the associated code?
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<http://www.bosch-si.com>
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>
[mailto:keycloak-dev-<mailto:keycloak-dev->
bounces@lists.jboss.org<mailto:bounces@lists.jboss.org>] On Behalf Of Marek
Posolda
Sent: Dienstag, 23. Mai 2017 10:41
To: Bill Burke <bburke@redhat.com<mailto:bburke@redhat.com>>;
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
On 22/05/17 15:16, Bill Burke wrote:
>>> 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.
Ok, I understand 1 may be problematic for some scenarios and won't do it. But
what exactly is a blocker for relax on code one-time use?
I am thinking that code will be still single-use by default as it's required per
OAuth2/OIDC specs. However admins, who prefer performance over security, may
choose to relax strict code one-time use. This may be new option - not sure
whether configurable per realm or per client. I can see it's likely ok in some
environments (private corporate networks
etc) ?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:02 a.m.
There were 2 cases to consider:
- Code-to-token endpoint won't have userSession available. In this case,
code would need to contain actual claims. At least some of them, which
require userSession. But we agreed to not go this path, at least not now?
- Code-to-token endpoint will have userSession available. In this case,
code doesn't need to contain any claims of user. Just the sessionState
and possibly route info. Code-to-token endpoint will lookup userSession,
user, and all the stuff it needs to generate claims into the tokens.
Pretty much like it's now.
I was also thinking, that code is slightly modified JWT and also
contains route information in the path itself. Like:
code=jwt-header.jwt-content.jwt-hmac-signature.route-info . The route
info in the URL has advantage that some loadbalancers might be able to
read it from there and route the request. Lookup into JWT is slightly
more tricky and loadbalancers won't support it unless it's some
loadbalancer/smart proxy developed by us. Anyway, not everyone would
like to have the route in the URL, like Sebastian I guess? Maybe code
generation and parsing deserves to be externalized with the separate SPI?
Marek
On 24/05/17 06:25, Stian Thorgersen wrote:
I meant if we are planning to change it. I don't see why it would
need
to contain actual claims, but rather could it not just contain the
details to generate the claims?
On 23 May 2017 at 21:43, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Nope, right now OAuth code just references userSession and client.
ATM code itself is not JWT.
Marek
On 23/05/17 14:55, Stian Thorgersen wrote:
> Marek - are we not just storing the details we need to know what
> mappers to invoke? There's no actually claims in there right?
>
> On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1)
> <Sebastian.Schuster(a)bosch-si.com
> <mailto:Sebastian.Schuster@bosch-si.com>> wrote:
>
> Another argument against providing claims in the code is that
> it can be stolen by rogue mobile apps and PKCE does not help
> here as it only prevents using stolen codes. Encrypting the
> code could help, but this might also have impact on code
> size. Maybe it is best to first try the on-demand replication
> approach and see if it nails it before introducing another
> configuration switch that could be set wrong and the
> associated code?
>
> 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
> <http://www.bosch-si.com>
> Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> | Fax
> +49 30 726112-100 <tel:%2B49%2030%20726112-100> |
> Sebastian.Schuster(a)bosch-si.com
> <mailto:Sebastian.Schuster@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(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>
> [mailto:keycloak-dev- <mailto:keycloak-dev->
> >bounces(a)lists.jboss.org <mailto:bounces@lists.jboss.org>] On
> Behalf Of Marek Posolda
> > Sent: Dienstag, 23. Mai 2017 10:41
> > To: Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>>; keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >
> > On 22/05/17 15:16, Bill Burke wrote:
> > >>> 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.
> >
> > Ok, I understand 1 may be problematic for some scenarios
> and won't do it. But
> > what exactly is a blocker for relax on code one-time use?
> >
> > I am thinking that code will be still single-use by default
> as it's required per
> > OAuth2/OIDC specs. However admins, who prefer performance
> over security, may
> > choose to relax strict code one-time use. This may be new
> option - not sure
> > whether configurable per realm or per client. I can see
> it's likely ok in some
> > environments (private corporate networks
> > etc) ?
> >
> > Marek
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
2:06 a.m.
ah yes. We want to avoid writing details into userSession everytime when
the same client do SSO login again (like browser refresh of javascript
application page etc). Yep, so looks that code also needs to contain
stuff like client_id, scope and others besides userSession.
Marek
On 23/05/17 20:11, Stian Thorgersen wrote:
Doesn't the code only have to contain client_id, scope, etc.?
Then the
protocol mappers can be evaluated when the token is generated rather than
when the code is generated?
On 23 May 2017 at 15:11, Bill Burke <bburke(a)redhat.com> wrote:
> 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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
>>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>>> Sent: Montag, 22. Mai 2017 19:30
>>> To: Bill Burke <bburke(a)redhat.com>
>>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>
>>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>>
>>>
>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>
>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:04 a.m.
We've talked about this earlier in the thread. The User session is
needed as brokering or some other component might have stored temporary
data within the user session that is being mapped to a claim. This will
become especially important when we implement no-import brokering.
Either the code has to contain all claims, or the user session has to be
available.
IMO, the most viable solution is that the code contains routing
information and the code-to-token endpoint acts as a proxy if the
session doesn't exist on that node.
On 5/24/17 12:25 AM, Stian Thorgersen wrote:
I meant if we are planning to change it. I don't see why it would
need
to contain actual claims, but rather could it not just contain the
details to generate the claims?
On 23 May 2017 at 21:43, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Nope, right now OAuth code just references userSession and client.
ATM code itself is not JWT.
Marek
On 23/05/17 14:55, Stian Thorgersen wrote:
> Marek - are we not just storing the details we need to know what
> mappers to invoke? There's no actually claims in there right?
>
> On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1)
> <Sebastian.Schuster(a)bosch-si.com
> <mailto:Sebastian.Schuster@bosch-si.com>> wrote:
>
> Another argument against providing claims in the code is that
> it can be stolen by rogue mobile apps and PKCE does not help
> here as it only prevents using stolen codes. Encrypting the
> code could help, but this might also have impact on code
> size. Maybe it is best to first try the on-demand replication
> approach and see if it nails it before introducing another
> configuration switch that could be set wrong and the
> associated code?
>
> 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
> <http://www.bosch-si.com>
> Tel. +49 30 726112-485 <tel:%2B49%2030%20726112-485> | Fax
> +49 30 726112-100 <tel:%2B49%2030%20726112-100> |
> Sebastian.Schuster(a)bosch-si.com
> <mailto:Sebastian.Schuster@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(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>
> [mailto:keycloak-dev- <mailto:keycloak-dev->
> >bounces(a)lists.jboss.org <mailto:bounces@lists.jboss.org>] On
> Behalf Of Marek Posolda
> > Sent: Dienstag, 23. Mai 2017 10:41
> > To: Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>>; keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >
> > On 22/05/17 15:16, Bill Burke wrote:
> > >>> 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.
> >
> > Ok, I understand 1 may be problematic for some scenarios
> and won't do it. But
> > what exactly is a blocker for relax on code one-time use?
> >
> > I am thinking that code will be still single-use by default
> as it's required per
> > OAuth2/OIDC specs. However admins, who prefer performance
> over security, may
> > choose to relax strict code one-time use. This may be new
> option - not sure
> > whether configurable per realm or per client. I can see
> it's likely ok in some
> > environments (private corporate networks
> > etc) ?
> >
> > Marek
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
8:38 a.m.
On 24 May 2017 at 15:04, Bill Burke <bburke(a)redhat.com> wrote:
We've talked about this earlier in the thread. The User session
is needed
as brokering or some other component might have stored temporary data
within the user session that is being mapped to a claim. This will become
especially important when we implement no-import brokering. Either the
code has to contain all claims, or the user session has to be available.
That's the part that I don't understand. Why would it even contain
anything
if the code is just a permission to obtain a token. We invoke any protocol
mappers or anything until the first token is created.
IMO, the most viable solution is that the code contains routing
information and the code-to-token endpoint acts as a proxy if the session
doesn't exist on that node.
On 5/24/17 12:25 AM, Stian Thorgersen wrote:
I meant if we are planning to change it. I don't see why it would need to
contain actual claims, but rather could it not just contain the details to
generate the claims?
On 23 May 2017 at 21:43, Marek Posolda <mposolda(a)redhat.com> wrote:
> Nope, right now OAuth code just references userSession and client. ATM
> code itself is not JWT.
>
> Marek
>
>
> On 23/05/17 14:55, Stian Thorgersen wrote:
>
> Marek - are we not just storing the details we need to know what mappers
> to invoke? There's no actually claims in there right?
>
> On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1) <
> Sebastian.Schuster(a)bosch-si.com> wrote:
>
>> Another argument against providing claims in the code is that it can be
>> stolen by rogue mobile apps and PKCE does not help here as it only prevents
>> using stolen codes. Encrypting the code could help, but this might also
>> have impact on code size. Maybe it is best to first try the on-demand
>> replication approach and see if it nails it before introducing another
>> configuration switch that could be set wrong and the associated code?
>>
>> 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 <%2B49%2030%20726112-485> | Fax +49 30 726112-100
>> <%2B49%2030%20726112-100> | Sebastian.Schuster(a)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(a)lists.jboss.org [mailto:keycloak-dev-
>> > bounces(a)lists.jboss.org] On Behalf Of Marek Posolda
>> > Sent: Dienstag, 23. Mai 2017 10:41
>> > To: Bill Burke <bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
>> > Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>> >
>> > On 22/05/17 15:16, Bill Burke wrote:
>> > >>> 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.
>> >
>> > Ok, I understand 1 may be problematic for some scenarios and won't do
>> it. But
>> > what exactly is a blocker for relax on code one-time use?
>> >
>> > I am thinking that code will be still single-use by default as it's
>> required per
>> > OAuth2/OIDC specs. However admins, who prefer performance over
>> security, may
>> > choose to relax strict code one-time use. This may be new option - not
>> sure
>> > whether configurable per realm or per client. I can see it's likely ok
>> in some
>> > environments (private corporate networks
>> > etc) ?
>> >
>> > Marek
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
9:30 a.m.
On 5/24/17 9:38 AM, Stian Thorgersen wrote:
On 24 May 2017 at 15:04, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
We've talked about this earlier in the thread. The User session
is needed as brokering or some other component might have stored
temporary data within the user session that is being mapped to a
claim. This will become especially important when we implement
no-import brokering. Either the code has to contain all claims,
or the user session has to be available.
That's the part that I don't understand. Why would it even contain
anything if the code is just a permission to obtain a token. We invoke
any protocol mappers or anything until the first token is created.
I'm just saying that you may need information in the UserSession to be
able to create a token. Protocol mappers are iterated when deciding to
show the consent screen. I'm not sure why protocol mappers were stored
in the user session. Marek will have to answer that question.
Bill
3:59 p.m.
On 24/05/17 16:30, Bill Burke wrote:
On 5/24/17 9:38 AM, Stian Thorgersen wrote:
>
>
> On 24 May 2017 at 15:04, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> We've talked about this earlier in the thread. The User session
> is needed as brokering or some other component might have stored
> temporary data within the user session that is being mapped to a
> claim. This will become especially important when we implement
> no-import brokering. Either the code has to contain all claims,
> or the user session has to be available.
>
> That's the part that I don't understand. Why would it even contain
> anything if the code is just a permission to obtain a token. We
> invoke any protocol mappers or anything until the first token is created.
I'm just saying that you may need information in the UserSession to be
able to create a token. Protocol mappers are iterated when deciding
to show the consent screen. I'm not sure why protocol mappers were
stored in the user session. Marek will have to answer that question.
AFAIR the
only reason was scope parameter. If you did SSO login for 2
times with same client and same userSession, it used to create 2
separate clientSessions. Every clientSession may have different roles if
scope parameter is different. That's why roles needed to be listed in
clientSession. For protocolMappers, we didn't support scope parameter,
but we planned to add that.
Anyway, there is JIRA for remove protocolMappers and roles from the
session. It can be done as long as the information is available inside
"code" and inside "refreshToken". So as long as "code"
contains the
informations from the authorizationRequest (clientId, scope, etc), we
don't need to keep this information inside userSession.
Marek
Bill
2539
days inactive
2544
days old
29 comments
4 participants
participants (4)
-
Bill Burke -
Marek Posolda -
Schuster Sebastian (INST/ESY1) -
Stian Thorgersen