From mposolda at redhat.com  Tue May  2 06:45:25 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 2 May 2017 12:45:25 +0200
Subject: [keycloak-dev] Support rfc6750 Form-Encoded Body Parameter for
 access tokens in Keycloak
In-Reply-To: <07cd8d8f-8128-a091-1cea-3b4c8f7dcae3@gmx.net>
References: <07cd8d8f-8128-a091-1cea-3b4c8f7dcae3@gmx.net>
Message-ID: <b20ac66e-9e96-250a-b31f-57de99f70063@redhat.com>

Feel free to create JIRA for this and also send PR.

Maybe it is as simple as refactor QueryParamterTokenRequestAuthenticator 
to use "exchange.getRequest().getFirstParamValue(ACCESS_TOKEN)" instead 
of "exchange.getRequest().getQueryParamValue(ACCESS_TOKEN)" (the former 
would handle both query and form parameters), but not 100% sure. Also 
for the PR, we would need the test too.

Btv. the JIRA were the query parameter support was added was 
https://issues.jboss.org/browse/KEYCLOAK-1733 .

Marek

On 28/04/17 16:30, Alexander Schwartz wrote:
> Hi Keycloak Developers,
>
> RFC6750 allows the access token to be submitted as part of a POST
> request. I found that this is the only good way to do file downloads in
> a JavaScript frontend.
>
> https://tools.ietf.org/html/rfc6750#section-2.1
>
> Excerpt: When sending the access token in the HTTP request entity-body,
> client adds the access token to the request-body using the
> "access_token" parameter. [...] Resource servers MAY support this method.
>
> I don't remember a thread on this mailing list. The only place I could
> find in the code was the User Endpoint that does this quite manually.
>
> Currently Keycloak only supports the query parameter using
> QueryParamterTokenRequestAuthenticator. A similar class will be needed
> to support a Form Parameter. Like the
> QueryParamterTokenRequestAuthenticator it will be part of the request
> processing and it will not be configurable.
>
> I'd like to open a JIRA issue for this as part of the Java Keycloak
> Clients to track the efforts and thoughts.
>
> Comments welcome!
>
> Regards,
> Alexander
>


From mposolda at redhat.com  Wed May  3 03:47:29 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 3 May 2017 09:47:29 +0200
Subject: [keycloak-dev] Frontchannel logout based on iframes?
Message-ID: <6c6d6eb5-632a-7beb-b8fc-7931f8818862@redhat.com>

I went through the OIDC frontchannel logout specification draft [1] and 
realized that it relies a lot on the iframes instead of browser 
redirection. Basically OP would render HTML page with the hidden iframes 
containing the logout URL of clients like:

<iframe src="frontchannel_logout_uri">

I wonder if we should add some support for the iframes based approach 
for SAML too? It looks that many vendors including shibboleth (see [2]) 
are using it as it seem to have lots of advantages over the redirection 
based. Like:

- More reliable. With the redirection based approach used by SAML, the 
IDP needs to redirect browser to the client1, which then need to 
redirect back to IDP, which continues with redirection to client2 etc. 
Problem is, that if any client is broken, then whole flow will break and 
logout won't be finished properly.

- Better performance. Logout requests would be sent concurrently to all 
the clients.

- Better for cross-dc as there is no need for more writes to userSession 
cache. IDP would just render the html with iframes in single request and 
then remove userSession entirely.

Possible disadvantages:
- iframes may be blocked on the SP side.

- It will require some javascript though as for SAML-SP initiated 
logout, the IDP needs to send the LogoutResponse back to the SP, which 
initiated logout. Which means that once HTML with iframes is rendered 
and all the iframe requests are finished, there would need to be some 
callback, which will automatically redirect browser back to SP with 
LogoutResponse.

- POST binding for logout. Not sure if this would work with iframes, but 
I suppose there are some ways how to solve that (automatically submitted 
form through javascript etc).

- Anything else?

WDYT? Do we want to add some support for iframes based logout to our 
SAML clients?


[1] http://openid.net/specs/openid-connect-frontchannel-1_0.html
[2] https://www.switch.ch/aai/support/presentations/update2016/07_logout.pdf

Marek


From sthorger at redhat.com  Wed May  3 05:02:23 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 3 May 2017 11:02:23 +0200
Subject: [keycloak-dev] Keycloak 3.1.0.Final Released
Message-ID: <CAJgngAdZ=d+wBs8psAVCV+B4nzh0rce=4Hcmxq3FJJWMtX4joA@mail.gmail.com>

Keycloak 3.1.0.Final has just been released.

To download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.

The full list of resolved issues is available in JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.1.0.Final>
.
Upgrading

Before you upgrade remember to backup your database and check the migration
guide
<https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
.

From heide at 365farmnet.com  Wed May  3 08:28:21 2017
From: heide at 365farmnet.com (Heide, Marc)
Date: Wed, 3 May 2017 12:28:21 +0000
Subject: [keycloak-dev] KEYCLOAK-4521: Error getting userinfo via access
 token obtained by offline token
Message-ID: <0A9F064B-3E15-4100-B533-382C190BF12E@365farmnet.com>

Hi,

Regarding this issue, is it ok to send PR?
I have tested the solution proposed my Marek in the description. In fact I have implemented it as a fallback if the session is null.
Seems to work for our use case. Testsuite has passed so far on my side.

Sorry if I forgot something. It?s my first contribution.

Best Regards
Marc  




From sthorger at redhat.com  Wed May  3 08:55:17 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 3 May 2017 14:55:17 +0200
Subject: [keycloak-dev] KEYCLOAK-4521: Error getting userinfo via access
 token obtained by offline token
In-Reply-To: <0A9F064B-3E15-4100-B533-382C190BF12E@365farmnet.com>
References: <0A9F064B-3E15-4100-B533-382C190BF12E@365farmnet.com>
Message-ID: <CAJgngAeQ+VLYmrKcf8fH8wyquE2Rx1MCCMyRQKTSfLacXCjtPQ@mail.gmail.com>

PR would be welcome, but please remember to add a test with the PR.

On 3 May 2017 at 14:28, Heide, Marc <heide at 365farmnet.com> wrote:

> Hi,
>
> Regarding this issue, is it ok to send PR?
> I have tested the solution proposed my Marek in the description. In fact I
> have implemented it as a fallback if the session is null.
> Seems to work for our use case. Testsuite has passed so far on my side.
>
> Sorry if I forgot something. It?s my first contribution.
>
> Best Regards
> Marc
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Wed May  3 09:23:14 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 3 May 2017 09:23:14 -0400
Subject: [keycloak-dev] Frontchannel logout based on iframes?
In-Reply-To: <6c6d6eb5-632a-7beb-b8fc-7931f8818862@redhat.com>
References: <6c6d6eb5-632a-7beb-b8fc-7931f8818862@redhat.com>
Message-ID: <cfaf00e1-30c5-af2e-d46a-625d479096f1@redhat.com>



On 5/3/17 3:47 AM, Marek Posolda wrote:
> I went through the OIDC frontchannel logout specification draft [1] and
> realized that it relies a lot on the iframes instead of browser
> redirection. Basically OP would render HTML page with the hidden iframes
> containing the logout URL of clients like:
>
> <iframe src="frontchannel_logout_uri">
>
> I wonder if we should add some support for the iframes based approach
> for SAML too? It looks that many vendors including shibboleth (see [2])
> are using it as it seem to have lots of advantages over the redirection
> based. Like:
>
> - More reliable. With the redirection based approach used by SAML, the
> IDP needs to redirect browser to the client1, which then need to
> redirect back to IDP, which continues with redirection to client2 etc.
> Problem is, that if any client is broken, then whole flow will break and
> logout won't be finished properly.
>
> - Better performance. Logout requests would be sent concurrently to all
> the clients.
>
> - Better for cross-dc as there is no need for more writes to userSession
> cache. IDP would just render the html with iframes in single request and
> then remove userSession entirely.
>
> Possible disadvantages:
> - iframes may be blocked on the SP side.
>
> - It will require some javascript though as for SAML-SP initiated
> logout, the IDP needs to send the LogoutResponse back to the SP, which
> initiated logout. Which means that once HTML with iframes is rendered
> and all the iframe requests are finished, there would need to be some
> callback, which will automatically redirect browser back to SP with
> LogoutResponse.
>
> - POST binding for logout. Not sure if this would work with iframes, but
> I suppose there are some ways how to solve that (automatically submitted
> form through javascript etc).
+1,  Don't think POSt binding will be an issue.  If you look at the POSt 
binding it actually requires HTML forms with embedded Javascript to do a 
"POST redirect".

> - Anything else?
>
> WDYT? Do we want to add some support for iframes based logout to our
> SAML clients?

What's cool is that logout could be done in parallel, no?

Bill

From hmlnarik at redhat.com  Wed May  3 09:43:34 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 3 May 2017 15:43:34 +0200
Subject: [keycloak-dev] Frontchannel logout based on iframes?
In-Reply-To: <cfaf00e1-30c5-af2e-d46a-625d479096f1@redhat.com>
References: <6c6d6eb5-632a-7beb-b8fc-7931f8818862@redhat.com>
	<cfaf00e1-30c5-af2e-d46a-625d479096f1@redhat.com>
Message-ID: <CAMvXD=EpA_hwy6OAWKLwwq7K0ifMKSY-KpKb8oAoeJjeiNp=zw@mail.gmail.com>

I like this idea.

My only technical concern is whether we need to support browsers with
disabled Javascript - if yes, front channel logouts POST binding might
not work, and we would have to make this optimization optional, e.g.
in realm settings. Currently, POST binding has a fallback for
non-javascript browsers: the user can click a button to submit the
form with logout response manually. This button would not be visible
in an iframe, meaning that the logout would not proceed for that
particular client.

Given that non-Javascript-capable browsers are rather rare, I don't
see this as a blocker so I would prefer going on with Marek's
suggestion and document this as a known limitation.

--Hynek


On Wed, May 3, 2017 at 3:23 PM, Bill Burke <bburke at redhat.com> wrote:
>
>
> On 5/3/17 3:47 AM, Marek Posolda wrote:
>> I went through the OIDC frontchannel logout specification draft [1] and
>> realized that it relies a lot on the iframes instead of browser
>> redirection. Basically OP would render HTML page with the hidden iframes
>> containing the logout URL of clients like:
>>
>> <iframe src="frontchannel_logout_uri">
>>
>> I wonder if we should add some support for the iframes based approach
>> for SAML too? It looks that many vendors including shibboleth (see [2])
>> are using it as it seem to have lots of advantages over the redirection
>> based. Like:
>>
>> - More reliable. With the redirection based approach used by SAML, the
>> IDP needs to redirect browser to the client1, which then need to
>> redirect back to IDP, which continues with redirection to client2 etc.
>> Problem is, that if any client is broken, then whole flow will break and
>> logout won't be finished properly.
>>
>> - Better performance. Logout requests would be sent concurrently to all
>> the clients.
>>
>> - Better for cross-dc as there is no need for more writes to userSession
>> cache. IDP would just render the html with iframes in single request and
>> then remove userSession entirely.
>>
>> Possible disadvantages:
>> - iframes may be blocked on the SP side.
>>
>> - It will require some javascript though as for SAML-SP initiated
>> logout, the IDP needs to send the LogoutResponse back to the SP, which
>> initiated logout. Which means that once HTML with iframes is rendered
>> and all the iframe requests are finished, there would need to be some
>> callback, which will automatically redirect browser back to SP with
>> LogoutResponse.
>>
>> - POST binding for logout. Not sure if this would work with iframes, but
>> I suppose there are some ways how to solve that (automatically submitted
>> form through javascript etc).
> +1,  Don't think POSt binding will be an issue.  If you look at the POSt
> binding it actually requires HTML forms with embedded Javascript to do a
> "POST redirect".
>
>> - Anything else?
>>
>> WDYT? Do we want to add some support for iframes based logout to our
>> SAML clients?
>
> What's cool is that logout could be done in parallel, no?
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

--Hynek

From mposolda at redhat.com  Wed May  3 15:10:41 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 3 May 2017 21:10:41 +0200
Subject: [keycloak-dev] Frontchannel logout based on iframes?
In-Reply-To: <cfaf00e1-30c5-af2e-d46a-625d479096f1@redhat.com>
References: <6c6d6eb5-632a-7beb-b8fc-7931f8818862@redhat.com>
	<cfaf00e1-30c5-af2e-d46a-625d479096f1@redhat.com>
Message-ID: <6dc058fe-f5ce-ed0a-b990-26b61a550ed0@redhat.com>

On 03/05/17 15:23, Bill Burke wrote:
>
> On 5/3/17 3:47 AM, Marek Posolda wrote:
>> I went through the OIDC frontchannel logout specification draft [1] and
>> realized that it relies a lot on the iframes instead of browser
>> redirection. Basically OP would render HTML page with the hidden iframes
>> containing the logout URL of clients like:
>>
>> <iframe src="frontchannel_logout_uri">
>>
>> I wonder if we should add some support for the iframes based approach
>> for SAML too? It looks that many vendors including shibboleth (see [2])
>> are using it as it seem to have lots of advantages over the redirection
>> based. Like:
>>
>> - More reliable. With the redirection based approach used by SAML, the
>> IDP needs to redirect browser to the client1, which then need to
>> redirect back to IDP, which continues with redirection to client2 etc.
>> Problem is, that if any client is broken, then whole flow will break and
>> logout won't be finished properly.
>>
>> - Better performance. Logout requests would be sent concurrently to all
>> the clients.
>>
>> - Better for cross-dc as there is no need for more writes to userSession
>> cache. IDP would just render the html with iframes in single request and
>> then remove userSession entirely.
>>
>> Possible disadvantages:
>> - iframes may be blocked on the SP side.
>>
>> - It will require some javascript though as for SAML-SP initiated
>> logout, the IDP needs to send the LogoutResponse back to the SP, which
>> initiated logout. Which means that once HTML with iframes is rendered
>> and all the iframe requests are finished, there would need to be some
>> callback, which will automatically redirect browser back to SP with
>> LogoutResponse.
>>
>> - POST binding for logout. Not sure if this would work with iframes, but
>> I suppose there are some ways how to solve that (automatically submitted
>> form through javascript etc).
> +1,  Don't think POSt binding will be an issue.  If you look at the POSt
> binding it actually requires HTML forms with embedded Javascript to do a
> "POST redirect".
>
>> - Anything else?
>>
>> WDYT? Do we want to add some support for iframes based logout to our
>> SAML clients?
> What's cool is that logout could be done in parallel, no?
Yes, exactly.

By the way, I think that we have a space for improvement here for 
backchannel requests as well. Right now, they are sent sequentially in 
AuthenticationManager.backchannelLogout . We can sent logout request to 
all the authenticated clients in the userSession concurrently IMO.

Marek
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Wed May  3 15:27:26 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 3 May 2017 21:27:26 +0200
Subject: [keycloak-dev] Frontchannel logout based on iframes?
In-Reply-To: <CAMvXD=EpA_hwy6OAWKLwwq7K0ifMKSY-KpKb8oAoeJjeiNp=zw@mail.gmail.com>
References: <6c6d6eb5-632a-7beb-b8fc-7931f8818862@redhat.com>
	<cfaf00e1-30c5-af2e-d46a-625d479096f1@redhat.com>
	<CAMvXD=EpA_hwy6OAWKLwwq7K0ifMKSY-KpKb8oAoeJjeiNp=zw@mail.gmail.com>
Message-ID: <9846cabe-a1e9-7ae7-f96e-4de597950ba9@redhat.com>

Maybe we can solve this somehow too. The iframes can be visible by 
default and we can hide them through the javascript, once the document 
is loaded. If javascript is disabled, iframe will be still visible, so 
user can manually click on logout button. But not sure how bad this is 
for usability?

My hope is, if we can remove redirect-based approach and rely on iframes 
instead, which will help with cross-dc. But I may miss some corner 
cases... If we need to keep the redirect-based approach, we would need 
to refactor it anyway IMO as currently frontchannel logout with 
redirect-based approach needs to write multiple times to userSession 
before it removes it, which is not ideal behaviour. Probably we can 
create temporary authenticationSession, which will exist just during the 
logout process, and will be able to rely on browser sticky session 
between redirects.

Marek

On 03/05/17 15:43, Hynek Mlnarik wrote:
> I like this idea.
>
> My only technical concern is whether we need to support browsers with
> disabled Javascript - if yes, front channel logouts POST binding might
> not work, and we would have to make this optimization optional, e.g.
> in realm settings. Currently, POST binding has a fallback for
> non-javascript browsers: the user can click a button to submit the
> form with logout response manually. This button would not be visible
> in an iframe, meaning that the logout would not proceed for that
> particular client.
>
> Given that non-Javascript-capable browsers are rather rare, I don't
> see this as a blocker so I would prefer going on with Marek's
> suggestion and document this as a known limitation.
>
> --Hynek
>
>
> On Wed, May 3, 2017 at 3:23 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> On 5/3/17 3:47 AM, Marek Posolda wrote:
>>> I went through the OIDC frontchannel logout specification draft [1] and
>>> realized that it relies a lot on the iframes instead of browser
>>> redirection. Basically OP would render HTML page with the hidden iframes
>>> containing the logout URL of clients like:
>>>
>>> <iframe src="frontchannel_logout_uri">
>>>
>>> I wonder if we should add some support for the iframes based approach
>>> for SAML too? It looks that many vendors including shibboleth (see [2])
>>> are using it as it seem to have lots of advantages over the redirection
>>> based. Like:
>>>
>>> - More reliable. With the redirection based approach used by SAML, the
>>> IDP needs to redirect browser to the client1, which then need to
>>> redirect back to IDP, which continues with redirection to client2 etc.
>>> Problem is, that if any client is broken, then whole flow will break and
>>> logout won't be finished properly.
>>>
>>> - Better performance. Logout requests would be sent concurrently to all
>>> the clients.
>>>
>>> - Better for cross-dc as there is no need for more writes to userSession
>>> cache. IDP would just render the html with iframes in single request and
>>> then remove userSession entirely.
>>>
>>> Possible disadvantages:
>>> - iframes may be blocked on the SP side.
>>>
>>> - It will require some javascript though as for SAML-SP initiated
>>> logout, the IDP needs to send the LogoutResponse back to the SP, which
>>> initiated logout. Which means that once HTML with iframes is rendered
>>> and all the iframe requests are finished, there would need to be some
>>> callback, which will automatically redirect browser back to SP with
>>> LogoutResponse.
>>>
>>> - POST binding for logout. Not sure if this would work with iframes, but
>>> I suppose there are some ways how to solve that (automatically submitted
>>> form through javascript etc).
>> +1,  Don't think POSt binding will be an issue.  If you look at the POSt
>> binding it actually requires HTML forms with embedded Javascript to do a
>> "POST redirect".
>>
>>> - Anything else?
>>>
>>> WDYT? Do we want to add some support for iframes based logout to our
>>> SAML clients?
>> What's cool is that logout could be done in parallel, no?
>>
>> Bill
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From heide at 365farmnet.com  Thu May  4 05:10:03 2017
From: heide at 365farmnet.com (Heide, Marc)
Date: Thu, 4 May 2017 09:10:03 +0000
Subject: [keycloak-dev] KEYCLOAK-4521: Error getting userinfo via access
 token obtained by offline token
In-Reply-To: <CAJgngAeQ+VLYmrKcf8fH8wyquE2Rx1MCCMyRQKTSfLacXCjtPQ@mail.gmail.com>
References: <0A9F064B-3E15-4100-B533-382C190BF12E@365farmnet.com>
	<CAJgngAeQ+VLYmrKcf8fH8wyquE2Rx1MCCMyRQKTSfLacXCjtPQ@mail.gmail.com>
Message-ID: <D9053296-32B5-4D8D-B5FE-BD19D9711C69@365farmnet.com>

Hi,

Could you give me a hint which kind of test you would expect?
Currently I struggle with even finding a test for this user info endpoint. Is there any?

Best Regards
Marc

>Am 03.05.17, 14:55 schrieb "Stian Thorgersen" <sthorger at redhat.com>:

>    PR would be welcome, but please remember to add a test with the PR.
    

    





From mposolda at redhat.com  Thu May  4 05:26:07 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 4 May 2017 11:26:07 +0200
Subject: [keycloak-dev] KEYCLOAK-4521: Error getting userinfo via access
 token obtained by offline token
In-Reply-To: <D9053296-32B5-4D8D-B5FE-BD19D9711C69@365farmnet.com>
References: <0A9F064B-3E15-4100-B533-382C190BF12E@365farmnet.com>
	<CAJgngAeQ+VLYmrKcf8fH8wyquE2Rx1MCCMyRQKTSfLacXCjtPQ@mail.gmail.com>
	<D9053296-32B5-4D8D-B5FE-BD19D9711C69@365farmnet.com>
Message-ID: <acba39c2-03ea-3a13-491f-2eefb322b444@redhat.com>

UserInfoTest . You can also take a look at OfflineTokenTest for some 
inspiration for how to test offline tokens.

Marek

On 04/05/17 11:10, Heide, Marc wrote:
> Hi,
>
> Could you give me a hint which kind of test you would expect?
> Currently I struggle with even finding a test for this user info endpoint. Is there any?
>
> Best Regards
> Marc
>
>> Am 03.05.17, 14:55 schrieb "Stian Thorgersen" <sthorger at redhat.com>:
>>     PR would be welcome, but please remember to add a test with the PR.
>      
>
>      
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Thu May  4 05:26:20 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 4 May 2017 11:26:20 +0200
Subject: [keycloak-dev] KEYCLOAK-4521: Error getting userinfo via access
 token obtained by offline token
In-Reply-To: <D9053296-32B5-4D8D-B5FE-BD19D9711C69@365farmnet.com>
References: <0A9F064B-3E15-4100-B533-382C190BF12E@365farmnet.com>
	<CAJgngAeQ+VLYmrKcf8fH8wyquE2Rx1MCCMyRQKTSfLacXCjtPQ@mail.gmail.com>
	<D9053296-32B5-4D8D-B5FE-BD19D9711C69@365farmnet.com>
Message-ID: <CAJgngAfZKXFegbxKGkSBFeO_jP2zTK0ryyAqSHquUd6169u0AA@mail.gmail.com>

This is probably the best candidate:
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/oidc/UserInfoTest.java

On 4 May 2017 at 11:10, Heide, Marc <heide at 365farmnet.com> wrote:

> Hi,
>
> Could you give me a hint which kind of test you would expect?
> Currently I struggle with even finding a test for this user info endpoint.
> Is there any?
>
> Best Regards
> Marc
>
> >Am 03.05.17, 14:55 schrieb "Stian Thorgersen" <sthorger at redhat.com>:
>
> >    PR would be welcome, but please remember to add a test with the PR.
>
>
>
>
>
>
>

From sthorger at redhat.com  Fri May  5 05:06:45 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 May 2017 11:06:45 +0200
Subject: [keycloak-dev] Update to WildFly 11 for 3.2
Message-ID: <CAJgngAdpkMFiufVAsrLnPnqNzbCSyNSgz=q77o8fop3CrGe74g@mail.gmail.com>

WildFly 11 is due to be released before we are releasing Keycloak 3.2.

I would like to upgrade to WildFly 11 Alpha11 now so we can see if we find
any issues with the plan that we will upgrade to WildFly 11 Final before we
release Keycloak 3.2.0.Final.

There's a slight chance that it would be delayed, but in that case we can
simply delay 3.2.

Any objections? Or can I go ahead and upgrade master?

From psilva at redhat.com  Fri May  5 10:56:12 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 May 2017 11:56:12 -0300
Subject: [keycloak-dev] Update to WildFly 11 for 3.2
In-Reply-To: <CAJgngAdpkMFiufVAsrLnPnqNzbCSyNSgz=q77o8fop3CrGe74g@mail.gmail.com>
References: <CAJgngAdpkMFiufVAsrLnPnqNzbCSyNSgz=q77o8fop3CrGe74g@mail.gmail.com>
Message-ID: <CAJrcDBdbCnX=2LcJJCpdawKFfF1mrev-asNROMrc=6Jas1k_Pg@mail.gmail.com>

Are all dependencies available ? Didn't find wildfly-core dependencies in
Maven central .... But only wildfly-dist.

On Fri, May 5, 2017 at 6:06 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> WildFly 11 is due to be released before we are releasing Keycloak 3.2.
>
> I would like to upgrade to WildFly 11 Alpha11 now so we can see if we find
> any issues with the plan that we will upgrade to WildFly 11 Final before we
> release Keycloak 3.2.0.Final.
>
> There's a slight chance that it would be delayed, but in that case we can
> simply delay 3.2.
>
> Any objections? Or can I go ahead and upgrade master?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From tonymwinters at me.com  Fri May  5 13:38:10 2017
From: tonymwinters at me.com (Tony Winters)
Date: Fri, 05 May 2017 13:38:10 -0400
Subject: [keycloak-dev] GoLang Adapter
Message-ID: <A835EA8C-E66F-4EFD-979D-9F9A75E02212@me.com>

I was just at the RedHat Summit this week and during the Keycloak session, it was mentioned that there wasn?t a GoLang adapter yet. I?d be interested in tackling this if there is a need. What is the process to get this started? We actually have an application written in GoLang that will need to be secured once we go live with Keycloak company wide (scheduled go-live within the next several months).

Tony Winters

From bburke at redhat.com  Fri May  5 14:34:50 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 5 May 2017 14:34:50 -0400
Subject: [keycloak-dev] GoLang Adapter
In-Reply-To: <A835EA8C-E66F-4EFD-979D-9F9A75E02212@me.com>
References: <A835EA8C-E66F-4EFD-979D-9F9A75E02212@me.com>
Message-ID: <0c4a4ca6-dc06-aaf6-757d-730f15779197@redhat.com>

https://github.com/coreos/go-oidc  might be a good start?

You could expand it to make sure it understands our access token format 
(i.e.roles) and can handle our extensions (backchannel logut and other 
events, the CORS support we have in other adapters, etc...)

Then we'd probably create a repo for you once its ready, or we can do 
that right away too, up to you.



On 5/5/17 1:38 PM, Tony Winters wrote:
> I was just at the RedHat Summit this week and during the Keycloak session, it was mentioned that there wasn?t a GoLang adapter yet. I?d be interested in tackling this if there is a need. What is the process to get this started? We actually have an application written in GoLang that will need to be secured once we go live with Keycloak company wide (scheduled go-live within the next several months).
>
> Tony Winters
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Fri May  5 21:51:41 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 5 May 2017 22:51:41 -0300
Subject: [keycloak-dev] Cross-DC Support
Message-ID: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>

Hey All,

Is it fair to say that using invalidation events via ClusterProvider is
enough to get Cross-DC support ?

Regards.
Pedro Igor

From sthorger at redhat.com  Mon May  8 02:26:53 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 May 2017 08:26:53 +0200
Subject: [keycloak-dev] Cross-DC Support
In-Reply-To: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>
References: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>
Message-ID: <CAJgngAeh5EQZPxW2vPs4jkwgMmRyFqZXdOYOzPdu3Y3jo0ehXA@mail.gmail.com>

Marek can probably answer that in more detail. However, IMO the caches for
authorization services should be done exactly as the other invalidation
caches. We've done a lot of tweaks here to get it to work properly and it's
complex stuff so we don't want to have two different approaches in the code.

On 6 May 2017 at 03:51, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hey All,
>
> Is it fair to say that using invalidation events via ClusterProvider is
> enough to get Cross-DC support ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May  8 02:28:10 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 May 2017 08:28:10 +0200
Subject: [keycloak-dev] GoLang Adapter
In-Reply-To: <0c4a4ca6-dc06-aaf6-757d-730f15779197@redhat.com>
References: <A835EA8C-E66F-4EFD-979D-9F9A75E02212@me.com>
	<0c4a4ca6-dc06-aaf6-757d-730f15779197@redhat.com>
Message-ID: <CAJgngAe5hD5mvPirAJQqPypYkGsEEeV7-dNu_k1VQJZ=K6sivA@mail.gmail.com>

Sebastien is planning to create a blueprint of adapters including test
coverage. That would probably be very useful when creating a new adapter.

On 5 May 2017 at 20:34, Bill Burke <bburke at redhat.com> wrote:

> https://github.com/coreos/go-oidc  might be a good start?
>
> You could expand it to make sure it understands our access token format
> (i.e.roles) and can handle our extensions (backchannel logut and other
> events, the CORS support we have in other adapters, etc...)
>
> Then we'd probably create a repo for you once its ready, or we can do
> that right away too, up to you.
>
>
>
> On 5/5/17 1:38 PM, Tony Winters wrote:
> > I was just at the RedHat Summit this week and during the Keycloak
> session, it was mentioned that there wasn?t a GoLang adapter yet. I?d be
> interested in tackling this if there is a need. What is the process to get
> this started? We actually have an application written in GoLang that will
> need to be secured once we go live with Keycloak company wide (scheduled
> go-live within the next several months).
> >
> > Tony Winters
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May  8 02:29:42 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 May 2017 08:29:42 +0200
Subject: [keycloak-dev] Update to WildFly 11 for 3.2
In-Reply-To: <CAJrcDBdbCnX=2LcJJCpdawKFfF1mrev-asNROMrc=6Jas1k_Pg@mail.gmail.com>
References: <CAJgngAdpkMFiufVAsrLnPnqNzbCSyNSgz=q77o8fop3CrGe74g@mail.gmail.com>
	<CAJrcDBdbCnX=2LcJJCpdawKFfF1mrev-asNROMrc=6Jas1k_Pg@mail.gmail.com>
Message-ID: <CAJgngAfDiJacgctrdLx_AwqqSjKd_9+Ks9N7TK2Z_6mJOqnXGg@mail.gmail.com>

Not sure, but you can already build KC server with WF11 Alpha1 by running:

mvn clean install -Pwf11 -Pdistribution

At least the feature pack is there.

On 5 May 2017 at 16:56, Pedro Igor Silva <psilva at redhat.com> wrote:

> Are all dependencies available ? Didn't find wildfly-core dependencies in
> Maven central .... But only wildfly-dist.
>
> On Fri, May 5, 2017 at 6:06 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> WildFly 11 is due to be released before we are releasing Keycloak 3.2.
>>
>> I would like to upgrade to WildFly 11 Alpha11 now so we can see if we find
>> any issues with the plan that we will upgrade to WildFly 11 Final before
>> we
>> release Keycloak 3.2.0.Final.
>>
>> There's a slight chance that it would be delayed, but in that case we can
>> simply delay 3.2.
>>
>> Any objections? Or can I go ahead and upgrade master?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Mon May  8 02:55:46 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 May 2017 08:55:46 +0200
Subject: [keycloak-dev] Update to WildFly 11 for 3.2
In-Reply-To: <CAJgngAfDiJacgctrdLx_AwqqSjKd_9+Ks9N7TK2Z_6mJOqnXGg@mail.gmail.com>
References: <CAJgngAdpkMFiufVAsrLnPnqNzbCSyNSgz=q77o8fop3CrGe74g@mail.gmail.com>
	<CAJrcDBdbCnX=2LcJJCpdawKFfF1mrev-asNROMrc=6Jas1k_Pg@mail.gmail.com>
	<CAJgngAfDiJacgctrdLx_AwqqSjKd_9+Ks9N7TK2Z_6mJOqnXGg@mail.gmail.com>
Message-ID: <CAJgngAdry0=Pto57fy31AgvZO3bdwh+OQrJR2dd72=HnPaYCCg@mail.gmail.com>

There's an issue with X509 auth as it relies on a method [1] that has been
renamed in Bouncycastle 1.52 to 1.56. Both EAP 7.1 and WF11 use BC 1.56,
while WF10 use 1.52.

I can't merge it to master until we bump to WF11.

[1]
https://github.com/keycloak/keycloak/commit/a62213137c942580b6b8980585da455bd1490d8a

On 8 May 2017 at 08:29, Stian Thorgersen <sthorger at redhat.com> wrote:

> Not sure, but you can already build KC server with WF11 Alpha1 by running:
>
> mvn clean install -Pwf11 -Pdistribution
>
> At least the feature pack is there.
>
> On 5 May 2017 at 16:56, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Are all dependencies available ? Didn't find wildfly-core dependencies in
>> Maven central .... But only wildfly-dist.
>>
>> On Fri, May 5, 2017 at 6:06 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> WildFly 11 is due to be released before we are releasing Keycloak 3.2.
>>>
>>> I would like to upgrade to WildFly 11 Alpha11 now so we can see if we
>>> find
>>> any issues with the plan that we will upgrade to WildFly 11 Final before
>>> we
>>> release Keycloak 3.2.0.Final.
>>>
>>> There's a slight chance that it would be delayed, but in that case we can
>>> simply delay 3.2.
>>>
>>> Any objections? Or can I go ahead and upgrade master?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From wim.vandenhaute at gmail.com  Mon May  8 05:36:46 2017
From: wim.vandenhaute at gmail.com (Wim Vandenhaute)
Date: Mon, 08 May 2017 09:36:46 +0000
Subject: [keycloak-dev] Migration from 2.4.0 to 2.5.5
Message-ID: <CAAmmoOogeUZ4cv0AwKD+f0NWWdNsfdGZbYUhrkoduaZH91ETag@mail.gmail.com>

Hello list,

When migrating a custom user federation provider it seems the
validateAndProxy callback from the UserFederationProvider SPI no longer has
an alternative since it has been removed.
Before whenever a UserModel was pulled from Keycloak, this callback was
made and our custom user federation provider could add some transient
attributes each time.

In 2.5.5 it is my understanding that implementing the
ImportedUserValidation SPI is the way to go yet whenever the
authorization/access code is exchanged (
TokenEndpoint.buildAuthorizationCodeAccessTokenResponse ) the
ImportedUserValidation.validate is never called as the UserSessionAdapter
always goes straight to the UserCacheSession userprovider implementation
instead of the UserStorageManager.
Before whenever the TokenEndpoint was called, it always went to the
UserFederationManager class which fetched the UserModel but afterwards
check if the user had a federation link and  then called the
UserFederationProvider.validateAndProxy hook.

So my questions are:

1. What is the right way to go to make sure a customer user federation
provider can always add some custom attributes to the UserModel via a
delegate, even if the UserModel comes from the keycloak cache.

2. Or do we have to disable the keycloak cache for this and if so how?

Kind regards,
Wim.

From psilva at redhat.com  Mon May  8 07:08:31 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 8 May 2017 08:08:31 -0300
Subject: [keycloak-dev] Cross-DC Support
In-Reply-To: <CAJgngAeh5EQZPxW2vPs4jkwgMmRyFqZXdOYOzPdu3Y3jo0ehXA@mail.gmail.com>
References: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>
	<CAJgngAeh5EQZPxW2vPs4jkwgMmRyFqZXdOYOzPdu3Y3jo0ehXA@mail.gmail.com>
Message-ID: <CAJrcDBcSRjSHX-PSkXrpb8XA-a0WgiXudd3wyU6=jS1-Pr9yCQ@mail.gmail.com>

That is why I'm asking. I have been working with some changes to authz
cache layer to get it aligned with the rest of the project. I've a PR
already with some initial changes at this regard, where I'm basically
pushing usage of invalidation events via cluster provider. Besides, I have
also changed cache mode for authz cache to local. We don't really need to
replicate/distribute entries across nodes, but cache things locally and
invalidate these same accordingly.

On Mon, May 8, 2017 at 3:26 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Marek can probably answer that in more detail. However, IMO the caches for
> authorization services should be done exactly as the other invalidation
> caches. We've done a lot of tweaks here to get it to work properly and it's
> complex stuff so we don't want to have two different approaches in the code.
>
> On 6 May 2017 at 03:51, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hey All,
>>
>> Is it fair to say that using invalidation events via ClusterProvider is
>> enough to get Cross-DC support ?
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Mon May  8 08:48:10 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 May 2017 14:48:10 +0200
Subject: [keycloak-dev] Compilation error in master (SAMLParserTest)
Message-ID: <CAJgngAc59efcobqTr1pOwz+8kK3ZH1PiyZxjqn6033cU7=Y67Q@mail.gmail.com>

At the moment there's a compilation error trying to build master. This is
caused by an issue in SAMLParserTest. It was not caught by Travis because
it doesn't run unit tests at all.

I've updated Travis so it runs unit tests and fixed the compilation error
in PR:
https://github.com/keycloak/keycloak/pull/4119

Just waiting for it to pass then I'll merge.

From sthorger at redhat.com  Mon May  8 10:00:55 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 May 2017 16:00:55 +0200
Subject: [keycloak-dev] Compilation error in master (SAMLParserTest)
In-Reply-To: <CAJgngAc59efcobqTr1pOwz+8kK3ZH1PiyZxjqn6033cU7=Y67Q@mail.gmail.com>
References: <CAJgngAc59efcobqTr1pOwz+8kK3ZH1PiyZxjqn6033cU7=Y67Q@mail.gmail.com>
Message-ID: <CAJgngAdenGHked8=Drk4jibU5x=bMXgwhX42rLfpBNp+YaRvPQ@mail.gmail.com>

Fixed

On 8 May 2017 at 14:48, Stian Thorgersen <sthorger at redhat.com> wrote:

> At the moment there's a compilation error trying to build master. This is
> caused by an issue in SAMLParserTest. It was not caught by Travis because
> it doesn't run unit tests at all.
>
> I've updated Travis so it runs unit tests and fixed the compilation error
> in PR:
> https://github.com/keycloak/keycloak/pull/4119
>
> Just waiting for it to pass then I'll merge.
>

From mposolda at redhat.com  Tue May  9 02:44:06 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 May 2017 08:44:06 +0200
Subject: [keycloak-dev] Cross-DC Support
In-Reply-To: <CAJrcDBcSRjSHX-PSkXrpb8XA-a0WgiXudd3wyU6=jS1-Pr9yCQ@mail.gmail.com>
References: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>
	<CAJgngAeh5EQZPxW2vPs4jkwgMmRyFqZXdOYOzPdu3Y3jo0ehXA@mail.gmail.com>
	<CAJrcDBcSRjSHX-PSkXrpb8XA-a0WgiXudd3wyU6=jS1-Pr9yCQ@mail.gmail.com>
Message-ID: <bb23e1d4-0f58-2acb-7a65-49ce605cded7@redhat.com>

I think that should be sufficient for Cross-DC support.

Pedro, if you want to try some basic testing of cross-dc, here are some 
simple instructions: 
https://github.com/keycloak/keycloak/blob/master/misc/CrossDataCenter.md

For the development, there is even easier way to test with 2 embedded 
KeycloakServer instances (class KeycloakServer from the old testsuite) 
if you run the KeycloakServer with the properties like this (replace 
with your shared DB): 
-Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak 
-Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver 
-Dkeycloak.connectionsJpa.user=keycloak 
-Dkeycloak.connectionsJpa.password=keycloak 
-Dkeycloak.connectionsInfinispan.remoteStoreEnabled=true 
-Dkeycloak.connectionsInfinispan.remoteStoreHost=localhost 
-Dkeycloak.connectionsInfinispan.remoteStorePort=11322

You just need to run 2 servers on different ports, which is argument 
like "-p 8081" .

Marek

On 08/05/17 13:08, Pedro Igor Silva wrote:
> That is why I'm asking. I have been working with some changes to authz
> cache layer to get it aligned with the rest of the project. I've a PR
> already with some initial changes at this regard, where I'm basically
> pushing usage of invalidation events via cluster provider. Besides, I have
> also changed cache mode for authz cache to local. We don't really need to
> replicate/distribute entries across nodes, but cache things locally and
> invalidate these same accordingly.
>
> On Mon, May 8, 2017 at 3:26 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Marek can probably answer that in more detail. However, IMO the caches for
>> authorization services should be done exactly as the other invalidation
>> caches. We've done a lot of tweaks here to get it to work properly and it's
>> complex stuff so we don't want to have two different approaches in the code.
>>
>> On 6 May 2017 at 03:51, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Hey All,
>>>
>>> Is it fair to say that using invalidation events via ClusterProvider is
>>> enough to get Cross-DC support ?
>>>
>>> Regards.
>>> Pedro Igor
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From psilva at redhat.com  Tue May  9 07:33:38 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 9 May 2017 08:33:38 -0300
Subject: [keycloak-dev] Cross-DC Support
In-Reply-To: <bb23e1d4-0f58-2acb-7a65-49ce605cded7@redhat.com>
References: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>
	<CAJgngAeh5EQZPxW2vPs4jkwgMmRyFqZXdOYOzPdu3Y3jo0ehXA@mail.gmail.com>
	<CAJrcDBcSRjSHX-PSkXrpb8XA-a0WgiXudd3wyU6=jS1-Pr9yCQ@mail.gmail.com>
	<bb23e1d4-0f58-2acb-7a65-49ce605cded7@redhat.com>
Message-ID: <CAJrcDBdPhz3_NGvERgcbASQTXwWeMkFKNsx4YS1hgyLaq9ssiw@mail.gmail.com>

Thanks, Marek. Will follow instructions there to check how things are
working when enabling a remote store with JDG.

I've also changed the authz cache mode to local, what I think makes more
sense than use a distributed cache as it stands today. We basically want to
cache things locally and invalidate entries accordingly to avoid stale
entries across nodes.

On Tue, May 9, 2017 at 3:44 AM, Marek Posolda <mposolda at redhat.com> wrote:

> I think that should be sufficient for Cross-DC support.
>
> Pedro, if you want to try some basic testing of cross-dc, here are some
> simple instructions: https://github.com/keycloak/ke
> ycloak/blob/master/misc/CrossDataCenter.md
>
> For the development, there is even easier way to test with 2 embedded
> KeycloakServer instances (class KeycloakServer from the old testsuite) if
> you run the KeycloakServer with the properties like this (replace with your
> shared DB): -Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak
> -Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver
> -Dkeycloak.connectionsJpa.user=keycloak -Dkeycloak.connectionsJpa.password=keycloak
> -Dkeycloak.connectionsInfinispan.remoteStoreEnabled=true
> -Dkeycloak.connectionsInfinispan.remoteStoreHost=localhost
> -Dkeycloak.connectionsInfinispan.remoteStorePort=11322
>
> You just need to run 2 servers on different ports, which is argument like
> "-p 8081" .
>
> Marek
>
>
> On 08/05/17 13:08, Pedro Igor Silva wrote:
>
>> That is why I'm asking. I have been working with some changes to authz
>> cache layer to get it aligned with the rest of the project. I've a PR
>> already with some initial changes at this regard, where I'm basically
>> pushing usage of invalidation events via cluster provider. Besides, I have
>> also changed cache mode for authz cache to local. We don't really need to
>> replicate/distribute entries across nodes, but cache things locally and
>> invalidate these same accordingly.
>>
>> On Mon, May 8, 2017 at 3:26 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>> Marek can probably answer that in more detail. However, IMO the caches for
>>> authorization services should be done exactly as the other invalidation
>>> caches. We've done a lot of tweaks here to get it to work properly and
>>> it's
>>> complex stuff so we don't want to have two different approaches in the
>>> code.
>>>
>>> On 6 May 2017 at 03:51, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>> Hey All,
>>>>
>>>> Is it fair to say that using invalidation events via ClusterProvider is
>>>> enough to get Cross-DC support ?
>>>>
>>>> Regards.
>>>> Pedro Igor
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From mposolda at redhat.com  Tue May  9 08:00:37 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 9 May 2017 14:00:37 +0200
Subject: [keycloak-dev] Cross-DC Support
In-Reply-To: <CAJrcDBdPhz3_NGvERgcbASQTXwWeMkFKNsx4YS1hgyLaq9ssiw@mail.gmail.com>
References: <CAJrcDBcRqyGkM9JZDh8EXfHBd0oezYEZ18Pi+3+uUG+NGnbHMA@mail.gmail.com>
	<CAJgngAeh5EQZPxW2vPs4jkwgMmRyFqZXdOYOzPdu3Y3jo0ehXA@mail.gmail.com>
	<CAJrcDBcSRjSHX-PSkXrpb8XA-a0WgiXudd3wyU6=jS1-Pr9yCQ@mail.gmail.com>
	<bb23e1d4-0f58-2acb-7a65-49ce605cded7@redhat.com>
	<CAJrcDBdPhz3_NGvERgcbASQTXwWeMkFKNsx4YS1hgyLaq9ssiw@mail.gmail.com>
Message-ID: <c7184586-8d96-250b-dffb-bfe536af1414@redhat.com>

On 09/05/17 13:33, Pedro Igor Silva wrote:
> Thanks, Marek. Will follow instructions there to check how things are 
> working when enabling a remote store with JDG.
>
> I've also changed the authz cache mode to local, what I think makes 
> more sense than use a distributed cache as it stands today. We 
> basically want to cache things locally and invalidate entries 
> accordingly to avoid stale entries across nodes.
+1

I left some minor comment in your PR regarding this. We have more places 
in the distribution where the infinispan caches needs to be configured 
for various distributions (server-dist, demo-dist, overlay, domain mode 
etc) and looks you forgot one of the locations. Maybe we can improve 
this to have single place where infinispan caches are configured for 
non-clustered or clustered mode and all the distribution builds will use 
this. This will help to avoid potential consistency issues like this. 
But that's not the case for now...

Marek
>
> On Tue, May 9, 2017 at 3:44 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I think that should be sufficient for Cross-DC support.
>
>     Pedro, if you want to try some basic testing of cross-dc, here are
>     some simple instructions:
>     https://github.com/keycloak/keycloak/blob/master/misc/CrossDataCenter.md
>     <https://github.com/keycloak/keycloak/blob/master/misc/CrossDataCenter.md>
>
>     For the development, there is even easier way to test with 2
>     embedded KeycloakServer instances (class KeycloakServer from the
>     old testsuite) if you run the KeycloakServer with the properties
>     like this (replace with your shared DB):
>     -Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak
>     -Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver
>     -Dkeycloak.connectionsJpa.user=keycloak
>     -Dkeycloak.connectionsJpa.password=keycloak
>     -Dkeycloak.connectionsInfinispan.remoteStoreEnabled=true
>     -Dkeycloak.connectionsInfinispan.remoteStoreHost=localhost
>     -Dkeycloak.connectionsInfinispan.remoteStorePort=11322
>
>     You just need to run 2 servers on different ports, which is
>     argument like "-p 8081" .
>
>     Marek
>
>
>     On 08/05/17 13:08, Pedro Igor Silva wrote:
>
>         That is why I'm asking. I have been working with some changes
>         to authz
>         cache layer to get it aligned with the rest of the project.
>         I've a PR
>         already with some initial changes at this regard, where I'm
>         basically
>         pushing usage of invalidation events via cluster provider.
>         Besides, I have
>         also changed cache mode for authz cache to local. We don't
>         really need to
>         replicate/distribute entries across nodes, but cache things
>         locally and
>         invalidate these same accordingly.
>
>         On Mon, May 8, 2017 at 3:26 AM, Stian Thorgersen
>         <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>         wrote:
>
>             Marek can probably answer that in more detail. However,
>             IMO the caches for
>             authorization services should be done exactly as the other
>             invalidation
>             caches. We've done a lot of tweaks here to get it to work
>             properly and it's
>             complex stuff so we don't want to have two different
>             approaches in the code.
>
>             On 6 May 2017 at 03:51, Pedro Igor Silva
>             <psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
>
>                 Hey All,
>
>                 Is it fair to say that using invalidation events via
>                 ClusterProvider is
>                 enough to get Cross-DC support ?
>
>                 Regards.
>                 Pedro Igor
>                 _______________________________________________
>                 keycloak-dev mailing list
>                 keycloak-dev at lists.jboss.org
>                 <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>


From sblanc at redhat.com  Tue May  9 10:15:44 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 9 May 2017 16:15:44 +0200
Subject: [keycloak-dev] Adapter's blueprint
Message-ID: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>

Hi !

I've started this sheet [1] that attempt to list all the features and
checks that a Keycloak adapter should support + a support matrix for our
existing adapters.

Feel free to add any missing feature, it's a really early version started a
few hours ago,

Sebi
[1]
https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHORqIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing

From ssilvert at redhat.com  Tue May  9 13:45:12 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 9 May 2017 13:45:12 -0400
Subject: [keycloak-dev] Adapter's blueprint
In-Reply-To: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
References: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
Message-ID: <8f8ecdf8-1e12-56eb-365d-45e0d5170ce0@redhat.com>

Very glad to see that effort Sebastien.  We really need the specs.

On 5/9/2017 10:15 AM, Sebastien Blanc wrote:
> Hi !
>
> I've started this sheet [1] that attempt to list all the features and
> checks that a Keycloak adapter should support + a support matrix for our
> existing adapters.
>
> Feel free to add any missing feature, it's a really early version started a
> few hours ago,
>
> Sebi
> [1]
> https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHORqIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Tue May  9 17:00:42 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 9 May 2017 18:00:42 -0300
Subject: [keycloak-dev] Adapter's blueprint
In-Reply-To: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
References: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
Message-ID: <20170509210042.GB13745@abstractj.org>

This is a great start Sebi. And I think we can always change along the
way.

I was just thinking here about something for the future, maybe. A way to
certify our Keycloak adapter's implementation. This idea came from
OpenID connect certification[1].

Why? In this way people could run conformance tests against our server
and make sure that their implementation is still compatible with the
latest releases of Keycloak. This also would enable us to know which
project is stable or not.

I know this could be a lot of work, but maybe something we could work/take into
consideration for further releases.

[1] - http://openid.net/certification/testing/

On 2017-05-09, Sebastien Blanc wrote:
> Hi !
>
> I've started this sheet [1] that attempt to list all the features and
> checks that a Keycloak adapter should support + a support matrix for our
> existing adapters.
>
> Feel free to add any missing feature, it's a really early version started a
> few hours ago,
>
> Sebi
> [1]
> https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHORqIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From vmuzikar at redhat.com  Wed May 10 05:20:56 2017
From: vmuzikar at redhat.com (Vaclav Muzikar)
Date: Wed, 10 May 2017 11:20:56 +0200
Subject: [keycloak-dev] Adapter's blueprint
In-Reply-To: <20170509210042.GB13745@abstractj.org>
References: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
	<20170509210042.GB13745@abstractj.org>
Message-ID: <CAMQSZyijTQNrqx2sohk2uQd_wTtjW9wT37r4LctXr=4gUMxZAw@mail.gmail.com>

+1
I think that's a great idea! However, not sure about implementation
possibilities for such conformance testsuite since the adapters are often
platform/framework/language specific. Perhaps some unified test app(s)
which could be protected by any adapter?

On Tue, May 9, 2017 at 11:00 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> This is a great start Sebi. And I think we can always change along the
> way.
>
> I was just thinking here about something for the future, maybe. A way to
> certify our Keycloak adapter's implementation. This idea came from
> OpenID connect certification[1].
>
> Why? In this way people could run conformance tests against our server
> and make sure that their implementation is still compatible with the
> latest releases of Keycloak. This also would enable us to know which
> project is stable or not.
>
> I know this could be a lot of work, but maybe something we could work/take
> into
> consideration for further releases.
>
> [1] - http://openid.net/certification/testing/
>
> On 2017-05-09, Sebastien Blanc wrote:
> > Hi !
> >
> > I've started this sheet [1] that attempt to list all the features and
> > checks that a Keycloak adapter should support + a support matrix for our
> > existing adapters.
> >
> > Feel free to add any missing feature, it's a really early version
> started a
> > few hours ago,
> >
> > Sebi
> > [1]
> > https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHOR
> qIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
V?clav Muzik??
Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

From sblanc at redhat.com  Wed May 10 05:46:19 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 10 May 2017 11:46:19 +0200
Subject: [keycloak-dev] Adapter's blueprint
In-Reply-To: <CAMQSZyijTQNrqx2sohk2uQd_wTtjW9wT37r4LctXr=4gUMxZAw@mail.gmail.com>
References: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
	<20170509210042.GB13745@abstractj.org>
	<CAMQSZyijTQNrqx2sohk2uQd_wTtjW9wT37r4LctXr=4gUMxZAw@mail.gmail.com>
Message-ID: <CAMZCGg8uYA62Sr00p8KwQk8W1tQmtwzLS-MhvCqWkbMt0opinA@mail.gmail.com>

Yes it's a great idea and I tried to word the specs as test requirements
"Should ..." .

Regarding unified tests apps, yes, something around functional test could
do it.
For instance, if you look at these tests
https://github.com/keycloak/keycloak-quickstarts/blob/master/service-jee-jaxrs/src/test/java/org/keycloak/quickstart/jaxrs/ArquillianServiceJeeJaxrsTest.java
, even if it's written in Java, it's pretty agnostic against which secured
back end it runs ... Some there is definitely some space for that.

But first, let's make sure we have a complete and curated list of
specifications.


On Wed, May 10, 2017 at 11:20 AM, Vaclav Muzikar <vmuzikar at redhat.com>
wrote:

> +1
> I think that's a great idea! However, not sure about implementation
> possibilities for such conformance testsuite since the adapters are often
> platform/framework/language specific. Perhaps some unified test app(s)
> which could be protected by any adapter?
>
> On Tue, May 9, 2017 at 11:00 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > This is a great start Sebi. And I think we can always change along the
> > way.
> >
> > I was just thinking here about something for the future, maybe. A way to
> > certify our Keycloak adapter's implementation. This idea came from
> > OpenID connect certification[1].
> >
> > Why? In this way people could run conformance tests against our server
> > and make sure that their implementation is still compatible with the
> > latest releases of Keycloak. This also would enable us to know which
> > project is stable or not.
> >
> > I know this could be a lot of work, but maybe something we could
> work/take
> > into
> > consideration for further releases.
> >
> > [1] - http://openid.net/certification/testing/
> >
> > On 2017-05-09, Sebastien Blanc wrote:
> > > Hi !
> > >
> > > I've started this sheet [1] that attempt to list all the features and
> > > checks that a Keycloak adapter should support + a support matrix for
> our
> > > existing adapters.
> > >
> > > Feel free to add any missing feature, it's a really early version
> > started a
> > > few hours ago,
> > >
> > > Sebi
> > > [1]
> > > https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHOR
> > qIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
>
>
> --
> V?clav Muzik??
> Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sblanc at redhat.com  Wed May 10 05:56:26 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 10 May 2017 11:56:26 +0200
Subject: [keycloak-dev] GoLang Adapter
In-Reply-To: <CAJgngAe5hD5mvPirAJQqPypYkGsEEeV7-dNu_k1VQJZ=K6sivA@mail.gmail.com>
References: <A835EA8C-E66F-4EFD-979D-9F9A75E02212@me.com>
	<0c4a4ca6-dc06-aaf6-757d-730f15779197@redhat.com>
	<CAJgngAe5hD5mvPirAJQqPypYkGsEEeV7-dNu_k1VQJZ=K6sivA@mail.gmail.com>
Message-ID: <CAMZCGg_5MKuKaTRvFuw0Vp0XsKVh2Md3q6SgCtX9xHy6egg=zg@mail.gmail.com>

Tony, glad I could convince you ;)

As Bill said, taking as base an existing Go OIDC lib is the easiest to get
into it. Blog post like this one from our "competitor" ;)
https://auth0.com/blog/authentication-in-golang/ could also help

Regarding the adapter blueprint,  I started this document here
https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHORqIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing

On Mon, May 8, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Sebastien is planning to create a blueprint of adapters including test
> coverage. That would probably be very useful when creating a new adapter.
>
> On 5 May 2017 at 20:34, Bill Burke <bburke at redhat.com> wrote:
>
>> https://github.com/coreos/go-oidc  might be a good start?
>>
>> You could expand it to make sure it understands our access token format
>> (i.e.roles) and can handle our extensions (backchannel logut and other
>> events, the CORS support we have in other adapters, etc...)
>>
>> Then we'd probably create a repo for you once its ready, or we can do
>> that right away too, up to you.
>>
>>
>>
>> On 5/5/17 1:38 PM, Tony Winters wrote:
>> > I was just at the RedHat Summit this week and during the Keycloak
>> session, it was mentioned that there wasn?t a GoLang adapter yet. I?d be
>> interested in tackling this if there is a need. What is the process to get
>> this started? We actually have an application written in GoLang that will
>> need to be secured once we go live with Keycloak company wide (scheduled
>> go-live within the next several months).
>> >
>> > Tony Winters
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From ssilvert at redhat.com  Wed May 10 13:03:39 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 10 May 2017 13:03:39 -0400
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
Message-ID: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>

The very thought of $subject seems like heresy.  Why check in something 
that is normally pulled using npm?

We have Angular 2 examples in Keycloak now.  In the not-too-distant 
future, our Account Management console will be written in Angular 2.  So 
node_modules has to be there somehow.

There are basically two options:
1)  Merge node_modules into the Keycloak repo.
2)  Don't merge and then run npm install at build time.

Productization standards push toward option #1.  We need to have 
consistent, repeatable builds.

But I'm looking for reasons that #1 might be bad.  I can't come up with 
a rational reason to do #2 except that it saves disk space.

Any thoughts?

From thomas.darimont at googlemail.com  Wed May 10 13:43:34 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 10 May 2017 19:43:34 +0200
Subject: [keycloak-dev] GoLang Adapter
In-Reply-To: <CAMZCGg_5MKuKaTRvFuw0Vp0XsKVh2Md3q6SgCtX9xHy6egg=zg@mail.gmail.com>
References: <A835EA8C-E66F-4EFD-979D-9F9A75E02212@me.com>
	<0c4a4ca6-dc06-aaf6-757d-730f15779197@redhat.com>
	<CAJgngAe5hD5mvPirAJQqPypYkGsEEeV7-dNu_k1VQJZ=K6sivA@mail.gmail.com>
	<CAMZCGg_5MKuKaTRvFuw0Vp0XsKVh2Md3q6SgCtX9xHy6egg=zg@mail.gmail.com>
Message-ID: <CAK-7U1iLsRFqQg077B2Pj12PNZzS4tC8OvYsnJu2vGr2CU9Kvg@mail.gmail.com>

Hi folks,

another option for using Keycloak with go is the 'goth' library which
integrates
with multiple auth providers.

https://github.com/markbates/goth

To run the example app with Keycloak one simply needs to
build the example and run it with:

# client id
export OPENID_CONNECT_KEY=goth-demo
# client secret
export OPENID_CONNECT_SECRET=efb3f804-811d-411e-af66-a34f8d5cc02c
export OPENID_CONNECT_DISCOVERY_URL=
http://localhost:8081/auth/realms/golang-goth-demo/.well-known/openid-configuration

./example

The OIDC specific stuff is implemented here:
https://github.com/markbates/goth/tree/master/providers/openidConnect

Cheers,
Thomas

2017-05-10 11:56 GMT+02:00 Sebastien Blanc <sblanc at redhat.com>:

> Tony, glad I could convince you ;)
>
> As Bill said, taking as base an existing Go OIDC lib is the easiest to get
> into it. Blog post like this one from our "competitor" ;)
> https://auth0.com/blog/authentication-in-golang/ could also help
>
> Regarding the adapter blueprint,  I started this document here
> https://docs.google.com/a/redhat.com/spreadsheets/d/
> 13muhHORqIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
>
> On Mon, May 8, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > Sebastien is planning to create a blueprint of adapters including test
> > coverage. That would probably be very useful when creating a new adapter.
> >
> > On 5 May 2017 at 20:34, Bill Burke <bburke at redhat.com> wrote:
> >
> >> https://github.com/coreos/go-oidc  might be a good start?
> >>
> >> You could expand it to make sure it understands our access token format
> >> (i.e.roles) and can handle our extensions (backchannel logut and other
> >> events, the CORS support we have in other adapters, etc...)
> >>
> >> Then we'd probably create a repo for you once its ready, or we can do
> >> that right away too, up to you.
> >>
> >>
> >>
> >> On 5/5/17 1:38 PM, Tony Winters wrote:
> >> > I was just at the RedHat Summit this week and during the Keycloak
> >> session, it was mentioned that there wasn?t a GoLang adapter yet. I?d be
> >> interested in tackling this if there is a need. What is the process to
> get
> >> this started? We actually have an application written in GoLang that
> will
> >> need to be secured once we go live with Keycloak company wide (scheduled
> >> go-live within the next several months).
> >> >
> >> > Tony Winters
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Wed May 10 17:29:37 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 May 2017 17:29:37 -0400
Subject: [keycloak-dev] any reason Migrators in server-private-spi?
Message-ID: <d4761c6b-8abd-0ca3-3fab-62c5aa37d935@redhat.com>

Anybody know why Migrators are in server-private-spi?  Shouldn't they be 
in services?  They should never be exposed and I thought private-spi 
were for things we might eventually move to public.


From bburke at redhat.com  Wed May 10 18:07:07 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 May 2017 18:07:07 -0400
Subject: [keycloak-dev] restricted admin console access
Message-ID: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>

I'm thinking of adding additional admin roles: "admin-console-users", 
"admin-console-groups", "admin-console-clients" and a composite of all 
three: "admin-console-access".  These roles exist solely for the admin 
console and determine whether or not the "Users", "Clients", or "Groups" 
menu items show up.  It is unfeasible to calculate this considering that 
a restricted admin may have access to only one client in the admin 
console or a specific set of users in a specific group.

Alternatively, I could just display the "Users', "Clients" and "Groups" 
menu item no matter what role mappings or permissions the restricted 
admin has.  Then when they click on that menu item, query results are 
filtered based on individual permissions.  I like the latter better 
because its a better user experience.  For example, if a restricted 
admin can only manage one client and nothing else, the admin console 
could bring the admin directly to that client's management page.

From bruno at abstractj.org  Wed May 10 18:14:04 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 10 May 2017 19:14:04 -0300
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
Message-ID: <20170510221404.GA27289@abstractj.org>

On 2017-05-10, Stan Silvert wrote:
> The very thought of $subject seems like heresy.  Why check in something
> that is normally pulled using npm?
>
> We have Angular 2 examples in Keycloak now.  In the not-too-distant
> future, our Account Management console will be written in Angular 2.  So
> node_modules has to be there somehow.
>
> There are basically two options:
> 1)  Merge node_modules into the Keycloak repo.
> 2)  Don't merge and then run npm install at build time.
>
> Productization standards push toward option #1.  We need to have
> consistent, repeatable builds.
>
> But I'm looking for reasons that #1 might be bad.  I can't come up with
> a rational reason to do #2 except that it saves disk space.

My 2 cents here. I think #1 is bad for the following reasons:

1. That's not the convention for Node.js development. Think about Java
devs committing JARs to our repo. Certainly that would be terrible.
2. Code review becomes a PITA at every dependency update.
3. Merge conflicts. Just think about multiple devs contribution to the
same repo and updating their modules.
4. People could manually change these modules and you would never know
if the change is a consequence of `npm update` or a manual change.
5. This only makes sense on scenarios where dev cannot rely on npm
dependencies.


IMO option #2 would be the most viable. Projects from RedHat already do
this[1] with some success. So I don't see any need for it.

[1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob/02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42


>
> Any thoughts?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From takashi.norimatsu.ws at hitachi.com  Wed May 10 23:48:37 2017
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Thu, 11 May 2017 03:48:37 +0000
Subject: [keycloak-dev] Proposal of using existing authentication server on
 behalf of keycloak browser-based authentication
Message-ID: <831D472326678942A9B4BB933AAA103D25F97457@GSjpTK1DCembx01.service.hitachi.net>

Hello.

I'd like to propose the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. 

It might be said that it be the variant of Identity Brokering except for not using standard protocols for Identity Federation such as OpenID Connect and SAMLv2.

Its concept is similar to SP-Initiated SSO: POST/Artifact Bindings of SAMLv2.

[Background]
- The authentication server has already existed.
- This authentication server has not implemented OpenID Connect protocol.
- You want to use keycloak for realizing secure identity and access management by OpenID Connect.

In this situation above, you could opt to port the authentication feature of the existing authentication server onto keycloak and use User Storage SPI provider for retrieving user information from the existing authentication server, or implementing OpenID Connect protocol to address Identity Brokering triggered by keycloak.

However, the followings make it hard or impossible. 

- UI implementation cost : Responsive design, vast amount of customization based on various factors.
- Authentication porting cost : Requirements for high-level authentication that have already been implemented in the existing authentication server such as multi-factor authentication for LoA 3 conformance in ITU-T X.1254.

This authentication delegation mechanism resolves these difficulties by using the existing authentication server for authentication and retrieving authenticated user information by back-end communication between keycloak and the existing authentication server.

Prototype Implementation and PoV testing has been completed.

Implementing as additional providers and its factories for Authentication SPI and User Storage SPI in order to avoid impairing existing keycloak features.

Would you mind reviewing this concept and prototype implementation? If accepted, I'm willing to revise codes for PR.
Details is as follows.
https://github.com/Hitachi/PoV-keycloak-authentication-delegation/tree/master/doc
Sample codes is the following.
https://github.com/Hitachi/PoV-keycloak-authentication-delegation/tree/master/src

Best Regards
Takashi Norimatsu
Hitachi, Ltd.



From sthorger at redhat.com  Thu May 11 00:46:48 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 May 2017 06:46:48 +0200
Subject: [keycloak-dev] any reason Migrators in server-private-spi?
In-Reply-To: <d4761c6b-8abd-0ca3-3fab-62c5aa37d935@redhat.com>
References: <d4761c6b-8abd-0ca3-3fab-62c5aa37d935@redhat.com>
Message-ID: <CAJgngAc8Hx3UHvf-K8b0Ah5OnRZwkSBROCv+1GPJvtER6aOLhA@mail.gmail.com>

I can't think of any. Added a JIRA to get this sorted out:
https://issues.jboss.org/browse/KEYCLOAK-4887

On 10 May 2017 at 23:29, Bill Burke <bburke at redhat.com> wrote:

> Anybody know why Migrators are in server-private-spi?  Shouldn't they be
> in services?  They should never be exposed and I thought private-spi
> were for things we might eventually move to public.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu May 11 01:07:06 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 May 2017 07:07:06 +0200
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
Message-ID: <CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>

+1 To having a way to hide bits of the console

Why not just leverage the already existing roles? We could for example
require the view-users role to be able to view users at all. Then authz
services simply determines what users are displayed.

I'd be reluctant to add more roles as it's already quite messy IMO.
Especially with the master realm. Then there's also the token size with
large number of realms. Adding yet more roles would just make that even
worse right?

On 11 May 2017 at 00:07, Bill Burke <bburke at redhat.com> wrote:

> I'm thinking of adding additional admin roles: "admin-console-users",
> "admin-console-groups", "admin-console-clients" and a composite of all
> three: "admin-console-access".  These roles exist solely for the admin
> console and determine whether or not the "Users", "Clients", or "Groups"
> menu items show up.  It is unfeasible to calculate this considering that
> a restricted admin may have access to only one client in the admin
> console or a specific set of users in a specific group.
>
> Alternatively, I could just display the "Users', "Clients" and "Groups"
> menu item no matter what role mappings or permissions the restricted
> admin has.  Then when they click on that menu item, query results are
> filtered based on individual permissions.  I like the latter better
> because its a better user experience.  For example, if a restricted
> admin can only manage one client and nothing else, the admin console
> could bring the admin directly to that client's management page.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sander.Geerts at topicus.nl  Thu May 11 02:42:54 2017
From: Sander.Geerts at topicus.nl (Sander Geerts)
Date: Thu, 11 May 2017 06:42:54 +0000
Subject: [keycloak-dev] Angular version
Message-ID: <AA9E8CC426068F4382FE06885A41C0EA339DE4BA@EXCH-MBX04.topicus.local>

Hello,

We are using Keycloak for some of our products. One of our clients scans every used library and tools, and they came across the issue of cross-site scripting in the used angular version (1.4.4) in Keycloak. Can this cause issues when using Keycloak? Why (not)?

From sthorger at redhat.com  Thu May 11 06:48:53 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 May 2017 12:48:53 +0200
Subject: [keycloak-dev] Criticial vulnerability fixed in Keycloak Node.js
	adapters
Message-ID: <CAJgngAfZ1vckgyJSdcw-gX7HX2=UT8JMa32sT9B42-2SV678Nw@mail.gmail.com>

A criticial vulnerability was discovered in Keycloak Node.js adapters. We
highly recommend everyone upgrades to version 3.1.0 of the adapter
immediately. This adapter will work with Keycloak 2 and upwards.

For more details see CVE-2017-7474
<https://access.redhat.com/security/cve/cve-2017-7474>.

From ssilvert at redhat.com  Thu May 11 08:04:32 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 11 May 2017 08:04:32 -0400
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <20170510221404.GA27289@abstractj.org>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
Message-ID: <39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>

On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> On 2017-05-10, Stan Silvert wrote:
>> The very thought of $subject seems like heresy.  Why check in something
>> that is normally pulled using npm?
>>
>> We have Angular 2 examples in Keycloak now.  In the not-too-distant
>> future, our Account Management console will be written in Angular 2.  So
>> node_modules has to be there somehow.
>>
>> There are basically two options:
>> 1)  Merge node_modules into the Keycloak repo.
>> 2)  Don't merge and then run npm install at build time.
>>
>> Productization standards push toward option #1.  We need to have
>> consistent, repeatable builds.
>>
>> But I'm looking for reasons that #1 might be bad.  I can't come up with
>> a rational reason to do #2 except that it saves disk space.
> My 2 cents here. I think #1 is bad for the following reasons:
My instinct is that it's bad too.  But I need to play devil's advocate.
>
> 1. That's not the convention for Node.js development. Think about Java
> devs committing JARs to our repo. Certainly that would be terrible.
That's just the heresy argument.
> 2. Code review becomes a PITA at every dependency update.
If you are talking about review in GitHub, that shouldn't be a problem.  
GitHub uses linguist to hide vendor files so that it doesn't mess up 
your review.  All you see is the file name.  By default, it doesn't show 
you the whole file.  Strangely enough, the linguist guys see checking in 
js libraries as a common practice:
https://github.com/github/linguist#vendored-code
> 3. Merge conflicts. Just think about multiple devs contribution to the
> same repo and updating their modules.
Maybe I'm missing something here.  Wouldn't that be really rare if it 
ever happened at all (in our case)?
> 4. People could manually change these modules and you would never know
> if the change is a consequence of `npm update` or a manual change.
I really hope nobody would be dumb enough to do that!

But come to think of it, this would be a security issue if someone did 
it on purpose.   Someone could sneak malicious code into our repo 
disguised as a legit PR.  It wouldn't be easy to catch during code review.
> 5. This only makes sense on scenarios where dev cannot rely on npm
> dependencies.
>
>
> IMO option #2 would be the most viable. Projects from RedHat already do
> this[1] with some success. So I don't see any need for it.
>
> [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob/02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
Doesn't this make the build a LOT slower?

How is Aerogear dealing with productization?
>
>
>> Any thoughts?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> --
>
> abstractj


From bruno at abstractj.org  Thu May 11 09:10:30 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 11 May 2017 10:10:30 -0300
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
Message-ID: <20170511131030.GA5486@abstractj.org>

On 2017-05-11, Stan Silvert wrote:
> On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > On 2017-05-10, Stan Silvert wrote:
> > > The very thought of $subject seems like heresy.  Why check in something
> > > that is normally pulled using npm?
> > >
> > > We have Angular 2 examples in Keycloak now.  In the not-too-distant
> > > future, our Account Management console will be written in Angular 2.  So
> > > node_modules has to be there somehow.
> > >
> > > There are basically two options:
> > > 1)  Merge node_modules into the Keycloak repo.
> > > 2)  Don't merge and then run npm install at build time.
> > >
> > > Productization standards push toward option #1.  We need to have
> > > consistent, repeatable builds.
> > >
> > > But I'm looking for reasons that #1 might be bad.  I can't come up with
> > > a rational reason to do #2 except that it saves disk space.
> > My 2 cents here. I think #1 is bad for the following reasons:
> My instinct is that it's bad too.  But I need to play devil's advocate.
> >
> > 1. That's not the convention for Node.js development. Think about Java
> > devs committing JARs to our repo. Certainly that would be terrible.
> That's just the heresy argument.

Not really. It's also the way which QE thinks is the way to go (https://github.com/keycloak/keycloak-quickstarts/pull/25#issuecomment-300751341)

> > 2. Code review becomes a PITA at every dependency update.
> If you are talking about review in GitHub, that shouldn't be a problem.
> GitHub uses linguist to hide vendor files so that it doesn't mess up your
> review.  All you see is the file name.  By default, it doesn't show you the
> whole file.  Strangely enough, the linguist guys see checking in js
> libraries as a common practice:
> https://github.com/github/linguist#vendored-code

Well, you're assuming that we should all do our code reviews using only GH.

> > 3. Merge conflicts. Just think about multiple devs contribution to the
> > same repo and updating their modules.
> Maybe I'm missing something here.  Wouldn't that be really rare if it ever
> happened at all (in our case)?

Not if every developer decide to run npm update :)

> > 4. People could manually change these modules and you would never know
> > if the change is a consequence of `npm update` or a manual change.
> I really hope nobody would be dumb enough to do that!
>
> But come to think of it, this would be a security issue if someone did it on
> purpose.   Someone could sneak malicious code into our repo disguised as a
> legit PR.  It wouldn't be easy to catch during code review.

Trust me, if people wanted to do that. They wouldn't be dumb just
a single line

> > 5. This only makes sense on scenarios where dev cannot rely on npm
> > dependencies.
> >
> >
> > IMO option #2 would be the most viable. Projects from RedHat already do
> > this[1] with some success. So I don't see any need for it.
> >
> > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob/02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> Doesn't this make the build a LOT slower?

If slowness is the major concern, we should commit every single JAR
inside the repo and call it a day. But I don't think we do that, right?
Plus, Travis can cache the dependencies[1].

[1] - https://docs.travis-ci.com/user/caching/

>
> How is Aerogear dealing with productization?

You have to ask them, more precisely Matthias.

> >
> >
> > > Any thoughts?
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > --
> >
> > abstractj
>

--

abstractj

From sthorger at redhat.com  Thu May 11 13:17:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 May 2017 19:17:39 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <20170511131030.GA5486@abstractj.org>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
Message-ID: <CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>

I have 3 concerns around not checking in node_modules. If these are
addressed I'm happy:

* Productization - I believe not checking in the modules will mean they
have to be available in some internal NPM repository or something. Those
module not already available we'll have to add ourselves. Stan you would
have to figure this out as we no longer have a dedicated prod team (that's
us now!)
* Build time - just the basic Angular2 example adds overhead
* Offline mode - the Angular2 example at the moment can't be built when not
online. It will sit around for a loooong time until it eventually times
out. NPM modules would have to be checked in somewhere globally (not just
inside target dir or something like that). Maybe they can just be placed
inside the .m2 dir or something?!

On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2017-05-11, Stan Silvert wrote:
> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > On 2017-05-10, Stan Silvert wrote:
> > > > The very thought of $subject seems like heresy.  Why check in
> something
> > > > that is normally pulled using npm?
> > > >
> > > > We have Angular 2 examples in Keycloak now.  In the not-too-distant
> > > > future, our Account Management console will be written in Angular
> 2.  So
> > > > node_modules has to be there somehow.
> > > >
> > > > There are basically two options:
> > > > 1)  Merge node_modules into the Keycloak repo.
> > > > 2)  Don't merge and then run npm install at build time.
> > > >
> > > > Productization standards push toward option #1.  We need to have
> > > > consistent, repeatable builds.
> > > >
> > > > But I'm looking for reasons that #1 might be bad.  I can't come up
> with
> > > > a rational reason to do #2 except that it saves disk space.
> > > My 2 cents here. I think #1 is bad for the following reasons:
> > My instinct is that it's bad too.  But I need to play devil's advocate.
> > >
> > > 1. That's not the convention for Node.js development. Think about Java
> > > devs committing JARs to our repo. Certainly that would be terrible.
> > That's just the heresy argument.
>
> Not really. It's also the way which QE thinks is the way to go (
> https://github.com/keycloak/keycloak-quickstarts/pull/25#
> issuecomment-300751341)
>
> > > 2. Code review becomes a PITA at every dependency update.
> > If you are talking about review in GitHub, that shouldn't be a problem.
> > GitHub uses linguist to hide vendor files so that it doesn't mess up your
> > review.  All you see is the file name.  By default, it doesn't show you
> the
> > whole file.  Strangely enough, the linguist guys see checking in js
> > libraries as a common practice:
> > https://github.com/github/linguist#vendored-code
>
> Well, you're assuming that we should all do our code reviews using only GH.
>
> > > 3. Merge conflicts. Just think about multiple devs contribution to the
> > > same repo and updating their modules.
> > Maybe I'm missing something here.  Wouldn't that be really rare if it
> ever
> > happened at all (in our case)?
>
> Not if every developer decide to run npm update :)
>
> > > 4. People could manually change these modules and you would never know
> > > if the change is a consequence of `npm update` or a manual change.
> > I really hope nobody would be dumb enough to do that!
> >
> > But come to think of it, this would be a security issue if someone did
> it on
> > purpose.   Someone could sneak malicious code into our repo disguised as
> a
> > legit PR.  It wouldn't be easy to catch during code review.
>
> Trust me, if people wanted to do that. They wouldn't be dumb just
> a single line
>
> > > 5. This only makes sense on scenarios where dev cannot rely on npm
> > > dependencies.
> > >
> > >
> > > IMO option #2 would be the most viable. Projects from RedHat already do
> > > this[1] with some success. So I don't see any need for it.
> > >
> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob/
> 02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > Doesn't this make the build a LOT slower?
>
> If slowness is the major concern, we should commit every single JAR
> inside the repo and call it a day. But I don't think we do that, right?
> Plus, Travis can cache the dependencies[1].
>
> [1] - https://docs.travis-ci.com/user/caching/
>
> >
> > How is Aerogear dealing with productization?
>
> You have to ask them, more precisely Matthias.
>
> > >
> > >
> > > > Any thoughts?
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > --
> > >
> > > abstractj
> >
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu May 11 13:18:17 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 May 2017 19:18:17 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
Message-ID: <CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>

Oh and also I like to just run stuff from the IDE. I very rarely build
Keycloak from mvn unless I'm mocking about with the distribution parts.

On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:

> I have 3 concerns around not checking in node_modules. If these are
> addressed I'm happy:
>
> * Productization - I believe not checking in the modules will mean they
> have to be available in some internal NPM repository or something. Those
> module not already available we'll have to add ourselves. Stan you would
> have to figure this out as we no longer have a dedicated prod team (that's
> us now!)
> * Build time - just the basic Angular2 example adds overhead
> * Offline mode - the Angular2 example at the moment can't be built when
> not online. It will sit around for a loooong time until it eventually times
> out. NPM modules would have to be checked in somewhere globally (not just
> inside target dir or something like that). Maybe they can just be placed
> inside the .m2 dir or something?!
>
> On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> On 2017-05-11, Stan Silvert wrote:
>> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
>> > > On 2017-05-10, Stan Silvert wrote:
>> > > > The very thought of $subject seems like heresy.  Why check in
>> something
>> > > > that is normally pulled using npm?
>> > > >
>> > > > We have Angular 2 examples in Keycloak now.  In the not-too-distant
>> > > > future, our Account Management console will be written in Angular
>> 2.  So
>> > > > node_modules has to be there somehow.
>> > > >
>> > > > There are basically two options:
>> > > > 1)  Merge node_modules into the Keycloak repo.
>> > > > 2)  Don't merge and then run npm install at build time.
>> > > >
>> > > > Productization standards push toward option #1.  We need to have
>> > > > consistent, repeatable builds.
>> > > >
>> > > > But I'm looking for reasons that #1 might be bad.  I can't come up
>> with
>> > > > a rational reason to do #2 except that it saves disk space.
>> > > My 2 cents here. I think #1 is bad for the following reasons:
>> > My instinct is that it's bad too.  But I need to play devil's advocate.
>> > >
>> > > 1. That's not the convention for Node.js development. Think about Java
>> > > devs committing JARs to our repo. Certainly that would be terrible.
>> > That's just the heresy argument.
>>
>> Not really. It's also the way which QE thinks is the way to go (
>> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
>> suecomment-300751341)
>>
>> > > 2. Code review becomes a PITA at every dependency update.
>> > If you are talking about review in GitHub, that shouldn't be a problem.
>> > GitHub uses linguist to hide vendor files so that it doesn't mess up
>> your
>> > review.  All you see is the file name.  By default, it doesn't show you
>> the
>> > whole file.  Strangely enough, the linguist guys see checking in js
>> > libraries as a common practice:
>> > https://github.com/github/linguist#vendored-code
>>
>> Well, you're assuming that we should all do our code reviews using only
>> GH.
>>
>> > > 3. Merge conflicts. Just think about multiple devs contribution to the
>> > > same repo and updating their modules.
>> > Maybe I'm missing something here.  Wouldn't that be really rare if it
>> ever
>> > happened at all (in our case)?
>>
>> Not if every developer decide to run npm update :)
>>
>> > > 4. People could manually change these modules and you would never know
>> > > if the change is a consequence of `npm update` or a manual change.
>> > I really hope nobody would be dumb enough to do that!
>> >
>> > But come to think of it, this would be a security issue if someone did
>> it on
>> > purpose.   Someone could sneak malicious code into our repo disguised
>> as a
>> > legit PR.  It wouldn't be easy to catch during code review.
>>
>> Trust me, if people wanted to do that. They wouldn't be dumb just
>> a single line
>>
>> > > 5. This only makes sense on scenarios where dev cannot rely on npm
>> > > dependencies.
>> > >
>> > >
>> > > IMO option #2 would be the most viable. Projects from RedHat already
>> do
>> > > this[1] with some success. So I don't see any need for it.
>> > >
>> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob
>> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
>> > Doesn't this make the build a LOT slower?
>>
>> If slowness is the major concern, we should commit every single JAR
>> inside the repo and call it a day. But I don't think we do that, right?
>> Plus, Travis can cache the dependencies[1].
>>
>> [1] - https://docs.travis-ci.com/user/caching/
>>
>> >
>> > How is Aerogear dealing with productization?
>>
>> You have to ask them, more precisely Matthias.
>>
>> > >
>> > >
>> > > > Any thoughts?
>> > > > _______________________________________________
>> > > > keycloak-dev mailing list
>> > > > keycloak-dev at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > > --
>> > >
>> > > abstractj
>> >
>>
>> --
>>
>> abstractj
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bruno at abstractj.org  Thu May 11 16:06:59 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 11 May 2017 17:06:59 -0300
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
Message-ID: <20170511200659.GA30905@abstractj.org>

Some answers inline.

On 2017-05-11, Stian Thorgersen wrote:
> Oh and also I like to just run stuff from the IDE. I very rarely build
> Keycloak from mvn unless I'm mocking about with the distribution parts.

To run stuff from your IDE, you just run npm install inside the project.
You don't need Maven for it.

>
> On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> > I have 3 concerns around not checking in node_modules. If these are
> > addressed I'm happy:
> >
> > * Productization - I believe not checking in the modules will mean they
> > have to be available in some internal NPM repository or something. Those
> > module not already available we'll have to add ourselves. Stan you would
> > have to figure this out as we no longer have a dedicated prod team (that's
> > us now!)

Yep, I know. One of the reasons why run diff at each upgrade of these
dependencies will sound like hell.

> > * Build time - just the basic Angular2 example adds overhead

I won't take the road of Java vs Node.js. But pretty much you have the
same issue with Maven, when you don't have dependencies installed.
One way or another you have to download it from the internet.

> > * Offline mode - the Angular2 example at the moment can't be built when
> > not online. It will sit around for a loooong time until it eventually times
> > out. NPM modules would have to be checked in somewhere globally (not just
> > inside target dir or something like that). Maybe they can just be placed
> > inside the .m2 dir or something?!

Isn't the same when you are disconnected and you try to run Maven?

Anyways, I don't think we gonna reach any consensus about it. So, anything
you guys think is the best for the project, go ahead. It's software, we
can always change, sometimes break :)

> >
> > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
> >
> >> On 2017-05-11, Stan Silvert wrote:
> >> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> >> > > On 2017-05-10, Stan Silvert wrote:
> >> > > > The very thought of $subject seems like heresy.  Why check in
> >> something
> >> > > > that is normally pulled using npm?
> >> > > >
> >> > > > We have Angular 2 examples in Keycloak now.  In the not-too-distant
> >> > > > future, our Account Management console will be written in Angular
> >> 2.  So
> >> > > > node_modules has to be there somehow.
> >> > > >
> >> > > > There are basically two options:
> >> > > > 1)  Merge node_modules into the Keycloak repo.
> >> > > > 2)  Don't merge and then run npm install at build time.
> >> > > >
> >> > > > Productization standards push toward option #1.  We need to have
> >> > > > consistent, repeatable builds.
> >> > > >
> >> > > > But I'm looking for reasons that #1 might be bad.  I can't come up
> >> with
> >> > > > a rational reason to do #2 except that it saves disk space.
> >> > > My 2 cents here. I think #1 is bad for the following reasons:
> >> > My instinct is that it's bad too.  But I need to play devil's advocate.
> >> > >
> >> > > 1. That's not the convention for Node.js development. Think about Java
> >> > > devs committing JARs to our repo. Certainly that would be terrible.
> >> > That's just the heresy argument.
> >>
> >> Not really. It's also the way which QE thinks is the way to go (
> >> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> >> suecomment-300751341)
> >>
> >> > > 2. Code review becomes a PITA at every dependency update.
> >> > If you are talking about review in GitHub, that shouldn't be a problem.
> >> > GitHub uses linguist to hide vendor files so that it doesn't mess up
> >> your
> >> > review.  All you see is the file name.  By default, it doesn't show you
> >> the
> >> > whole file.  Strangely enough, the linguist guys see checking in js
> >> > libraries as a common practice:
> >> > https://github.com/github/linguist#vendored-code
> >>
> >> Well, you're assuming that we should all do our code reviews using only
> >> GH.
> >>
> >> > > 3. Merge conflicts. Just think about multiple devs contribution to the
> >> > > same repo and updating their modules.
> >> > Maybe I'm missing something here.  Wouldn't that be really rare if it
> >> ever
> >> > happened at all (in our case)?
> >>
> >> Not if every developer decide to run npm update :)
> >>
> >> > > 4. People could manually change these modules and you would never know
> >> > > if the change is a consequence of `npm update` or a manual change.
> >> > I really hope nobody would be dumb enough to do that!
> >> >
> >> > But come to think of it, this would be a security issue if someone did
> >> it on
> >> > purpose.   Someone could sneak malicious code into our repo disguised
> >> as a
> >> > legit PR.  It wouldn't be easy to catch during code review.
> >>
> >> Trust me, if people wanted to do that. They wouldn't be dumb just
> >> a single line
> >>
> >> > > 5. This only makes sense on scenarios where dev cannot rely on npm
> >> > > dependencies.
> >> > >
> >> > >
> >> > > IMO option #2 would be the most viable. Projects from RedHat already
> >> do
> >> > > this[1] with some success. So I don't see any need for it.
> >> > >
> >> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob
> >> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> >> > Doesn't this make the build a LOT slower?
> >>
> >> If slowness is the major concern, we should commit every single JAR
> >> inside the repo and call it a day. But I don't think we do that, right?
> >> Plus, Travis can cache the dependencies[1].
> >>
> >> [1] - https://docs.travis-ci.com/user/caching/
> >>
> >> >
> >> > How is Aerogear dealing with productization?
> >>
> >> You have to ask them, more precisely Matthias.
> >>
> >> > >
> >> > >
> >> > > > Any thoughts?
> >> > > > _______________________________________________
> >> > > > keycloak-dev mailing list
> >> > > > keycloak-dev at lists.jboss.org
> >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> > > --
> >> > >
> >> > > abstractj
> >> >
> >>
> >> --
> >>
> >> abstractj
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >

--

abstractj

From mposolda at redhat.com  Thu May 11 16:33:12 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 11 May 2017 22:33:12 +0200
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
Message-ID: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>

I've finally sent the PR https://github.com/keycloak/keycloak/pull/4132 
with the work for $subject. This includes the work by Hynek and me on 
Authentication sessions and action tokens. We finally managed to sort 
various kinks and have all tests passing.

Some things and concepts were already discussed in some previous threads 
[1], [2], [3] and during presentations. So I won't repeat everything. 
Just some highlights:

- authenticationSession replaces the old ClientSessionModel. There is 
separate AuthenticationSessionProvider and separate infinispan cache 
"authenticationSessions" . This cache typicaly won't be replicated over 
all the datacenters, but instead it will rely on browser sticky 
sessions, hence browser will be redirected by loadbalancer to correct 
node in correct datacenter. So typicaly there won't be cross-dc 
communication needed during authentication.

- I've added some support for sticky sessions already. In cluster 
environment, the authentication session cookie is created in the format 
like "sessionId.routeId" . For example 
"aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format 
like JSESSIONID cookie used as a cookie in classic java web 
applications. One side-effect of this PR is, that it also covers the 
support for running clustering tests on embedded undertow and from IDE.

- Support for browser back/forward/refresh buttons was improved since my 
presentation last month. There are no browser redirects after the form 
submit, but instead there is a change of browser history through the 
javascript history.replaceState function. This pretty much removes all 
the POST requests from the browser history and helps with having good 
experience regarding browser buttons. In case that you have old browser 
not supporting this, the behaviour is same like before. Hence default 
browser "Page expired" page after clicking back from POST request (same 
behaviour like latest master). There are no additional redirects.

- For action tokens, Hynek will likely add more. For quick summary, I 
can just mention that action token is JWT signed by realm secret key. 
You can generate it in your authenticator or requiredActionProvider and 
send it somehow to user. Typically through email. Once user opens the 
actionToken URL from the email, it is processed on LoginActionsService 
endpoint, which provides most of the common basic functionality and 
verifications. LoginActionsService then finds the correct implementation 
of ActionTokenHandler, which is separate SPI. This allows to specify the 
details how can be actionToken handled, whether it's single use or not 
etc. There is support for the scenario if user opened link in the same 
browser when he started authenticationSession or in different browser etc.

- Regarding PR, I've tried to squash the commits a bit. However PR still 
consists of more commits to track at least what was done by me and what 
by Hynek. Do you think it is the issue to have more commits in the PR?

- This is hopefully the bigest task for the cross-dc support. My hope is 
that PR can be reviewed and merged soon as the work is more and more 
unsynced with the latest master and rebasing is a bit of pain. But I 
understand that this will require time. There is change in 324 files :) 
There are still a lot things to cover for cross-dc, but I think those 
can be done in smaller pieces and commit more often.

[1] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
[2] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
[3] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html

Marek


From bburke at redhat.com  Thu May 11 17:02:37 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 May 2017 17:02:37 -0400
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
Message-ID: <76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>

I don't want to add more roles either, but I currently don't see a way 
to model your suggestion.  This is why I'm posting to dev, because I 
need ideas.  Everything is currently modeled as granting additional 
access, not restricting existing access.  "view-users" grants viewing 
access to all users and we can't break backward compatibility.  I just 
don't know how restricting viewing to a specific group of users could be 
modeled.

The current way I have it modeled is:

1. See if admin can view all users .  There is a resource that 
represents all users.  I ask policy engine if admin has "view" scope for 
"Users" resource (i.e. (has "view-users" role).  If this passes, I let 
them view the user

2. If #1 fails, then loop through each group the user belongs to.  If 
admin has "view_members" scope for the group, i let the admin view the user


If we do as you suggest, then you'd have to do the opposite of above

1. See if admin can view all users. (has "view-users" role).  This 
doesn't grant access yet, proceed to step 2.
2. Loop through each group the user belongs to and see if the admin is 
restricted from viewing members of this group.

Do you see the problem here?   How do you model the restriction AND, at 
the same time, make sure you're backward compatible with "view-users" 
behavior?




On 5/11/17 1:07 AM, Stian Thorgersen wrote:
> +1 To having a way to hide bits of the console
>
> Why not just leverage the already existing roles? We could for example 
> require the view-users role to be able to view users at all. Then 
> authz services simply determines what users are displayed.
>
> I'd be reluctant to add more roles as it's already quite messy IMO. 
> Especially with the master realm. Then there's also the token size 
> with large number of realms. Adding yet more roles would just make 
> that even worse right?
>
> On 11 May 2017 at 00:07, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I'm thinking of adding additional admin roles: "admin-console-users",
>     "admin-console-groups", "admin-console-clients" and a composite of all
>     three: "admin-console-access".  These roles exist solely for the admin
>     console and determine whether or not the "Users", "Clients", or
>     "Groups"
>     menu items show up.  It is unfeasible to calculate this
>     considering that
>     a restricted admin may have access to only one client in the admin
>     console or a specific set of users in a specific group.
>
>     Alternatively, I could just display the "Users', "Clients" and
>     "Groups"
>     menu item no matter what role mappings or permissions the restricted
>     admin has.  Then when they click on that menu item, query results are
>     filtered based on individual permissions.  I like the latter better
>     because its a better user experience.  For example, if a restricted
>     admin can only manage one client and nothing else, the admin console
>     could bring the admin directly to that client's management page.
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From ssilvert at redhat.com  Thu May 11 18:22:28 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 11 May 2017 18:22:28 -0400
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <20170511200659.GA30905@abstractj.org>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
Message-ID: <7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>

On 5/11/2017 4:06 PM, Bruno Oliveira wrote:
> Some answers inline.
More comments inline...
>
> On 2017-05-11, Stian Thorgersen wrote:
>> Oh and also I like to just run stuff from the IDE. I very rarely build
>> Keycloak from mvn unless I'm mocking about with the distribution parts.
> To run stuff from your IDE, you just run npm install inside the project.
> You don't need Maven for it.
>
>> On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>>> I have 3 concerns around not checking in node_modules. If these are
>>> addressed I'm happy:
>>>
>>> * Productization - I believe not checking in the modules will mean they
>>> have to be available in some internal NPM repository or something. Those
>>> module not already available we'll have to add ourselves. Stan you would
>>> have to figure this out as we no longer have a dedicated prod team (that's
>>> us now!)
> Yep, I know. One of the reasons why run diff at each upgrade of these
> dependencies will sound like hell.
I don't know the answer to the productization question.  SOMEBODY in 
MiddleWare
must have dealt with this before.  Who can I ask?
>
>>> * Build time - just the basic Angular2 example adds overhead
> I won't take the road of Java vs Node.js. But pretty much you have the
> same issue with Maven, when you don't have dependencies installed.
> One way or another you have to download it from the internet.
With Maven, you only have to download once.  But with node_modules not 
checked in
you will have to download every time after you do a clean.  Or is there 
some way around that?

npm doesn't seem to have the same concept of a local repo like Maven.  
Installing globally doesn't fix
the problem.  Or is there a solution I don't know about?
>
>>> * Offline mode - the Angular2 example at the moment can't be built when
>>> not online. It will sit around for a loooong time until it eventually times
>>> out. NPM modules would have to be checked in somewhere globally (not just
>>> inside target dir or something like that). Maybe they can just be placed
>>> inside the .m2 dir or something?!
> Isn't the same when you are disconnected and you try to run Maven?
No.   You can rely on the local Maven repo.  Works great disconnected.
>
> Anyways, I don't think we gonna reach any consensus about it. So, anything
> you guys think is the best for the project, go ahead. It's software, we
> can always change, sometimes break :)
>
>>> On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
>>>
>>>> On 2017-05-11, Stan Silvert wrote:
>>>>> On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
>>>>>> On 2017-05-10, Stan Silvert wrote:
>>>>>>> The very thought of $subject seems like heresy.  Why check in
>>>> something
>>>>>>> that is normally pulled using npm?
>>>>>>>
>>>>>>> We have Angular 2 examples in Keycloak now.  In the not-too-distant
>>>>>>> future, our Account Management console will be written in Angular
>>>> 2.  So
>>>>>>> node_modules has to be there somehow.
>>>>>>>
>>>>>>> There are basically two options:
>>>>>>> 1)  Merge node_modules into the Keycloak repo.
>>>>>>> 2)  Don't merge and then run npm install at build time.
>>>>>>>
>>>>>>> Productization standards push toward option #1.  We need to have
>>>>>>> consistent, repeatable builds.
>>>>>>>
>>>>>>> But I'm looking for reasons that #1 might be bad.  I can't come up
>>>> with
>>>>>>> a rational reason to do #2 except that it saves disk space.
>>>>>> My 2 cents here. I think #1 is bad for the following reasons:
>>>>> My instinct is that it's bad too.  But I need to play devil's advocate.
>>>>>> 1. That's not the convention for Node.js development. Think about Java
>>>>>> devs committing JARs to our repo. Certainly that would be terrible.
>>>>> That's just the heresy argument.
>>>> Not really. It's also the way which QE thinks is the way to go (
>>>> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
>>>> suecomment-300751341)
>>>>
>>>>>> 2. Code review becomes a PITA at every dependency update.
>>>>> If you are talking about review in GitHub, that shouldn't be a problem.
>>>>> GitHub uses linguist to hide vendor files so that it doesn't mess up
>>>> your
>>>>> review.  All you see is the file name.  By default, it doesn't show you
>>>> the
>>>>> whole file.  Strangely enough, the linguist guys see checking in js
>>>>> libraries as a common practice:
>>>>> https://github.com/github/linguist#vendored-code
>>>> Well, you're assuming that we should all do our code reviews using only
>>>> GH.
>>>>
>>>>>> 3. Merge conflicts. Just think about multiple devs contribution to the
>>>>>> same repo and updating their modules.
>>>>> Maybe I'm missing something here.  Wouldn't that be really rare if it
>>>> ever
>>>>> happened at all (in our case)?
>>>> Not if every developer decide to run npm update :)
>>>>
>>>>>> 4. People could manually change these modules and you would never know
>>>>>> if the change is a consequence of `npm update` or a manual change.
>>>>> I really hope nobody would be dumb enough to do that!
>>>>>
>>>>> But come to think of it, this would be a security issue if someone did
>>>> it on
>>>>> purpose.   Someone could sneak malicious code into our repo disguised
>>>> as a
>>>>> legit PR.  It wouldn't be easy to catch during code review.
>>>> Trust me, if people wanted to do that. They wouldn't be dumb just
>>>> a single line
>>>>
>>>>>> 5. This only makes sense on scenarios where dev cannot rely on npm
>>>>>> dependencies.
>>>>>>
>>>>>>
>>>>>> IMO option #2 would be the most viable. Projects from RedHat already
>>>> do
>>>>>> this[1] with some success. So I don't see any need for it.
>>>>>>
>>>>>> [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob
>>>> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
>>>>> Doesn't this make the build a LOT slower?
>>>> If slowness is the major concern, we should commit every single JAR
>>>> inside the repo and call it a day. But I don't think we do that, right?
>>>> Plus, Travis can cache the dependencies[1].
>>>>
>>>> [1] - https://docs.travis-ci.com/user/caching/
>>>>
>>>>> How is Aerogear dealing with productization?
>>>> You have to ask them, more precisely Matthias.
>>>>
>>>>>>
>>>>>>> Any thoughts?
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> --
>>>>>>
>>>>>> abstractj
>>>> --
>>>>
>>>> abstractj
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
> --
>
> abstractj


From bburke at redhat.com  Thu May 11 19:15:19 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 May 2017 19:15:19 -0400
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
Message-ID: <c64151ab-9194-42ba-a215-cd6b60f993a9@redhat.com>

Nice work...Cut/paste this to docs


On 5/11/17 4:33 PM, Marek Posolda wrote:
> I've finally sent the PR https://github.com/keycloak/keycloak/pull/4132
> with the work for $subject. This includes the work by Hynek and me on
> Authentication sessions and action tokens. We finally managed to sort
> various kinks and have all tests passing.
>
> Some things and concepts were already discussed in some previous threads
> [1], [2], [3] and during presentations. So I won't repeat everything.
> Just some highlights:
>
> - authenticationSession replaces the old ClientSessionModel. There is
> separate AuthenticationSessionProvider and separate infinispan cache
> "authenticationSessions" . This cache typicaly won't be replicated over
> all the datacenters, but instead it will rely on browser sticky
> sessions, hence browser will be redirected by loadbalancer to correct
> node in correct datacenter. So typicaly there won't be cross-dc
> communication needed during authentication.
>
> - I've added some support for sticky sessions already. In cluster
> environment, the authentication session cookie is created in the format
> like "sessionId.routeId" . For example
> "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format
> like JSESSIONID cookie used as a cookie in classic java web
> applications. One side-effect of this PR is, that it also covers the
> support for running clustering tests on embedded undertow and from IDE.
>
> - Support for browser back/forward/refresh buttons was improved since my
> presentation last month. There are no browser redirects after the form
> submit, but instead there is a change of browser history through the
> javascript history.replaceState function. This pretty much removes all
> the POST requests from the browser history and helps with having good
> experience regarding browser buttons. In case that you have old browser
> not supporting this, the behaviour is same like before. Hence default
> browser "Page expired" page after clicking back from POST request (same
> behaviour like latest master). There are no additional redirects.
>
> - For action tokens, Hynek will likely add more. For quick summary, I
> can just mention that action token is JWT signed by realm secret key.
> You can generate it in your authenticator or requiredActionProvider and
> send it somehow to user. Typically through email. Once user opens the
> actionToken URL from the email, it is processed on LoginActionsService
> endpoint, which provides most of the common basic functionality and
> verifications. LoginActionsService then finds the correct implementation
> of ActionTokenHandler, which is separate SPI. This allows to specify the
> details how can be actionToken handled, whether it's single use or not
> etc. There is support for the scenario if user opened link in the same
> browser when he started authenticationSession or in different browser etc.
>
> - Regarding PR, I've tried to squash the commits a bit. However PR still
> consists of more commits to track at least what was done by me and what
> by Hynek. Do you think it is the issue to have more commits in the PR?
>
> - This is hopefully the bigest task for the cross-dc support. My hope is
> that PR can be reviewed and merged soon as the work is more and more
> unsynced with the latest master and rebasing is a bit of pain. But I
> understand that this will require time. There is change in 324 files :)
> There are still a lot things to cover for cross-dc, but I think those
> can be done in smaller pieces and commit more often.
>
> [1] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
> [3] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stevenmirabito at gmail.com  Thu May 11 21:25:26 2017
From: stevenmirabito at gmail.com (Steven Mirabito)
Date: Fri, 12 May 2017 01:25:26 +0000
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
Message-ID: <CAHVh=dZpjy40+nqGwPabXt0+eiLbEXN=dhzVnyZUcmZE8MFM5w@mail.gmail.com>

Using yarn instead of npm to manage node_modules (it's a drop-in
replacement in most cases) will provide a local package cache similar to
the local Maven repo: https://yarnpkg.com

-Steven

On Thu, May 11, 2017, 5:57 PM Stan Silvert <ssilvert at redhat.com> wrote:

> On 5/11/2017 4:06 PM, Bruno Oliveira wrote:
> > Some answers inline.
> More comments inline...
> >
> > On 2017-05-11, Stian Thorgersen wrote:
> >> Oh and also I like to just run stuff from the IDE. I very rarely build
> >> Keycloak from mvn unless I'm mocking about with the distribution parts.
> > To run stuff from your IDE, you just run npm install inside the project.
> > You don't need Maven for it.
> >
> >> On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
> >>
> >>> I have 3 concerns around not checking in node_modules. If these are
> >>> addressed I'm happy:
> >>>
> >>> * Productization - I believe not checking in the modules will mean they
> >>> have to be available in some internal NPM repository or something.
> Those
> >>> module not already available we'll have to add ourselves. Stan you
> would
> >>> have to figure this out as we no longer have a dedicated prod team
> (that's
> >>> us now!)
> > Yep, I know. One of the reasons why run diff at each upgrade of these
> > dependencies will sound like hell.
> I don't know the answer to the productization question.  SOMEBODY in
> MiddleWare
> must have dealt with this before.  Who can I ask?
> >
> >>> * Build time - just the basic Angular2 example adds overhead
> > I won't take the road of Java vs Node.js. But pretty much you have the
> > same issue with Maven, when you don't have dependencies installed.
> > One way or another you have to download it from the internet.
> With Maven, you only have to download once.  But with node_modules not
> checked in
> you will have to download every time after you do a clean.  Or is there
> some way around that?
>
> npm doesn't seem to have the same concept of a local repo like Maven.
> Installing globally doesn't fix
> the problem.  Or is there a solution I don't know about?
> >
> >>> * Offline mode - the Angular2 example at the moment can't be built when
> >>> not online. It will sit around for a loooong time until it eventually
> times
> >>> out. NPM modules would have to be checked in somewhere globally (not
> just
> >>> inside target dir or something like that). Maybe they can just be
> placed
> >>> inside the .m2 dir or something?!
> > Isn't the same when you are disconnected and you try to run Maven?
> No.   You can rely on the local Maven repo.  Works great disconnected.
> >
> > Anyways, I don't think we gonna reach any consensus about it. So,
> anything
> > you guys think is the best for the project, go ahead. It's software, we
> > can always change, sometimes break :)
> >
> >>> On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
> >>>
> >>>> On 2017-05-11, Stan Silvert wrote:
> >>>>> On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> >>>>>> On 2017-05-10, Stan Silvert wrote:
> >>>>>>> The very thought of $subject seems like heresy.  Why check in
> >>>> something
> >>>>>>> that is normally pulled using npm?
> >>>>>>>
> >>>>>>> We have Angular 2 examples in Keycloak now.  In the not-too-distant
> >>>>>>> future, our Account Management console will be written in Angular
> >>>> 2.  So
> >>>>>>> node_modules has to be there somehow.
> >>>>>>>
> >>>>>>> There are basically two options:
> >>>>>>> 1)  Merge node_modules into the Keycloak repo.
> >>>>>>> 2)  Don't merge and then run npm install at build time.
> >>>>>>>
> >>>>>>> Productization standards push toward option #1.  We need to have
> >>>>>>> consistent, repeatable builds.
> >>>>>>>
> >>>>>>> But I'm looking for reasons that #1 might be bad.  I can't come up
> >>>> with
> >>>>>>> a rational reason to do #2 except that it saves disk space.
> >>>>>> My 2 cents here. I think #1 is bad for the following reasons:
> >>>>> My instinct is that it's bad too.  But I need to play devil's
> advocate.
> >>>>>> 1. That's not the convention for Node.js development. Think about
> Java
> >>>>>> devs committing JARs to our repo. Certainly that would be terrible.
> >>>>> That's just the heresy argument.
> >>>> Not really. It's also the way which QE thinks is the way to go (
> >>>> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> >>>> suecomment-300751341)
> >>>>
> >>>>>> 2. Code review becomes a PITA at every dependency update.
> >>>>> If you are talking about review in GitHub, that shouldn't be a
> problem.
> >>>>> GitHub uses linguist to hide vendor files so that it doesn't mess up
> >>>> your
> >>>>> review.  All you see is the file name.  By default, it doesn't show
> you
> >>>> the
> >>>>> whole file.  Strangely enough, the linguist guys see checking in js
> >>>>> libraries as a common practice:
> >>>>> https://github.com/github/linguist#vendored-code
> >>>> Well, you're assuming that we should all do our code reviews using
> only
> >>>> GH.
> >>>>
> >>>>>> 3. Merge conflicts. Just think about multiple devs contribution to
> the
> >>>>>> same repo and updating their modules.
> >>>>> Maybe I'm missing something here.  Wouldn't that be really rare if it
> >>>> ever
> >>>>> happened at all (in our case)?
> >>>> Not if every developer decide to run npm update :)
> >>>>
> >>>>>> 4. People could manually change these modules and you would never
> know
> >>>>>> if the change is a consequence of `npm update` or a manual change.
> >>>>> I really hope nobody would be dumb enough to do that!
> >>>>>
> >>>>> But come to think of it, this would be a security issue if someone
> did
> >>>> it on
> >>>>> purpose.   Someone could sneak malicious code into our repo disguised
> >>>> as a
> >>>>> legit PR.  It wouldn't be easy to catch during code review.
> >>>> Trust me, if people wanted to do that. They wouldn't be dumb just
> >>>> a single line
> >>>>
> >>>>>> 5. This only makes sense on scenarios where dev cannot rely on npm
> >>>>>> dependencies.
> >>>>>>
> >>>>>>
> >>>>>> IMO option #2 would be the most viable. Projects from RedHat already
> >>>> do
> >>>>>> this[1] with some success. So I don't see any need for it.
> >>>>>>
> >>>>>> [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob
> >>>> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> >>>>> Doesn't this make the build a LOT slower?
> >>>> If slowness is the major concern, we should commit every single JAR
> >>>> inside the repo and call it a day. But I don't think we do that,
> right?
> >>>> Plus, Travis can cache the dependencies[1].
> >>>>
> >>>> [1] - https://docs.travis-ci.com/user/caching/
> >>>>
> >>>>> How is Aerogear dealing with productization?
> >>>> You have to ask them, more precisely Matthias.
> >>>>
> >>>>>>
> >>>>>>> Any thoughts?
> >>>>>>> _______________________________________________
> >>>>>>> keycloak-dev mailing list
> >>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>> --
> >>>>>>
> >>>>>> abstractj
> >>>> --
> >>>>
> >>>> abstractj
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>>
> > --
> >
> > abstractj
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Schuster at bosch-si.com  Fri May 12 02:30:30 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 12 May 2017 06:30:30 +0000
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
Message-ID: <9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>

Hi Marek,

Is there a technical reason for including the routeid explicitely in the Cookie?
Normally, I would be reluctant to give out information about the setup behind
the load balancer, like how many nodes the cluster consists of.

Best regards,
Sebastian 

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda
Sent: Donnerstag, 11. Mai 2017 22:33
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] Authentication sessions & Action tokens PR

I've finally sent the PR https://github.com/keycloak/keycloak/pull/4132
with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.

Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything. 
Just some highlights:

- authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.

- I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.

- Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.

- For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key. 
You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.

- Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?

- This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.

[1] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
[2] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
[3] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html

Marek

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Fri May 12 03:34:10 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 May 2017 09:34:10 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <20170511200659.GA30905@abstractj.org>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
Message-ID: <CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>

On 11 May 2017 at 22:06, Bruno Oliveira <bruno at abstractj.org> wrote:

> Some answers inline.
>
> On 2017-05-11, Stian Thorgersen wrote:
> > Oh and also I like to just run stuff from the IDE. I very rarely build
> > Keycloak from mvn unless I'm mocking about with the distribution parts.
>
> To run stuff from your IDE, you just run npm install inside the project.
> You don't need Maven for it.
>

I'm not super keen on that either. I'm not a Node dev and most of the folks
on the team and our contributors aren't. So this has to be Java folks
friendly.


>
> >
> > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
> >
> > > I have 3 concerns around not checking in node_modules. If these are
> > > addressed I'm happy:
> > >
> > > * Productization - I believe not checking in the modules will mean they
> > > have to be available in some internal NPM repository or something.
> Those
> > > module not already available we'll have to add ourselves. Stan you
> would
> > > have to figure this out as we no longer have a dedicated prod team
> (that's
> > > us now!)
>
> Yep, I know. One of the reasons why run diff at each upgrade of these
> dependencies will sound like hell.
>

What diff are you talking about? RHSSO is just pulling in KC tags. That's
it. However, it might be that we're "cheating" the productization process
by checking in the modules.


>
> > > * Build time - just the basic Angular2 example adds overhead
>
> I won't take the road of Java vs Node.js. But pretty much you have the
> same issue with Maven, when you don't have dependencies installed.
> One way or another you have to download it from the internet.
>

Nah you don't. Because Maven has a global Maven repo on your box
(~/.m2/repository dude). As long as you've ran the build since the deps was
last changed you can just use the offline mode with Maven.


>
> > > * Offline mode - the Angular2 example at the moment can't be built when
> > > not online. It will sit around for a loooong time until it eventually
> times
> > > out. NPM modules would have to be checked in somewhere globally (not
> just
> > > inside target dir or something like that). Maybe they can just be
> placed
> > > inside the .m2 dir or something?!
>
> Isn't the same when you are disconnected and you try to run Maven?
>

Nah, see above.


>
> Anyways, I don't think we gonna reach any consensus about it. So, anything
> you guys think is the best for the project, go ahead. It's software, we
> can always change, sometimes break :)
>

I'm actually more happy with not checking it in if we can workaround the
issues and make it a Java dev friendly process.

Can all the stuff needed be retrieved with Maven plugins or would folks
have to install Node, NPM, etc, etc.. to build what is mostly a "Java
project"?


>
> > >
> > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
> > >
> > >> On 2017-05-11, Stan Silvert wrote:
> > >> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > >> > > On 2017-05-10, Stan Silvert wrote:
> > >> > > > The very thought of $subject seems like heresy.  Why check in
> > >> something
> > >> > > > that is normally pulled using npm?
> > >> > > >
> > >> > > > We have Angular 2 examples in Keycloak now.  In the
> not-too-distant
> > >> > > > future, our Account Management console will be written in
> Angular
> > >> 2.  So
> > >> > > > node_modules has to be there somehow.
> > >> > > >
> > >> > > > There are basically two options:
> > >> > > > 1)  Merge node_modules into the Keycloak repo.
> > >> > > > 2)  Don't merge and then run npm install at build time.
> > >> > > >
> > >> > > > Productization standards push toward option #1.  We need to have
> > >> > > > consistent, repeatable builds.
> > >> > > >
> > >> > > > But I'm looking for reasons that #1 might be bad.  I can't come
> up
> > >> with
> > >> > > > a rational reason to do #2 except that it saves disk space.
> > >> > > My 2 cents here. I think #1 is bad for the following reasons:
> > >> > My instinct is that it's bad too.  But I need to play devil's
> advocate.
> > >> > >
> > >> > > 1. That's not the convention for Node.js development. Think about
> Java
> > >> > > devs committing JARs to our repo. Certainly that would be
> terrible.
> > >> > That's just the heresy argument.
> > >>
> > >> Not really. It's also the way which QE thinks is the way to go (
> > >> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > >> suecomment-300751341)
> > >>
> > >> > > 2. Code review becomes a PITA at every dependency update.
> > >> > If you are talking about review in GitHub, that shouldn't be a
> problem.
> > >> > GitHub uses linguist to hide vendor files so that it doesn't mess up
> > >> your
> > >> > review.  All you see is the file name.  By default, it doesn't show
> you
> > >> the
> > >> > whole file.  Strangely enough, the linguist guys see checking in js
> > >> > libraries as a common practice:
> > >> > https://github.com/github/linguist#vendored-code
> > >>
> > >> Well, you're assuming that we should all do our code reviews using
> only
> > >> GH.
> > >>
> > >> > > 3. Merge conflicts. Just think about multiple devs contribution
> to the
> > >> > > same repo and updating their modules.
> > >> > Maybe I'm missing something here.  Wouldn't that be really rare if
> it
> > >> ever
> > >> > happened at all (in our case)?
> > >>
> > >> Not if every developer decide to run npm update :)
> > >>
> > >> > > 4. People could manually change these modules and you would never
> know
> > >> > > if the change is a consequence of `npm update` or a manual change.
> > >> > I really hope nobody would be dumb enough to do that!
> > >> >
> > >> > But come to think of it, this would be a security issue if someone
> did
> > >> it on
> > >> > purpose.   Someone could sneak malicious code into our repo
> disguised
> > >> as a
> > >> > legit PR.  It wouldn't be easy to catch during code review.
> > >>
> > >> Trust me, if people wanted to do that. They wouldn't be dumb just
> > >> a single line
> > >>
> > >> > > 5. This only makes sense on scenarios where dev cannot rely on npm
> > >> > > dependencies.
> > >> > >
> > >> > >
> > >> > > IMO option #2 would be the most viable. Projects from RedHat
> already
> > >> do
> > >> > > this[1] with some success. So I don't see any need for it.
> > >> > >
> > >> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/
> blob
> > >> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > >> > Doesn't this make the build a LOT slower?
> > >>
> > >> If slowness is the major concern, we should commit every single JAR
> > >> inside the repo and call it a day. But I don't think we do that,
> right?
> > >> Plus, Travis can cache the dependencies[1].
> > >>
> > >> [1] - https://docs.travis-ci.com/user/caching/
> > >>
> > >> >
> > >> > How is Aerogear dealing with productization?
> > >>
> > >> You have to ask them, more precisely Matthias.
> > >>
> > >> > >
> > >> > >
> > >> > > > Any thoughts?
> > >> > > > _______________________________________________
> > >> > > > keycloak-dev mailing list
> > >> > > > keycloak-dev at lists.jboss.org
> > >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >> > > --
> > >> > >
> > >> > > abstractj
> > >> >
> > >>
> > >> --
> > >>
> > >> abstractj
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > >
> > >
>
> --
>
> abstractj
>

From sthorger at redhat.com  Fri May 12 03:35:09 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 May 2017 09:35:09 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAHVh=dZpjy40+nqGwPabXt0+eiLbEXN=dhzVnyZUcmZE8MFM5w@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
	<CAHVh=dZpjy40+nqGwPabXt0+eiLbEXN=dhzVnyZUcmZE8MFM5w@mail.gmail.com>
Message-ID: <CAJgngAeDGr9dtZ_PDsE_9azR8SO6=0PEmkdzPJcd1m-kVhwTmQ@mail.gmail.com>

Is that yet another thing I've got to install ;)

As a Java dev I just wanna install the JDK and Maven then run "mvn clean
install". I don't want to have to install a bunch of Node stuff manually.

On 12 May 2017 at 03:25, Steven Mirabito <stevenmirabito at gmail.com> wrote:

> Using yarn instead of npm to manage node_modules (it's a drop-in
> replacement in most cases) will provide a local package cache similar to
> the local Maven repo: https://yarnpkg.com
>
> -Steven
>
> On Thu, May 11, 2017, 5:57 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 5/11/2017 4:06 PM, Bruno Oliveira wrote:
>> > Some answers inline.
>> More comments inline...
>> >
>> > On 2017-05-11, Stian Thorgersen wrote:
>> >> Oh and also I like to just run stuff from the IDE. I very rarely build
>> >> Keycloak from mvn unless I'm mocking about with the distribution parts.
>> > To run stuff from your IDE, you just run npm install inside the project.
>> > You don't need Maven for it.
>> >
>> >> On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
>> >>
>> >>> I have 3 concerns around not checking in node_modules. If these are
>> >>> addressed I'm happy:
>> >>>
>> >>> * Productization - I believe not checking in the modules will mean
>> they
>> >>> have to be available in some internal NPM repository or something.
>> Those
>> >>> module not already available we'll have to add ourselves. Stan you
>> would
>> >>> have to figure this out as we no longer have a dedicated prod team
>> (that's
>> >>> us now!)
>> > Yep, I know. One of the reasons why run diff at each upgrade of these
>> > dependencies will sound like hell.
>> I don't know the answer to the productization question.  SOMEBODY in
>> MiddleWare
>> must have dealt with this before.  Who can I ask?
>> >
>> >>> * Build time - just the basic Angular2 example adds overhead
>> > I won't take the road of Java vs Node.js. But pretty much you have the
>> > same issue with Maven, when you don't have dependencies installed.
>> > One way or another you have to download it from the internet.
>> With Maven, you only have to download once.  But with node_modules not
>> checked in
>> you will have to download every time after you do a clean.  Or is there
>> some way around that?
>>
>> npm doesn't seem to have the same concept of a local repo like Maven.
>> Installing globally doesn't fix
>> the problem.  Or is there a solution I don't know about?
>> >
>> >>> * Offline mode - the Angular2 example at the moment can't be built
>> when
>> >>> not online. It will sit around for a loooong time until it eventually
>> times
>> >>> out. NPM modules would have to be checked in somewhere globally (not
>> just
>> >>> inside target dir or something like that). Maybe they can just be
>> placed
>> >>> inside the .m2 dir or something?!
>> > Isn't the same when you are disconnected and you try to run Maven?
>> No.   You can rely on the local Maven repo.  Works great disconnected.
>> >
>> > Anyways, I don't think we gonna reach any consensus about it. So,
>> anything
>> > you guys think is the best for the project, go ahead. It's software, we
>> > can always change, sometimes break :)
>> >
>> >>> On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
>> >>>
>> >>>> On 2017-05-11, Stan Silvert wrote:
>> >>>>> On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
>> >>>>>> On 2017-05-10, Stan Silvert wrote:
>> >>>>>>> The very thought of $subject seems like heresy.  Why check in
>> >>>> something
>> >>>>>>> that is normally pulled using npm?
>> >>>>>>>
>> >>>>>>> We have Angular 2 examples in Keycloak now.  In the
>> not-too-distant
>> >>>>>>> future, our Account Management console will be written in Angular
>> >>>> 2.  So
>> >>>>>>> node_modules has to be there somehow.
>> >>>>>>>
>> >>>>>>> There are basically two options:
>> >>>>>>> 1)  Merge node_modules into the Keycloak repo.
>> >>>>>>> 2)  Don't merge and then run npm install at build time.
>> >>>>>>>
>> >>>>>>> Productization standards push toward option #1.  We need to have
>> >>>>>>> consistent, repeatable builds.
>> >>>>>>>
>> >>>>>>> But I'm looking for reasons that #1 might be bad.  I can't come up
>> >>>> with
>> >>>>>>> a rational reason to do #2 except that it saves disk space.
>> >>>>>> My 2 cents here. I think #1 is bad for the following reasons:
>> >>>>> My instinct is that it's bad too.  But I need to play devil's
>> advocate.
>> >>>>>> 1. That's not the convention for Node.js development. Think about
>> Java
>> >>>>>> devs committing JARs to our repo. Certainly that would be terrible.
>> >>>>> That's just the heresy argument.
>> >>>> Not really. It's also the way which QE thinks is the way to go (
>> >>>> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
>> >>>> suecomment-300751341)
>> >>>>
>> >>>>>> 2. Code review becomes a PITA at every dependency update.
>> >>>>> If you are talking about review in GitHub, that shouldn't be a
>> problem.
>> >>>>> GitHub uses linguist to hide vendor files so that it doesn't mess up
>> >>>> your
>> >>>>> review.  All you see is the file name.  By default, it doesn't show
>> you
>> >>>> the
>> >>>>> whole file.  Strangely enough, the linguist guys see checking in js
>> >>>>> libraries as a common practice:
>> >>>>> https://github.com/github/linguist#vendored-code
>> >>>> Well, you're assuming that we should all do our code reviews using
>> only
>> >>>> GH.
>> >>>>
>> >>>>>> 3. Merge conflicts. Just think about multiple devs contribution to
>> the
>> >>>>>> same repo and updating their modules.
>> >>>>> Maybe I'm missing something here.  Wouldn't that be really rare if
>> it
>> >>>> ever
>> >>>>> happened at all (in our case)?
>> >>>> Not if every developer decide to run npm update :)
>> >>>>
>> >>>>>> 4. People could manually change these modules and you would never
>> know
>> >>>>>> if the change is a consequence of `npm update` or a manual change.
>> >>>>> I really hope nobody would be dumb enough to do that!
>> >>>>>
>> >>>>> But come to think of it, this would be a security issue if someone
>> did
>> >>>> it on
>> >>>>> purpose.   Someone could sneak malicious code into our repo
>> disguised
>> >>>> as a
>> >>>>> legit PR.  It wouldn't be easy to catch during code review.
>> >>>> Trust me, if people wanted to do that. They wouldn't be dumb just
>> >>>> a single line
>> >>>>
>> >>>>>> 5. This only makes sense on scenarios where dev cannot rely on npm
>> >>>>>> dependencies.
>> >>>>>>
>> >>>>>>
>> >>>>>> IMO option #2 would be the most viable. Projects from RedHat
>> already
>> >>>> do
>> >>>>>> this[1] with some success. So I don't see any need for it.
>> >>>>>>
>> >>>>>> [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob
>> >>>> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
>> >>>>> Doesn't this make the build a LOT slower?
>> >>>> If slowness is the major concern, we should commit every single JAR
>> >>>> inside the repo and call it a day. But I don't think we do that,
>> right?
>> >>>> Plus, Travis can cache the dependencies[1].
>> >>>>
>> >>>> [1] - https://docs.travis-ci.com/user/caching/
>> >>>>
>> >>>>> How is Aerogear dealing with productization?
>> >>>> You have to ask them, more precisely Matthias.
>> >>>>
>> >>>>>>
>> >>>>>>> Any thoughts?
>> >>>>>>> _______________________________________________
>> >>>>>>> keycloak-dev mailing list
>> >>>>>>> keycloak-dev at lists.jboss.org
>> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>>> --
>> >>>>>>
>> >>>>>> abstractj
>> >>>> --
>> >>>>
>> >>>> abstractj
>> >>>> _______________________________________________
>> >>>> keycloak-dev mailing list
>> >>>> keycloak-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>>
>> >>>
>> > --
>> >
>> > abstractj
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Fri May 12 03:39:04 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 May 2017 09:39:04 +0200
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
	<76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
Message-ID: <CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>

Just to be clear I'm a bit too much of a noob on the authz services to be
very helpful, so I'm just trying to help as much as I can.

What about there's two modes for a realm. Old backwards compatible mode
with no authz services involved. This will just work exactly how it does
today. Then there's the new mode which uses authz services. The new mode
doesn't have to be compatible, but I guess we'd need to be able to easily
switch a realm from the old to the new.

That way you could switch the behaviour to what you're saying below.
"view-users" just gives permission to invoke the endpoints and show the
console bits, then authz services kicks in to control what users a user can
see?

On 11 May 2017 at 23:02, Bill Burke <bburke at redhat.com> wrote:

> I don't want to add more roles either, but I currently don't see a way to
> model your suggestion.  This is why I'm posting to dev, because I need
> ideas.  Everything is currently modeled as granting additional access, not
> restricting existing access.  "view-users" grants viewing access to all
> users and we can't break backward compatibility.  I just don't know how
> restricting viewing to a specific group of users could be modeled.
>
> The current way I have it modeled is:
>
> 1. See if admin can view all users .  There is a resource that represents
> all users.  I ask policy engine if admin has "view" scope for "Users"
> resource (i.e. (has "view-users" role).  If this passes, I let them view
> the user
>
> 2. If #1 fails, then loop through each group the user belongs to.  If
> admin has "view_members" scope for the group, i let the admin view the user
>
> If we do as you suggest, then you'd have to do the opposite of above
>
> 1. See if admin can view all users. (has "view-users" role).  This doesn't
> grant access yet, proceed to step 2.
> 2. Loop through each group the user belongs to and see if the admin is
> restricted from viewing members of this group.
>
> Do you see the problem here?   How do you model the restriction AND, at
> the same time, make sure you're backward compatible with "view-users"
> behavior?
>
>
>
>
>
>
> On 5/11/17 1:07 AM, Stian Thorgersen wrote:
>
> +1 To having a way to hide bits of the console
>
> Why not just leverage the already existing roles? We could for example
> require the view-users role to be able to view users at all. Then authz
> services simply determines what users are displayed.
>
> I'd be reluctant to add more roles as it's already quite messy IMO.
> Especially with the master realm. Then there's also the token size with
> large number of realms. Adding yet more roles would just make that even
> worse right?
>
> On 11 May 2017 at 00:07, Bill Burke <bburke at redhat.com> wrote:
>
>> I'm thinking of adding additional admin roles: "admin-console-users",
>> "admin-console-groups", "admin-console-clients" and a composite of all
>> three: "admin-console-access".  These roles exist solely for the admin
>> console and determine whether or not the "Users", "Clients", or "Groups"
>> menu items show up.  It is unfeasible to calculate this considering that
>> a restricted admin may have access to only one client in the admin
>> console or a specific set of users in a specific group.
>>
>> Alternatively, I could just display the "Users', "Clients" and "Groups"
>> menu item no matter what role mappings or permissions the restricted
>> admin has.  Then when they click on that menu item, query results are
>> filtered based on individual permissions.  I like the latter better
>> because its a better user experience.  For example, if a restricted
>> admin can only manage one client and nothing else, the admin console
>> could bring the admin directly to that client's management page.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From bruno at abstractj.org  Fri May 12 04:25:36 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 12 May 2017 05:25:36 -0300
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
Message-ID: <20170512082536.GA16567@abstractj.org>

On 2017-05-11, Stan Silvert wrote:
> On 5/11/2017 4:06 PM, Bruno Oliveira wrote:
> > Some answers inline.
> More comments inline...
> >
> > On 2017-05-11, Stian Thorgersen wrote:
> > > Oh and also I like to just run stuff from the IDE. I very rarely build
> > > Keycloak from mvn unless I'm mocking about with the distribution parts.
> > To run stuff from your IDE, you just run npm install inside the project.
> > You don't need Maven for it.
> >
> > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
> > >
> > > > I have 3 concerns around not checking in node_modules. If these are
> > > > addressed I'm happy:
> > > >
> > > > * Productization - I believe not checking in the modules will mean they
> > > > have to be available in some internal NPM repository or something. Those
> > > > module not already available we'll have to add ourselves. Stan you would
> > > > have to figure this out as we no longer have a dedicated prod team (that's
> > > > us now!)
> > Yep, I know. One of the reasons why run diff at each upgrade of these
> > dependencies will sound like hell.
> I don't know the answer to the productization question.  SOMEBODY in
> MiddleWare
> must have dealt with this before.  Who can I ask?

I just asked Node team on it. Will share the answer as soon as I hear
something back.

> >
> > > > * Build time - just the basic Angular2 example adds overhead
> > I won't take the road of Java vs Node.js. But pretty much you have the
> > same issue with Maven, when you don't have dependencies installed.
> > One way or another you have to download it from the internet.
> With Maven, you only have to download once.  But with node_modules not
> checked in
> you will have to download every time after you do a clean.  Or is there some
> way around that?

You have to download once, per project.

>
> npm doesn't seem to have the same concept of a local repo like Maven.
> Installing globally doesn't fix
> the problem.  Or is there a solution I don't know about?

The local repo lives inside the project. But no, there's no concept of
global module for project dependencies and as the author states,
that never gonna happen with npm (https://github.com/npm/npm/issues/2949#issuecomment-11408461).

> >
> > > > * Offline mode - the Angular2 example at the moment can't be built when
> > > > not online. It will sit around for a loooong time until it eventually times
> > > > out. NPM modules would have to be checked in somewhere globally (not just
> > > > inside target dir or something like that). Maybe they can just be placed
> > > > inside the .m2 dir or something?!
> > Isn't the same when you are disconnected and you try to run Maven?
> No.   You can rely on the local Maven repo.  Works great disconnected.

If you never downloaded any dependency, I doubt it ;)

> >
> > Anyways, I don't think we gonna reach any consensus about it. So, anything
> > you guys think is the best for the project, go ahead. It's software, we
> > can always change, sometimes break :)
> >
> > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
> > > >
> > > > > On 2017-05-11, Stan Silvert wrote:
> > > > > > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > > > > > On 2017-05-10, Stan Silvert wrote:
> > > > > > > > The very thought of $subject seems like heresy.  Why check in
> > > > > something
> > > > > > > > that is normally pulled using npm?
> > > > > > > >
> > > > > > > > We have Angular 2 examples in Keycloak now.  In the not-too-distant
> > > > > > > > future, our Account Management console will be written in Angular
> > > > > 2.  So
> > > > > > > > node_modules has to be there somehow.
> > > > > > > >
> > > > > > > > There are basically two options:
> > > > > > > > 1)  Merge node_modules into the Keycloak repo.
> > > > > > > > 2)  Don't merge and then run npm install at build time.
> > > > > > > >
> > > > > > > > Productization standards push toward option #1.  We need to have
> > > > > > > > consistent, repeatable builds.
> > > > > > > >
> > > > > > > > But I'm looking for reasons that #1 might be bad.  I can't come up
> > > > > with
> > > > > > > > a rational reason to do #2 except that it saves disk space.
> > > > > > > My 2 cents here. I think #1 is bad for the following reasons:
> > > > > > My instinct is that it's bad too.  But I need to play devil's advocate.
> > > > > > > 1. That's not the convention for Node.js development. Think about Java
> > > > > > > devs committing JARs to our repo. Certainly that would be terrible.
> > > > > > That's just the heresy argument.
> > > > > Not really. It's also the way which QE thinks is the way to go (
> > > > > https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > > > > suecomment-300751341)
> > > > >
> > > > > > > 2. Code review becomes a PITA at every dependency update.
> > > > > > If you are talking about review in GitHub, that shouldn't be a problem.
> > > > > > GitHub uses linguist to hide vendor files so that it doesn't mess up
> > > > > your
> > > > > > review.  All you see is the file name.  By default, it doesn't show you
> > > > > the
> > > > > > whole file.  Strangely enough, the linguist guys see checking in js
> > > > > > libraries as a common practice:
> > > > > > https://github.com/github/linguist#vendored-code
> > > > > Well, you're assuming that we should all do our code reviews using only
> > > > > GH.
> > > > >
> > > > > > > 3. Merge conflicts. Just think about multiple devs contribution to the
> > > > > > > same repo and updating their modules.
> > > > > > Maybe I'm missing something here.  Wouldn't that be really rare if it
> > > > > ever
> > > > > > happened at all (in our case)?
> > > > > Not if every developer decide to run npm update :)
> > > > >
> > > > > > > 4. People could manually change these modules and you would never know
> > > > > > > if the change is a consequence of `npm update` or a manual change.
> > > > > > I really hope nobody would be dumb enough to do that!
> > > > > >
> > > > > > But come to think of it, this would be a security issue if someone did
> > > > > it on
> > > > > > purpose.   Someone could sneak malicious code into our repo disguised
> > > > > as a
> > > > > > legit PR.  It wouldn't be easy to catch during code review.
> > > > > Trust me, if people wanted to do that. They wouldn't be dumb just
> > > > > a single line
> > > > >
> > > > > > > 5. This only makes sense on scenarios where dev cannot rely on npm
> > > > > > > dependencies.
> > > > > > >
> > > > > > >
> > > > > > > IMO option #2 would be the most viable. Projects from RedHat already
> > > > > do
> > > > > > > this[1] with some success. So I don't see any need for it.
> > > > > > >
> > > > > > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/blob
> > > > > /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > > > > > Doesn't this make the build a LOT slower?
> > > > > If slowness is the major concern, we should commit every single JAR
> > > > > inside the repo and call it a day. But I don't think we do that, right?
> > > > > Plus, Travis can cache the dependencies[1].
> > > > >
> > > > > [1] - https://docs.travis-ci.com/user/caching/
> > > > >
> > > > > > How is Aerogear dealing with productization?
> > > > > You have to ask them, more precisely Matthias.
> > > > >
> > > > > > >
> > > > > > > > Any thoughts?
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > --
> > > > > > >
> > > > > > > abstractj
> > > > > --
> > > > >
> > > > > abstractj
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >
> > > >
> > --
> >
> > abstractj
>

--

abstractj

From sthorger at redhat.com  Fri May 12 04:45:49 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 May 2017 10:45:49 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <20170512082536.GA16567@abstractj.org>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
	<20170512082536.GA16567@abstractj.org>
Message-ID: <CAJgngAf6SPLnqP=ERukXRK8o5-H05J15hpo-EeV+9igLH3Cvdg@mail.gmail.com>

On 12 May 2017 at 10:25, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2017-05-11, Stan Silvert wrote:
> > On 5/11/2017 4:06 PM, Bruno Oliveira wrote:
> > > Some answers inline.
> > More comments inline...
> > >
> > > On 2017-05-11, Stian Thorgersen wrote:
> > > > Oh and also I like to just run stuff from the IDE. I very rarely
> build
> > > > Keycloak from mvn unless I'm mocking about with the distribution
> parts.
> > > To run stuff from your IDE, you just run npm install inside the
> project.
> > > You don't need Maven for it.
> > >
> > > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > > >
> > > > > I have 3 concerns around not checking in node_modules. If these are
> > > > > addressed I'm happy:
> > > > >
> > > > > * Productization - I believe not checking in the modules will mean
> they
> > > > > have to be available in some internal NPM repository or something.
> Those
> > > > > module not already available we'll have to add ourselves. Stan you
> would
> > > > > have to figure this out as we no longer have a dedicated prod team
> (that's
> > > > > us now!)
> > > Yep, I know. One of the reasons why run diff at each upgrade of these
> > > dependencies will sound like hell.
> > I don't know the answer to the productization question.  SOMEBODY in
> > MiddleWare
> > must have dealt with this before.  Who can I ask?
>
> I just asked Node team on it. Will share the answer as soon as I hear
> something back.
>
> > >
> > > > > * Build time - just the basic Angular2 example adds overhead
> > > I won't take the road of Java vs Node.js. But pretty much you have the
> > > same issue with Maven, when you don't have dependencies installed.
> > > One way or another you have to download it from the internet.
> > With Maven, you only have to download once.  But with node_modules not
> > checked in
> > you will have to download every time after you do a clean.  Or is there
> some
> > way around that?
>
> You have to download once, per project.
>

Where is it saved? I might be mistake, but I think MVN plugins for this
stuff just puts it in target dir, which is deleted on a mvn clean


>
> >
> > npm doesn't seem to have the same concept of a local repo like Maven.
> > Installing globally doesn't fix
> > the problem.  Or is there a solution I don't know about?
>
> The local repo lives inside the project. But no, there's no concept of
> global module for project dependencies and as the author states,
> that never gonna happen with npm (https://github.com/npm/npm/
> issues/2949#issuecomment-11408461).
>

That's just plain out stupid.... Mvn repo in home dir is one of it's
greatest concepts.


>
> > >
> > > > > * Offline mode - the Angular2 example at the moment can't be built
> when
> > > > > not online. It will sit around for a loooong time until it
> eventually times
> > > > > out. NPM modules would have to be checked in somewhere globally
> (not just
> > > > > inside target dir or something like that). Maybe they can just be
> placed
> > > > > inside the .m2 dir or something?!
> > > Isn't the same when you are disconnected and you try to run Maven?
> > No.   You can rely on the local Maven repo.  Works great disconnected.
>
> If you never downloaded any dependency, I doubt it ;)
>

As I said you just run mvn build once, then you can use it offline for as
long as you want unless dependencies change.


>
> > >
> > > Anyways, I don't think we gonna reach any consensus about it. So,
> anything
> > > you guys think is the best for the project, go ahead. It's software, we
> > > can always change, sometimes break :)
> > >
> > > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> > > > >
> > > > > > On 2017-05-11, Stan Silvert wrote:
> > > > > > > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > > > > > > On 2017-05-10, Stan Silvert wrote:
> > > > > > > > > The very thought of $subject seems like heresy.  Why check
> in
> > > > > > something
> > > > > > > > > that is normally pulled using npm?
> > > > > > > > >
> > > > > > > > > We have Angular 2 examples in Keycloak now.  In the
> not-too-distant
> > > > > > > > > future, our Account Management console will be written in
> Angular
> > > > > > 2.  So
> > > > > > > > > node_modules has to be there somehow.
> > > > > > > > >
> > > > > > > > > There are basically two options:
> > > > > > > > > 1)  Merge node_modules into the Keycloak repo.
> > > > > > > > > 2)  Don't merge and then run npm install at build time.
> > > > > > > > >
> > > > > > > > > Productization standards push toward option #1.  We need
> to have
> > > > > > > > > consistent, repeatable builds.
> > > > > > > > >
> > > > > > > > > But I'm looking for reasons that #1 might be bad.  I can't
> come up
> > > > > > with
> > > > > > > > > a rational reason to do #2 except that it saves disk space.
> > > > > > > > My 2 cents here. I think #1 is bad for the following reasons:
> > > > > > > My instinct is that it's bad too.  But I need to play devil's
> advocate.
> > > > > > > > 1. That's not the convention for Node.js development. Think
> about Java
> > > > > > > > devs committing JARs to our repo. Certainly that would be
> terrible.
> > > > > > > That's just the heresy argument.
> > > > > > Not really. It's also the way which QE thinks is the way to go (
> > > > > > https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > > > > > suecomment-300751341)
> > > > > >
> > > > > > > > 2. Code review becomes a PITA at every dependency update.
> > > > > > > If you are talking about review in GitHub, that shouldn't be a
> problem.
> > > > > > > GitHub uses linguist to hide vendor files so that it doesn't
> mess up
> > > > > > your
> > > > > > > review.  All you see is the file name.  By default, it doesn't
> show you
> > > > > > the
> > > > > > > whole file.  Strangely enough, the linguist guys see checking
> in js
> > > > > > > libraries as a common practice:
> > > > > > > https://github.com/github/linguist#vendored-code
> > > > > > Well, you're assuming that we should all do our code reviews
> using only
> > > > > > GH.
> > > > > >
> > > > > > > > 3. Merge conflicts. Just think about multiple devs
> contribution to the
> > > > > > > > same repo and updating their modules.
> > > > > > > Maybe I'm missing something here.  Wouldn't that be really
> rare if it
> > > > > > ever
> > > > > > > happened at all (in our case)?
> > > > > > Not if every developer decide to run npm update :)
> > > > > >
> > > > > > > > 4. People could manually change these modules and you would
> never know
> > > > > > > > if the change is a consequence of `npm update` or a manual
> change.
> > > > > > > I really hope nobody would be dumb enough to do that!
> > > > > > >
> > > > > > > But come to think of it, this would be a security issue if
> someone did
> > > > > > it on
> > > > > > > purpose.   Someone could sneak malicious code into our repo
> disguised
> > > > > > as a
> > > > > > > legit PR.  It wouldn't be easy to catch during code review.
> > > > > > Trust me, if people wanted to do that. They wouldn't be dumb just
> > > > > > a single line
> > > > > >
> > > > > > > > 5. This only makes sense on scenarios where dev cannot rely
> on npm
> > > > > > > > dependencies.
> > > > > > > >
> > > > > > > >
> > > > > > > > IMO option #2 would be the most viable. Projects from RedHat
> already
> > > > > > do
> > > > > > > > this[1] with some success. So I don't see any need for it.
> > > > > > > >
> > > > > > > > [1] - https://github.com/aerogear/
> aerogear-unifiedpush-server/blob
> > > > > > /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > > > > > > Doesn't this make the build a LOT slower?
> > > > > > If slowness is the major concern, we should commit every single
> JAR
> > > > > > inside the repo and call it a day. But I don't think we do that,
> right?
> > > > > > Plus, Travis can cache the dependencies[1].
> > > > > >
> > > > > > [1] - https://docs.travis-ci.com/user/caching/
> > > > > >
> > > > > > > How is Aerogear dealing with productization?
> > > > > > You have to ask them, more precisely Matthias.
> > > > > >
> > > > > > > >
> > > > > > > > > Any thoughts?
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > --
> > > > > > > >
> > > > > > > > abstractj
> > > > > > --
> > > > > >
> > > > > > abstractj
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >
> > > > >
> > > --
> > >
> > > abstractj
> >
>
> --
>
> abstractj
>

From bruno at abstractj.org  Fri May 12 04:48:27 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 12 May 2017 05:48:27 -0300
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
Message-ID: <20170512084827.GB16567@abstractj.org>

On 2017-05-12, Stian Thorgersen wrote:
> On 11 May 2017 at 22:06, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Some answers inline.
> >
> > On 2017-05-11, Stian Thorgersen wrote:
> > > Oh and also I like to just run stuff from the IDE. I very rarely build
> > > Keycloak from mvn unless I'm mocking about with the distribution parts.
> >
> > To run stuff from your IDE, you just run npm install inside the project.
> > You don't need Maven for it.
> >
>
> I'm not super keen on that either. I'm not a Node dev and most of the folks
> on the team and our contributors aren't. So this has to be Java folks
> friendly.

You just have to follow instructions like "run `npm install`". Is not
that hard ;)

>
>
> >
> > >
> > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
> > >
> > > > I have 3 concerns around not checking in node_modules. If these are
> > > > addressed I'm happy:
> > > >
> > > > * Productization - I believe not checking in the modules will mean they
> > > > have to be available in some internal NPM repository or something.
> > Those
> > > > module not already available we'll have to add ourselves. Stan you
> > would
> > > > have to figure this out as we no longer have a dedicated prod team
> > (that's
> > > > us now!)
> >
> > Yep, I know. One of the reasons why run diff at each upgrade of these
> > dependencies will sound like hell.
> >
>
> What diff are you talking about? RHSSO is just pulling in KC tags. That's
> it. However, it might be that we're "cheating" the productization process
> by checking in the modules.

Let's say that you checked in these dependencies, but I decided to run
"npm update". Based on what we have for the `package.json` at the
quickstarts, the most recent version of each dependency will be
download. And now, you have to track the change for each dependency.

Let's take for example this package.json(https://github.com/keycloak/keycloak-quickstarts/pull/25/files#diff-c51a8b39c47d3e583b72b31558d0aedbR12). You pretty much would need to know
what has changed for each dependency.

>
>
> >
> > > > * Build time - just the basic Angular2 example adds overhead
> >
> > I won't take the road of Java vs Node.js. But pretty much you have the
> > same issue with Maven, when you don't have dependencies installed.
> > One way or another you have to download it from the internet.
> >
>
> Nah you don't. Because Maven has a global Maven repo on your box
> (~/.m2/repository dude). As long as you've ran the build since the deps was
> last changed you can just use the offline mode with Maven.

Yep, if you have nothing, and you are disconnected, there's no offline
dependency. What sucks and I believe is your point, is the fact
that Node don't have the concept of global repository for all
the dependencies.

>
>
> >
> > > > * Offline mode - the Angular2 example at the moment can't be built when
> > > > not online. It will sit around for a loooong time until it eventually
> > times
> > > > out. NPM modules would have to be checked in somewhere globally (not
> > just
> > > > inside target dir or something like that). Maybe they can just be
> > placed
> > > > inside the .m2 dir or something?!
> >
> > Isn't the same when you are disconnected and you try to run Maven?
> >
>
> Nah, see above.
>
>
> >
> > Anyways, I don't think we gonna reach any consensus about it. So, anything
> > you guys think is the best for the project, go ahead. It's software, we
> > can always change, sometimes break :)
> >
>
> I'm actually more happy with not checking it in if we can workaround the
> issues and make it a Java dev friendly process.
>
> Can all the stuff needed be retrieved with Maven plugins or would folks
> have to install Node, NPM, etc, etc.. to build what is mostly a "Java
> project"?

The idea behind running Maven is to automate the installation of Node dependencies
inside the project. But still, people prior to that people have to install Node.

>
>
> >
> > > >
> > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
> > > >
> > > >> On 2017-05-11, Stan Silvert wrote:
> > > >> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > >> > > On 2017-05-10, Stan Silvert wrote:
> > > >> > > > The very thought of $subject seems like heresy.  Why check in
> > > >> something
> > > >> > > > that is normally pulled using npm?
> > > >> > > >
> > > >> > > > We have Angular 2 examples in Keycloak now.  In the
> > not-too-distant
> > > >> > > > future, our Account Management console will be written in
> > Angular
> > > >> 2.  So
> > > >> > > > node_modules has to be there somehow.
> > > >> > > >
> > > >> > > > There are basically two options:
> > > >> > > > 1)  Merge node_modules into the Keycloak repo.
> > > >> > > > 2)  Don't merge and then run npm install at build time.
> > > >> > > >
> > > >> > > > Productization standards push toward option #1.  We need to have
> > > >> > > > consistent, repeatable builds.
> > > >> > > >
> > > >> > > > But I'm looking for reasons that #1 might be bad.  I can't come
> > up
> > > >> with
> > > >> > > > a rational reason to do #2 except that it saves disk space.
> > > >> > > My 2 cents here. I think #1 is bad for the following reasons:
> > > >> > My instinct is that it's bad too.  But I need to play devil's
> > advocate.
> > > >> > >
> > > >> > > 1. That's not the convention for Node.js development. Think about
> > Java
> > > >> > > devs committing JARs to our repo. Certainly that would be
> > terrible.
> > > >> > That's just the heresy argument.
> > > >>
> > > >> Not really. It's also the way which QE thinks is the way to go (
> > > >> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > > >> suecomment-300751341)
> > > >>
> > > >> > > 2. Code review becomes a PITA at every dependency update.
> > > >> > If you are talking about review in GitHub, that shouldn't be a
> > problem.
> > > >> > GitHub uses linguist to hide vendor files so that it doesn't mess up
> > > >> your
> > > >> > review.  All you see is the file name.  By default, it doesn't show
> > you
> > > >> the
> > > >> > whole file.  Strangely enough, the linguist guys see checking in js
> > > >> > libraries as a common practice:
> > > >> > https://github.com/github/linguist#vendored-code
> > > >>
> > > >> Well, you're assuming that we should all do our code reviews using
> > only
> > > >> GH.
> > > >>
> > > >> > > 3. Merge conflicts. Just think about multiple devs contribution
> > to the
> > > >> > > same repo and updating their modules.
> > > >> > Maybe I'm missing something here.  Wouldn't that be really rare if
> > it
> > > >> ever
> > > >> > happened at all (in our case)?
> > > >>
> > > >> Not if every developer decide to run npm update :)
> > > >>
> > > >> > > 4. People could manually change these modules and you would never
> > know
> > > >> > > if the change is a consequence of `npm update` or a manual change.
> > > >> > I really hope nobody would be dumb enough to do that!
> > > >> >
> > > >> > But come to think of it, this would be a security issue if someone
> > did
> > > >> it on
> > > >> > purpose.   Someone could sneak malicious code into our repo
> > disguised
> > > >> as a
> > > >> > legit PR.  It wouldn't be easy to catch during code review.
> > > >>
> > > >> Trust me, if people wanted to do that. They wouldn't be dumb just
> > > >> a single line
> > > >>
> > > >> > > 5. This only makes sense on scenarios where dev cannot rely on npm
> > > >> > > dependencies.
> > > >> > >
> > > >> > >
> > > >> > > IMO option #2 would be the most viable. Projects from RedHat
> > already
> > > >> do
> > > >> > > this[1] with some success. So I don't see any need for it.
> > > >> > >
> > > >> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/
> > blob
> > > >> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > > >> > Doesn't this make the build a LOT slower?
> > > >>
> > > >> If slowness is the major concern, we should commit every single JAR
> > > >> inside the repo and call it a day. But I don't think we do that,
> > right?
> > > >> Plus, Travis can cache the dependencies[1].
> > > >>
> > > >> [1] - https://docs.travis-ci.com/user/caching/
> > > >>
> > > >> >
> > > >> > How is Aerogear dealing with productization?
> > > >>
> > > >> You have to ask them, more precisely Matthias.
> > > >>
> > > >> > >
> > > >> > >
> > > >> > > > Any thoughts?
> > > >> > > > _______________________________________________
> > > >> > > > keycloak-dev mailing list
> > > >> > > > keycloak-dev at lists.jboss.org
> > > >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >> > > --
> > > >> > >
> > > >> > > abstractj
> > > >> >
> > > >>
> > > >> --
> > > >>
> > > >> abstractj
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>
> > > >
> > > >
> >
> > --
> >
> > abstractj
> >

--

abstractj

From sthorger at redhat.com  Fri May 12 04:56:45 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 May 2017 10:56:45 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <20170512084827.GB16567@abstractj.org>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
	<20170512084827.GB16567@abstractj.org>
Message-ID: <CAJgngAdNM0GbqjNY+PYry8DWSqpHV6t2ENLhODiNXpNUQNpikw@mail.gmail.com>

On 12 May 2017 at 10:48, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2017-05-12, Stian Thorgersen wrote:
> > On 11 May 2017 at 22:06, Bruno Oliveira <bruno at abstractj.org> wrote:
> >
> > > Some answers inline.
> > >
> > > On 2017-05-11, Stian Thorgersen wrote:
> > > > Oh and also I like to just run stuff from the IDE. I very rarely
> build
> > > > Keycloak from mvn unless I'm mocking about with the distribution
> parts.
> > >
> > > To run stuff from your IDE, you just run npm install inside the
> project.
> > > You don't need Maven for it.
> > >
> >
> > I'm not super keen on that either. I'm not a Node dev and most of the
> folks
> > on the team and our contributors aren't. So this has to be Java folks
> > friendly.
>
> You just have to follow instructions like "run `npm install`". Is not
> that hard ;)
>

Keycloak is built with "mvn clean install" from the root dir. There should
be no "npm install" commands required. This has to be done through Maven
plugins.

Remember Keycloak is built with Maven by mostly Java folks. CI, Travis,
productization, everything expects to just run mvn install.


>
> >
> >
> > >
> > > >
> > > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > > >
> > > > > I have 3 concerns around not checking in node_modules. If these are
> > > > > addressed I'm happy:
> > > > >
> > > > > * Productization - I believe not checking in the modules will mean
> they
> > > > > have to be available in some internal NPM repository or something.
> > > Those
> > > > > module not already available we'll have to add ourselves. Stan you
> > > would
> > > > > have to figure this out as we no longer have a dedicated prod team
> > > (that's
> > > > > us now!)
> > >
> > > Yep, I know. One of the reasons why run diff at each upgrade of these
> > > dependencies will sound like hell.
> > >
> >
> > What diff are you talking about? RHSSO is just pulling in KC tags. That's
> > it. However, it might be that we're "cheating" the productization process
> > by checking in the modules.
>
> Let's say that you checked in these dependencies, but I decided to run
> "npm update". Based on what we have for the `package.json` at the
> quickstarts, the most recent version of each dependency will be
> download. And now, you have to track the change for each dependency.
>
> Let's take for example this package.json(https://github.
> com/keycloak/keycloak-quickstarts/pull/25/files#diff-
> c51a8b39c47d3e583b72b31558d0aedbR12). You pretty much would need to know
> what has changed for each dependency.
>
> >
> >
> > >
> > > > > * Build time - just the basic Angular2 example adds overhead
> > >
> > > I won't take the road of Java vs Node.js. But pretty much you have the
> > > same issue with Maven, when you don't have dependencies installed.
> > > One way or another you have to download it from the internet.
> > >
> >
> > Nah you don't. Because Maven has a global Maven repo on your box
> > (~/.m2/repository dude). As long as you've ran the build since the deps
> was
> > last changed you can just use the offline mode with Maven.
>
> Yep, if you have nothing, and you are disconnected, there's no offline
> dependency. What sucks and I believe is your point, is the fact
> that Node don't have the concept of global repository for all
> the dependencies.
>
> >
> >
> > >
> > > > > * Offline mode - the Angular2 example at the moment can't be built
> when
> > > > > not online. It will sit around for a loooong time until it
> eventually
> > > times
> > > > > out. NPM modules would have to be checked in somewhere globally
> (not
> > > just
> > > > > inside target dir or something like that). Maybe they can just be
> > > placed
> > > > > inside the .m2 dir or something?!
> > >
> > > Isn't the same when you are disconnected and you try to run Maven?
> > >
> >
> > Nah, see above.
> >
> >
> > >
> > > Anyways, I don't think we gonna reach any consensus about it. So,
> anything
> > > you guys think is the best for the project, go ahead. It's software, we
> > > can always change, sometimes break :)
> > >
> >
> > I'm actually more happy with not checking it in if we can workaround the
> > issues and make it a Java dev friendly process.
> >
> > Can all the stuff needed be retrieved with Maven plugins or would folks
> > have to install Node, NPM, etc, etc.. to build what is mostly a "Java
> > project"?
>
> The idea behind running Maven is to automate the installation of Node
> dependencies
> inside the project. But still, people prior to that people have to install
> Node.
>
> >
> >
> > >
> > > > >
> > > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> > > > >
> > > > >> On 2017-05-11, Stan Silvert wrote:
> > > > >> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > > >> > > On 2017-05-10, Stan Silvert wrote:
> > > > >> > > > The very thought of $subject seems like heresy.  Why check
> in
> > > > >> something
> > > > >> > > > that is normally pulled using npm?
> > > > >> > > >
> > > > >> > > > We have Angular 2 examples in Keycloak now.  In the
> > > not-too-distant
> > > > >> > > > future, our Account Management console will be written in
> > > Angular
> > > > >> 2.  So
> > > > >> > > > node_modules has to be there somehow.
> > > > >> > > >
> > > > >> > > > There are basically two options:
> > > > >> > > > 1)  Merge node_modules into the Keycloak repo.
> > > > >> > > > 2)  Don't merge and then run npm install at build time.
> > > > >> > > >
> > > > >> > > > Productization standards push toward option #1.  We need to
> have
> > > > >> > > > consistent, repeatable builds.
> > > > >> > > >
> > > > >> > > > But I'm looking for reasons that #1 might be bad.  I can't
> come
> > > up
> > > > >> with
> > > > >> > > > a rational reason to do #2 except that it saves disk space.
> > > > >> > > My 2 cents here. I think #1 is bad for the following reasons:
> > > > >> > My instinct is that it's bad too.  But I need to play devil's
> > > advocate.
> > > > >> > >
> > > > >> > > 1. That's not the convention for Node.js development. Think
> about
> > > Java
> > > > >> > > devs committing JARs to our repo. Certainly that would be
> > > terrible.
> > > > >> > That's just the heresy argument.
> > > > >>
> > > > >> Not really. It's also the way which QE thinks is the way to go (
> > > > >> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > > > >> suecomment-300751341)
> > > > >>
> > > > >> > > 2. Code review becomes a PITA at every dependency update.
> > > > >> > If you are talking about review in GitHub, that shouldn't be a
> > > problem.
> > > > >> > GitHub uses linguist to hide vendor files so that it doesn't
> mess up
> > > > >> your
> > > > >> > review.  All you see is the file name.  By default, it doesn't
> show
> > > you
> > > > >> the
> > > > >> > whole file.  Strangely enough, the linguist guys see checking
> in js
> > > > >> > libraries as a common practice:
> > > > >> > https://github.com/github/linguist#vendored-code
> > > > >>
> > > > >> Well, you're assuming that we should all do our code reviews using
> > > only
> > > > >> GH.
> > > > >>
> > > > >> > > 3. Merge conflicts. Just think about multiple devs
> contribution
> > > to the
> > > > >> > > same repo and updating their modules.
> > > > >> > Maybe I'm missing something here.  Wouldn't that be really rare
> if
> > > it
> > > > >> ever
> > > > >> > happened at all (in our case)?
> > > > >>
> > > > >> Not if every developer decide to run npm update :)
> > > > >>
> > > > >> > > 4. People could manually change these modules and you would
> never
> > > know
> > > > >> > > if the change is a consequence of `npm update` or a manual
> change.
> > > > >> > I really hope nobody would be dumb enough to do that!
> > > > >> >
> > > > >> > But come to think of it, this would be a security issue if
> someone
> > > did
> > > > >> it on
> > > > >> > purpose.   Someone could sneak malicious code into our repo
> > > disguised
> > > > >> as a
> > > > >> > legit PR.  It wouldn't be easy to catch during code review.
> > > > >>
> > > > >> Trust me, if people wanted to do that. They wouldn't be dumb just
> > > > >> a single line
> > > > >>
> > > > >> > > 5. This only makes sense on scenarios where dev cannot rely
> on npm
> > > > >> > > dependencies.
> > > > >> > >
> > > > >> > >
> > > > >> > > IMO option #2 would be the most viable. Projects from RedHat
> > > already
> > > > >> do
> > > > >> > > this[1] with some success. So I don't see any need for it.
> > > > >> > >
> > > > >> > > [1] - https://github.com/aerogear/
> aerogear-unifiedpush-server/
> > > blob
> > > > >> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > > > >> > Doesn't this make the build a LOT slower?
> > > > >>
> > > > >> If slowness is the major concern, we should commit every single
> JAR
> > > > >> inside the repo and call it a day. But I don't think we do that,
> > > right?
> > > > >> Plus, Travis can cache the dependencies[1].
> > > > >>
> > > > >> [1] - https://docs.travis-ci.com/user/caching/
> > > > >>
> > > > >> >
> > > > >> > How is Aerogear dealing with productization?
> > > > >>
> > > > >> You have to ask them, more precisely Matthias.
> > > > >>
> > > > >> > >
> > > > >> > >
> > > > >> > > > Any thoughts?
> > > > >> > > > _______________________________________________
> > > > >> > > > keycloak-dev mailing list
> > > > >> > > > keycloak-dev at lists.jboss.org
> > > > >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >> > > --
> > > > >> > >
> > > > >> > > abstractj
> > > > >> >
> > > > >>
> > > > >> --
> > > > >>
> > > > >> abstractj
> > > > >> _______________________________________________
> > > > >> keycloak-dev mailing list
> > > > >> keycloak-dev at lists.jboss.org
> > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >>
> > > > >
> > > > >
> > >
> > > --
> > >
> > > abstractj
> > >
>
> --
>
> abstractj
>

From stevenmirabito at gmail.com  Fri May 12 04:58:47 2017
From: stevenmirabito at gmail.com (Steven Mirabito)
Date: Fri, 12 May 2017 08:58:47 +0000
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
Message-ID: <CAHVh=dZvSb9YghG9Z_zR-TnZWHJnmNwv8o4kS+Qym-oEQe7gyg@mail.gmail.com>

Looks like this Maven plugin is exactly what you're looking for:
https://github.com/eirslett/frontend-maven-plugin

As I mentioned before, I would recommend using Yarn over NPM to get the
local package caching/offline support that's also desired, which looks like
a supported configuration with the aforementioned plugin.

-Steven

On Fri, May 12, 2017, 1:31 AM Stian Thorgersen <sthorger at redhat.com> wrote:

> On 11 May 2017 at 22:06, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > Some answers inline.
> >
> > On 2017-05-11, Stian Thorgersen wrote:
> > > Oh and also I like to just run stuff from the IDE. I very rarely build
> > > Keycloak from mvn unless I'm mocking about with the distribution parts.
> >
> > To run stuff from your IDE, you just run npm install inside the project.
> > You don't need Maven for it.
> >
>
> I'm not super keen on that either. I'm not a Node dev and most of the folks
> on the team and our contributors aren't. So this has to be Java folks
> friendly.
>
>
> >
> > >
> > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com> wrote:
> > >
> > > > I have 3 concerns around not checking in node_modules. If these are
> > > > addressed I'm happy:
> > > >
> > > > * Productization - I believe not checking in the modules will mean
> they
> > > > have to be available in some internal NPM repository or something.
> > Those
> > > > module not already available we'll have to add ourselves. Stan you
> > would
> > > > have to figure this out as we no longer have a dedicated prod team
> > (that's
> > > > us now!)
> >
> > Yep, I know. One of the reasons why run diff at each upgrade of these
> > dependencies will sound like hell.
> >
>
> What diff are you talking about? RHSSO is just pulling in KC tags. That's
> it. However, it might be that we're "cheating" the productization process
> by checking in the modules.
>
>
> >
> > > > * Build time - just the basic Angular2 example adds overhead
> >
> > I won't take the road of Java vs Node.js. But pretty much you have the
> > same issue with Maven, when you don't have dependencies installed.
> > One way or another you have to download it from the internet.
> >
>
> Nah you don't. Because Maven has a global Maven repo on your box
> (~/.m2/repository dude). As long as you've ran the build since the deps was
> last changed you can just use the offline mode with Maven.
>
>
> >
> > > > * Offline mode - the Angular2 example at the moment can't be built
> when
> > > > not online. It will sit around for a loooong time until it eventually
> > times
> > > > out. NPM modules would have to be checked in somewhere globally (not
> > just
> > > > inside target dir or something like that). Maybe they can just be
> > placed
> > > > inside the .m2 dir or something?!
> >
> > Isn't the same when you are disconnected and you try to run Maven?
> >
>
> Nah, see above.
>
>
> >
> > Anyways, I don't think we gonna reach any consensus about it. So,
> anything
> > you guys think is the best for the project, go ahead. It's software, we
> > can always change, sometimes break :)
> >
>
> I'm actually more happy with not checking it in if we can workaround the
> issues and make it a Java dev friendly process.
>
> Can all the stuff needed be retrieved with Maven plugins or would folks
> have to install Node, NPM, etc, etc.. to build what is mostly a "Java
> project"?
>
>
> >
> > > >
> > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org> wrote:
> > > >
> > > >> On 2017-05-11, Stan Silvert wrote:
> > > >> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > >> > > On 2017-05-10, Stan Silvert wrote:
> > > >> > > > The very thought of $subject seems like heresy.  Why check in
> > > >> something
> > > >> > > > that is normally pulled using npm?
> > > >> > > >
> > > >> > > > We have Angular 2 examples in Keycloak now.  In the
> > not-too-distant
> > > >> > > > future, our Account Management console will be written in
> > Angular
> > > >> 2.  So
> > > >> > > > node_modules has to be there somehow.
> > > >> > > >
> > > >> > > > There are basically two options:
> > > >> > > > 1)  Merge node_modules into the Keycloak repo.
> > > >> > > > 2)  Don't merge and then run npm install at build time.
> > > >> > > >
> > > >> > > > Productization standards push toward option #1.  We need to
> have
> > > >> > > > consistent, repeatable builds.
> > > >> > > >
> > > >> > > > But I'm looking for reasons that #1 might be bad.  I can't
> come
> > up
> > > >> with
> > > >> > > > a rational reason to do #2 except that it saves disk space.
> > > >> > > My 2 cents here. I think #1 is bad for the following reasons:
> > > >> > My instinct is that it's bad too.  But I need to play devil's
> > advocate.
> > > >> > >
> > > >> > > 1. That's not the convention for Node.js development. Think
> about
> > Java
> > > >> > > devs committing JARs to our repo. Certainly that would be
> > terrible.
> > > >> > That's just the heresy argument.
> > > >>
> > > >> Not really. It's also the way which QE thinks is the way to go (
> > > >> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > > >> suecomment-300751341)
> > > >>
> > > >> > > 2. Code review becomes a PITA at every dependency update.
> > > >> > If you are talking about review in GitHub, that shouldn't be a
> > problem.
> > > >> > GitHub uses linguist to hide vendor files so that it doesn't mess
> up
> > > >> your
> > > >> > review.  All you see is the file name.  By default, it doesn't
> show
> > you
> > > >> the
> > > >> > whole file.  Strangely enough, the linguist guys see checking in
> js
> > > >> > libraries as a common practice:
> > > >> > https://github.com/github/linguist#vendored-code
> > > >>
> > > >> Well, you're assuming that we should all do our code reviews using
> > only
> > > >> GH.
> > > >>
> > > >> > > 3. Merge conflicts. Just think about multiple devs contribution
> > to the
> > > >> > > same repo and updating their modules.
> > > >> > Maybe I'm missing something here.  Wouldn't that be really rare if
> > it
> > > >> ever
> > > >> > happened at all (in our case)?
> > > >>
> > > >> Not if every developer decide to run npm update :)
> > > >>
> > > >> > > 4. People could manually change these modules and you would
> never
> > know
> > > >> > > if the change is a consequence of `npm update` or a manual
> change.
> > > >> > I really hope nobody would be dumb enough to do that!
> > > >> >
> > > >> > But come to think of it, this would be a security issue if someone
> > did
> > > >> it on
> > > >> > purpose.   Someone could sneak malicious code into our repo
> > disguised
> > > >> as a
> > > >> > legit PR.  It wouldn't be easy to catch during code review.
> > > >>
> > > >> Trust me, if people wanted to do that. They wouldn't be dumb just
> > > >> a single line
> > > >>
> > > >> > > 5. This only makes sense on scenarios where dev cannot rely on
> npm
> > > >> > > dependencies.
> > > >> > >
> > > >> > >
> > > >> > > IMO option #2 would be the most viable. Projects from RedHat
> > already
> > > >> do
> > > >> > > this[1] with some success. So I don't see any need for it.
> > > >> > >
> > > >> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/
> > blob
> > > >> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > > >> > Doesn't this make the build a LOT slower?
> > > >>
> > > >> If slowness is the major concern, we should commit every single JAR
> > > >> inside the repo and call it a day. But I don't think we do that,
> > right?
> > > >> Plus, Travis can cache the dependencies[1].
> > > >>
> > > >> [1] - https://docs.travis-ci.com/user/caching/
> > > >>
> > > >> >
> > > >> > How is Aerogear dealing with productization?
> > > >>
> > > >> You have to ask them, more precisely Matthias.
> > > >>
> > > >> > >
> > > >> > >
> > > >> > > > Any thoughts?
> > > >> > > > _______________________________________________
> > > >> > > > keycloak-dev mailing list
> > > >> > > > keycloak-dev at lists.jboss.org
> > > >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >> > > --
> > > >> > >
> > > >> > > abstractj
> > > >> >
> > > >>
> > > >> --
> > > >>
> > > >> abstractj
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>
> > > >
> > > >
> >
> > --
> >
> > abstractj
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Fri May 12 05:00:39 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 12 May 2017 06:00:39 -0300
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAJgngAf6SPLnqP=ERukXRK8o5-H05J15hpo-EeV+9igLH3Cvdg@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<7e185242-14d1-67f1-2408-634cf7cbaa75@redhat.com>
	<20170512082536.GA16567@abstractj.org>
	<CAJgngAf6SPLnqP=ERukXRK8o5-H05J15hpo-EeV+9igLH3Cvdg@mail.gmail.com>
Message-ID: <20170512090039.GC16567@abstractj.org>

On 2017-05-12, Stian Thorgersen wrote:
> On 12 May 2017 at 10:25, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> > On 2017-05-11, Stan Silvert wrote:
> > > On 5/11/2017 4:06 PM, Bruno Oliveira wrote:
> > > > Some answers inline.
> > > More comments inline...
> > > >
> > > > On 2017-05-11, Stian Thorgersen wrote:
> > > > > Oh and also I like to just run stuff from the IDE. I very rarely
> > build
> > > > > Keycloak from mvn unless I'm mocking about with the distribution
> > parts.
> > > > To run stuff from your IDE, you just run npm install inside the
> > project.
> > > > You don't need Maven for it.
> > > >
> > > > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> > > > >
> > > > > > I have 3 concerns around not checking in node_modules. If these are
> > > > > > addressed I'm happy:
> > > > > >
> > > > > > * Productization - I believe not checking in the modules will mean
> > they
> > > > > > have to be available in some internal NPM repository or something.
> > Those
> > > > > > module not already available we'll have to add ourselves. Stan you
> > would
> > > > > > have to figure this out as we no longer have a dedicated prod team
> > (that's
> > > > > > us now!)
> > > > Yep, I know. One of the reasons why run diff at each upgrade of these
> > > > dependencies will sound like hell.
> > > I don't know the answer to the productization question.  SOMEBODY in
> > > MiddleWare
> > > must have dealt with this before.  Who can I ask?
> >
> > I just asked Node team on it. Will share the answer as soon as I hear
> > something back.
> >
> > > >
> > > > > > * Build time - just the basic Angular2 example adds overhead
> > > > I won't take the road of Java vs Node.js. But pretty much you have the
> > > > same issue with Maven, when you don't have dependencies installed.
> > > > One way or another you have to download it from the internet.
> > > With Maven, you only have to download once.  But with node_modules not
> > > checked in
> > > you will have to download every time after you do a clean.  Or is there
> > some
> > > way around that?

You don't have to do that with `frontend-maven-plugin`. To make sure
that I'm not saying anything stupid, I built admin-ui from the
UnifiedPush server(https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/admin-ui)

mvn clean install - will get all the node_modules that we need.
mvn clean - will keep node_modules

One thing that I noticed now on the same plugin. You don't need to install
node by yourself. The plugin will do that for you. See:
https://github.com/eirslett/frontend-maven-plugin#installing-node-and-yarn

> >
> > You have to download once, per project.
> >
>
> Where is it saved? I might be mistake, but I think MVN plugins for this
> stuff just puts it in target dir, which is deleted on a mvn clean
>
>
> >
> > >
> > > npm doesn't seem to have the same concept of a local repo like Maven.
> > > Installing globally doesn't fix
> > > the problem.  Or is there a solution I don't know about?
> >
> > The local repo lives inside the project. But no, there's no concept of
> > global module for project dependencies and as the author states,
> > that never gonna happen with npm (https://github.com/npm/npm/
> > issues/2949#issuecomment-11408461).
> >
>
> That's just plain out stupid.... Mvn repo in home dir is one of it's
> greatest concepts.
>
>
> >
> > > >
> > > > > > * Offline mode - the Angular2 example at the moment can't be built
> > when
> > > > > > not online. It will sit around for a loooong time until it
> > eventually times
> > > > > > out. NPM modules would have to be checked in somewhere globally
> > (not just
> > > > > > inside target dir or something like that). Maybe they can just be
> > placed
> > > > > > inside the .m2 dir or something?!
> > > > Isn't the same when you are disconnected and you try to run Maven?
> > > No.   You can rely on the local Maven repo.  Works great disconnected.
> >
> > If you never downloaded any dependency, I doubt it ;)
> >
>
> As I said you just run mvn build once, then you can use it offline for as
> long as you want unless dependencies change.
>
>
> >
> > > >
> > > > Anyways, I don't think we gonna reach any consensus about it. So,
> > anything
> > > > you guys think is the best for the project, go ahead. It's software, we
> > > > can always change, sometimes break :)
> > > >
> > > > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> > > > > >
> > > > > > > On 2017-05-11, Stan Silvert wrote:
> > > > > > > > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
> > > > > > > > > On 2017-05-10, Stan Silvert wrote:
> > > > > > > > > > The very thought of $subject seems like heresy.  Why check
> > in
> > > > > > > something
> > > > > > > > > > that is normally pulled using npm?
> > > > > > > > > >
> > > > > > > > > > We have Angular 2 examples in Keycloak now.  In the
> > not-too-distant
> > > > > > > > > > future, our Account Management console will be written in
> > Angular
> > > > > > > 2.  So
> > > > > > > > > > node_modules has to be there somehow.
> > > > > > > > > >
> > > > > > > > > > There are basically two options:
> > > > > > > > > > 1)  Merge node_modules into the Keycloak repo.
> > > > > > > > > > 2)  Don't merge and then run npm install at build time.
> > > > > > > > > >
> > > > > > > > > > Productization standards push toward option #1.  We need
> > to have
> > > > > > > > > > consistent, repeatable builds.
> > > > > > > > > >
> > > > > > > > > > But I'm looking for reasons that #1 might be bad.  I can't
> > come up
> > > > > > > with
> > > > > > > > > > a rational reason to do #2 except that it saves disk space.
> > > > > > > > > My 2 cents here. I think #1 is bad for the following reasons:
> > > > > > > > My instinct is that it's bad too.  But I need to play devil's
> > advocate.
> > > > > > > > > 1. That's not the convention for Node.js development. Think
> > about Java
> > > > > > > > > devs committing JARs to our repo. Certainly that would be
> > terrible.
> > > > > > > > That's just the heresy argument.
> > > > > > > Not really. It's also the way which QE thinks is the way to go (
> > > > > > > https://github.com/keycloak/keycloak-quickstarts/pull/25#is
> > > > > > > suecomment-300751341)
> > > > > > >
> > > > > > > > > 2. Code review becomes a PITA at every dependency update.
> > > > > > > > If you are talking about review in GitHub, that shouldn't be a
> > problem.
> > > > > > > > GitHub uses linguist to hide vendor files so that it doesn't
> > mess up
> > > > > > > your
> > > > > > > > review.  All you see is the file name.  By default, it doesn't
> > show you
> > > > > > > the
> > > > > > > > whole file.  Strangely enough, the linguist guys see checking
> > in js
> > > > > > > > libraries as a common practice:
> > > > > > > > https://github.com/github/linguist#vendored-code
> > > > > > > Well, you're assuming that we should all do our code reviews
> > using only
> > > > > > > GH.
> > > > > > >
> > > > > > > > > 3. Merge conflicts. Just think about multiple devs
> > contribution to the
> > > > > > > > > same repo and updating their modules.
> > > > > > > > Maybe I'm missing something here.  Wouldn't that be really
> > rare if it
> > > > > > > ever
> > > > > > > > happened at all (in our case)?
> > > > > > > Not if every developer decide to run npm update :)
> > > > > > >
> > > > > > > > > 4. People could manually change these modules and you would
> > never know
> > > > > > > > > if the change is a consequence of `npm update` or a manual
> > change.
> > > > > > > > I really hope nobody would be dumb enough to do that!
> > > > > > > >
> > > > > > > > But come to think of it, this would be a security issue if
> > someone did
> > > > > > > it on
> > > > > > > > purpose.   Someone could sneak malicious code into our repo
> > disguised
> > > > > > > as a
> > > > > > > > legit PR.  It wouldn't be easy to catch during code review.
> > > > > > > Trust me, if people wanted to do that. They wouldn't be dumb just
> > > > > > > a single line
> > > > > > >
> > > > > > > > > 5. This only makes sense on scenarios where dev cannot rely
> > on npm
> > > > > > > > > dependencies.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > IMO option #2 would be the most viable. Projects from RedHat
> > already
> > > > > > > do
> > > > > > > > > this[1] with some success. So I don't see any need for it.
> > > > > > > > >
> > > > > > > > > [1] - https://github.com/aerogear/
> > aerogear-unifiedpush-server/blob
> > > > > > > /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
> > > > > > > > Doesn't this make the build a LOT slower?
> > > > > > > If slowness is the major concern, we should commit every single
> > JAR
> > > > > > > inside the repo and call it a day. But I don't think we do that,
> > right?
> > > > > > > Plus, Travis can cache the dependencies[1].
> > > > > > >
> > > > > > > [1] - https://docs.travis-ci.com/user/caching/
> > > > > > >
> > > > > > > > How is Aerogear dealing with productization?
> > > > > > > You have to ask them, more precisely Matthias.
> > > > > > >
> > > > > > > > >
> > > > > > > > > > Any thoughts?
> > > > > > > > > > _______________________________________________
> > > > > > > > > > keycloak-dev mailing list
> > > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > abstractj
> > > > > > > --
> > > > > > >
> > > > > > > abstractj
> > > > > > > _______________________________________________
> > > > > > > keycloak-dev mailing list
> > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > >
> > > > > >
> > > > --
> > > >
> > > > abstractj
> > >
> >
> > --
> >
> > abstractj
> >

--

abstractj

From sthorger at redhat.com  Fri May 12 05:03:04 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 May 2017 11:03:04 +0200
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAHVh=dZvSb9YghG9Z_zR-TnZWHJnmNwv8o4kS+Qym-oEQe7gyg@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
	<CAHVh=dZvSb9YghG9Z_zR-TnZWHJnmNwv8o4kS+Qym-oEQe7gyg@mail.gmail.com>
Message-ID: <CAJgngAendn29FW5Jfjr-27E2iKvShhArcwoX01bXGH1H5y4bXQ@mail.gmail.com>

That one looks good. Stan we should give it a go

On 12 May 2017 at 10:58, Steven Mirabito <stevenmirabito at gmail.com> wrote:

> Looks like this Maven plugin is exactly what you're looking for:
> https://github.com/eirslett/frontend-maven-plugin
>
> As I mentioned before, I would recommend using Yarn over NPM to get the
> local package caching/offline support that's also desired, which looks like
> a supported configuration with the aforementioned plugin.
>
> -Steven
>
> On Fri, May 12, 2017, 1:31 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> On 11 May 2017 at 22:06, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>> > Some answers inline.
>> >
>> > On 2017-05-11, Stian Thorgersen wrote:
>> > > Oh and also I like to just run stuff from the IDE. I very rarely build
>> > > Keycloak from mvn unless I'm mocking about with the distribution
>> parts.
>> >
>> > To run stuff from your IDE, you just run npm install inside the project.
>> > You don't need Maven for it.
>> >
>>
>> I'm not super keen on that either. I'm not a Node dev and most of the
>> folks
>> on the team and our contributors aren't. So this has to be Java folks
>> friendly.
>>
>>
>> >
>> > >
>> > > On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > >
>> > > > I have 3 concerns around not checking in node_modules. If these are
>> > > > addressed I'm happy:
>> > > >
>> > > > * Productization - I believe not checking in the modules will mean
>> they
>> > > > have to be available in some internal NPM repository or something.
>> > Those
>> > > > module not already available we'll have to add ourselves. Stan you
>> > would
>> > > > have to figure this out as we no longer have a dedicated prod team
>> > (that's
>> > > > us now!)
>> >
>> > Yep, I know. One of the reasons why run diff at each upgrade of these
>> > dependencies will sound like hell.
>> >
>>
>> What diff are you talking about? RHSSO is just pulling in KC tags. That's
>> it. However, it might be that we're "cheating" the productization process
>> by checking in the modules.
>>
>>
>> >
>> > > > * Build time - just the basic Angular2 example adds overhead
>> >
>> > I won't take the road of Java vs Node.js. But pretty much you have the
>> > same issue with Maven, when you don't have dependencies installed.
>> > One way or another you have to download it from the internet.
>> >
>>
>> Nah you don't. Because Maven has a global Maven repo on your box
>> (~/.m2/repository dude). As long as you've ran the build since the deps
>> was
>> last changed you can just use the offline mode with Maven.
>>
>>
>> >
>> > > > * Offline mode - the Angular2 example at the moment can't be built
>> when
>> > > > not online. It will sit around for a loooong time until it
>> eventually
>> > times
>> > > > out. NPM modules would have to be checked in somewhere globally (not
>> > just
>> > > > inside target dir or something like that). Maybe they can just be
>> > placed
>> > > > inside the .m2 dir or something?!
>> >
>> > Isn't the same when you are disconnected and you try to run Maven?
>> >
>>
>> Nah, see above.
>>
>>
>> >
>> > Anyways, I don't think we gonna reach any consensus about it. So,
>> anything
>> > you guys think is the best for the project, go ahead. It's software, we
>> > can always change, sometimes break :)
>> >
>>
>> I'm actually more happy with not checking it in if we can workaround the
>> issues and make it a Java dev friendly process.
>>
>> Can all the stuff needed be retrieved with Maven plugins or would folks
>> have to install Node, NPM, etc, etc.. to build what is mostly a "Java
>> project"?
>>
>>
>> >
>> > > >
>> > > > On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>> > > >
>> > > >> On 2017-05-11, Stan Silvert wrote:
>> > > >> > On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
>> > > >> > > On 2017-05-10, Stan Silvert wrote:
>> > > >> > > > The very thought of $subject seems like heresy.  Why check in
>> > > >> something
>> > > >> > > > that is normally pulled using npm?
>> > > >> > > >
>> > > >> > > > We have Angular 2 examples in Keycloak now.  In the
>> > not-too-distant
>> > > >> > > > future, our Account Management console will be written in
>> > Angular
>> > > >> 2.  So
>> > > >> > > > node_modules has to be there somehow.
>> > > >> > > >
>> > > >> > > > There are basically two options:
>> > > >> > > > 1)  Merge node_modules into the Keycloak repo.
>> > > >> > > > 2)  Don't merge and then run npm install at build time.
>> > > >> > > >
>> > > >> > > > Productization standards push toward option #1.  We need to
>> have
>> > > >> > > > consistent, repeatable builds.
>> > > >> > > >
>> > > >> > > > But I'm looking for reasons that #1 might be bad.  I can't
>> come
>> > up
>> > > >> with
>> > > >> > > > a rational reason to do #2 except that it saves disk space.
>> > > >> > > My 2 cents here. I think #1 is bad for the following reasons:
>> > > >> > My instinct is that it's bad too.  But I need to play devil's
>> > advocate.
>> > > >> > >
>> > > >> > > 1. That's not the convention for Node.js development. Think
>> about
>> > Java
>> > > >> > > devs committing JARs to our repo. Certainly that would be
>> > terrible.
>> > > >> > That's just the heresy argument.
>> > > >>
>> > > >> Not really. It's also the way which QE thinks is the way to go (
>> > > >> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
>> > > >> suecomment-300751341)
>> > > >>
>> > > >> > > 2. Code review becomes a PITA at every dependency update.
>> > > >> > If you are talking about review in GitHub, that shouldn't be a
>> > problem.
>> > > >> > GitHub uses linguist to hide vendor files so that it doesn't
>> mess up
>> > > >> your
>> > > >> > review.  All you see is the file name.  By default, it doesn't
>> show
>> > you
>> > > >> the
>> > > >> > whole file.  Strangely enough, the linguist guys see checking in
>> js
>> > > >> > libraries as a common practice:
>> > > >> > https://github.com/github/linguist#vendored-code
>> > > >>
>> > > >> Well, you're assuming that we should all do our code reviews using
>> > only
>> > > >> GH.
>> > > >>
>> > > >> > > 3. Merge conflicts. Just think about multiple devs contribution
>> > to the
>> > > >> > > same repo and updating their modules.
>> > > >> > Maybe I'm missing something here.  Wouldn't that be really rare
>> if
>> > it
>> > > >> ever
>> > > >> > happened at all (in our case)?
>> > > >>
>> > > >> Not if every developer decide to run npm update :)
>> > > >>
>> > > >> > > 4. People could manually change these modules and you would
>> never
>> > know
>> > > >> > > if the change is a consequence of `npm update` or a manual
>> change.
>> > > >> > I really hope nobody would be dumb enough to do that!
>> > > >> >
>> > > >> > But come to think of it, this would be a security issue if
>> someone
>> > did
>> > > >> it on
>> > > >> > purpose.   Someone could sneak malicious code into our repo
>> > disguised
>> > > >> as a
>> > > >> > legit PR.  It wouldn't be easy to catch during code review.
>> > > >>
>> > > >> Trust me, if people wanted to do that. They wouldn't be dumb just
>> > > >> a single line
>> > > >>
>> > > >> > > 5. This only makes sense on scenarios where dev cannot rely on
>> npm
>> > > >> > > dependencies.
>> > > >> > >
>> > > >> > >
>> > > >> > > IMO option #2 would be the most viable. Projects from RedHat
>> > already
>> > > >> do
>> > > >> > > this[1] with some success. So I don't see any need for it.
>> > > >> > >
>> > > >> > > [1] - https://github.com/aerogear/aerogear-unifiedpush-server/
>> > blob
>> > > >> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
>> > > >> > Doesn't this make the build a LOT slower?
>> > > >>
>> > > >> If slowness is the major concern, we should commit every single JAR
>> > > >> inside the repo and call it a day. But I don't think we do that,
>> > right?
>> > > >> Plus, Travis can cache the dependencies[1].
>> > > >>
>> > > >> [1] - https://docs.travis-ci.com/user/caching/
>> > > >>
>> > > >> >
>> > > >> > How is Aerogear dealing with productization?
>> > > >>
>> > > >> You have to ask them, more precisely Matthias.
>> > > >>
>> > > >> > >
>> > > >> > >
>> > > >> > > > Any thoughts?
>> > > >> > > > _______________________________________________
>> > > >> > > > keycloak-dev mailing list
>> > > >> > > > keycloak-dev at lists.jboss.org
>> > > >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > > >> > > --
>> > > >> > >
>> > > >> > > abstractj
>> > > >> >
>> > > >>
>> > > >> --
>> > > >>
>> > > >> abstractj
>> > > >> _______________________________________________
>> > > >> keycloak-dev mailing list
>> > > >> keycloak-dev at lists.jboss.org
>> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > > >>
>> > > >
>> > > >
>> >
>> > --
>> >
>> > abstractj
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From ssilvert at redhat.com  Fri May 12 08:23:14 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 12 May 2017 08:23:14 -0400
Subject: [keycloak-dev] Merging node_modules into Keycloak repo
In-Reply-To: <CAJgngAendn29FW5Jfjr-27E2iKvShhArcwoX01bXGH1H5y4bXQ@mail.gmail.com>
References: <95ec054c-fdfc-0697-0c72-af3f5dd3cbc1@redhat.com>
	<20170510221404.GA27289@abstractj.org>
	<39b9da66-5d18-24cc-2616-48c38847d322@redhat.com>
	<20170511131030.GA5486@abstractj.org>
	<CAJgngAc6+CK-nTPx3NWAwgHDiHQzxqLfNM2nT_1YijCrEY=-tg@mail.gmail.com>
	<CAJgngAeKOqw8ObuyURtj4=aBKw3SPeLp1cAhqxbp-h7jhr1BnA@mail.gmail.com>
	<20170511200659.GA30905@abstractj.org>
	<CAJgngAdG4_sczxOrE-zW3+ohuCvhoAhDuFp=WRsyM+7Cy-n6rQ@mail.gmail.com>
	<CAHVh=dZvSb9YghG9Z_zR-TnZWHJnmNwv8o4kS+Qym-oEQe7gyg@mail.gmail.com>
	<CAJgngAendn29FW5Jfjr-27E2iKvShhArcwoX01bXGH1H5y4bXQ@mail.gmail.com>
Message-ID: <7509eb6b-330a-7e2e-c1e5-1296afccd5c9@redhat.com>

On 5/12/2017 5:03 AM, Stian Thorgersen wrote:
> That one looks good. Stan we should give it a go
Sounds like exactly what I've been looking for.  I'll give it a try and 
hope it pans out.

Did someone on this thread mention an internal repo we should be pulling 
from for productization?
>
> On 12 May 2017 at 10:58, Steven Mirabito <stevenmirabito at gmail.com> wrote:
>
>> Looks like this Maven plugin is exactly what you're looking for:
>> https://github.com/eirslett/frontend-maven-plugin
>>
>> As I mentioned before, I would recommend using Yarn over NPM to get the
>> local package caching/offline support that's also desired, which looks like
>> a supported configuration with the aforementioned plugin.
>>
>> -Steven
>>
>> On Fri, May 12, 2017, 1:31 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> On 11 May 2017 at 22:06, Bruno Oliveira <bruno at abstractj.org> wrote:
>>>
>>>> Some answers inline.
>>>>
>>>> On 2017-05-11, Stian Thorgersen wrote:
>>>>> Oh and also I like to just run stuff from the IDE. I very rarely build
>>>>> Keycloak from mvn unless I'm mocking about with the distribution
>>> parts.
>>>> To run stuff from your IDE, you just run npm install inside the project.
>>>> You don't need Maven for it.
>>>>
>>> I'm not super keen on that either. I'm not a Node dev and most of the
>>> folks
>>> on the team and our contributors aren't. So this has to be Java folks
>>> friendly.
>>>
>>>
>>>>> On 11 May 2017 at 19:17, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>>>> I have 3 concerns around not checking in node_modules. If these are
>>>>>> addressed I'm happy:
>>>>>>
>>>>>> * Productization - I believe not checking in the modules will mean
>>> they
>>>>>> have to be available in some internal NPM repository or something.
>>>> Those
>>>>>> module not already available we'll have to add ourselves. Stan you
>>>> would
>>>>>> have to figure this out as we no longer have a dedicated prod team
>>>> (that's
>>>>>> us now!)
>>>> Yep, I know. One of the reasons why run diff at each upgrade of these
>>>> dependencies will sound like hell.
>>>>
>>> What diff are you talking about? RHSSO is just pulling in KC tags. That's
>>> it. However, it might be that we're "cheating" the productization process
>>> by checking in the modules.
>>>
>>>
>>>>>> * Build time - just the basic Angular2 example adds overhead
>>>> I won't take the road of Java vs Node.js. But pretty much you have the
>>>> same issue with Maven, when you don't have dependencies installed.
>>>> One way or another you have to download it from the internet.
>>>>
>>> Nah you don't. Because Maven has a global Maven repo on your box
>>> (~/.m2/repository dude). As long as you've ran the build since the deps
>>> was
>>> last changed you can just use the offline mode with Maven.
>>>
>>>
>>>>>> * Offline mode - the Angular2 example at the moment can't be built
>>> when
>>>>>> not online. It will sit around for a loooong time until it
>>> eventually
>>>> times
>>>>>> out. NPM modules would have to be checked in somewhere globally (not
>>>> just
>>>>>> inside target dir or something like that). Maybe they can just be
>>>> placed
>>>>>> inside the .m2 dir or something?!
>>>> Isn't the same when you are disconnected and you try to run Maven?
>>>>
>>> Nah, see above.
>>>
>>>
>>>> Anyways, I don't think we gonna reach any consensus about it. So,
>>> anything
>>>> you guys think is the best for the project, go ahead. It's software, we
>>>> can always change, sometimes break :)
>>>>
>>> I'm actually more happy with not checking it in if we can workaround the
>>> issues and make it a Java dev friendly process.
>>>
>>> Can all the stuff needed be retrieved with Maven plugins or would folks
>>> have to install Node, NPM, etc, etc.. to build what is mostly a "Java
>>> project"?
>>>
>>>
>>>>>> On 11 May 2017 at 15:10, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>>>>>> On 2017-05-11, Stan Silvert wrote:
>>>>>>>> On 5/10/2017 6:14 PM, Bruno Oliveira wrote:
>>>>>>>>> On 2017-05-10, Stan Silvert wrote:
>>>>>>>>>> The very thought of $subject seems like heresy.  Why check in
>>>>>>> something
>>>>>>>>>> that is normally pulled using npm?
>>>>>>>>>>
>>>>>>>>>> We have Angular 2 examples in Keycloak now.  In the
>>>> not-too-distant
>>>>>>>>>> future, our Account Management console will be written in
>>>> Angular
>>>>>>> 2.  So
>>>>>>>>>> node_modules has to be there somehow.
>>>>>>>>>>
>>>>>>>>>> There are basically two options:
>>>>>>>>>> 1)  Merge node_modules into the Keycloak repo.
>>>>>>>>>> 2)  Don't merge and then run npm install at build time.
>>>>>>>>>>
>>>>>>>>>> Productization standards push toward option #1.  We need to
>>> have
>>>>>>>>>> consistent, repeatable builds.
>>>>>>>>>>
>>>>>>>>>> But I'm looking for reasons that #1 might be bad.  I can't
>>> come
>>>> up
>>>>>>> with
>>>>>>>>>> a rational reason to do #2 except that it saves disk space.
>>>>>>>>> My 2 cents here. I think #1 is bad for the following reasons:
>>>>>>>> My instinct is that it's bad too.  But I need to play devil's
>>>> advocate.
>>>>>>>>> 1. That's not the convention for Node.js development. Think
>>> about
>>>> Java
>>>>>>>>> devs committing JARs to our repo. Certainly that would be
>>>> terrible.
>>>>>>>> That's just the heresy argument.
>>>>>>> Not really. It's also the way which QE thinks is the way to go (
>>>>>>> https://github.com/keycloak/keycloak-quickstarts/pull/25#is
>>>>>>> suecomment-300751341)
>>>>>>>
>>>>>>>>> 2. Code review becomes a PITA at every dependency update.
>>>>>>>> If you are talking about review in GitHub, that shouldn't be a
>>>> problem.
>>>>>>>> GitHub uses linguist to hide vendor files so that it doesn't
>>> mess up
>>>>>>> your
>>>>>>>> review.  All you see is the file name.  By default, it doesn't
>>> show
>>>> you
>>>>>>> the
>>>>>>>> whole file.  Strangely enough, the linguist guys see checking in
>>> js
>>>>>>>> libraries as a common practice:
>>>>>>>> https://github.com/github/linguist#vendored-code
>>>>>>> Well, you're assuming that we should all do our code reviews using
>>>> only
>>>>>>> GH.
>>>>>>>
>>>>>>>>> 3. Merge conflicts. Just think about multiple devs contribution
>>>> to the
>>>>>>>>> same repo and updating their modules.
>>>>>>>> Maybe I'm missing something here.  Wouldn't that be really rare
>>> if
>>>> it
>>>>>>> ever
>>>>>>>> happened at all (in our case)?
>>>>>>> Not if every developer decide to run npm update :)
>>>>>>>
>>>>>>>>> 4. People could manually change these modules and you would
>>> never
>>>> know
>>>>>>>>> if the change is a consequence of `npm update` or a manual
>>> change.
>>>>>>>> I really hope nobody would be dumb enough to do that!
>>>>>>>>
>>>>>>>> But come to think of it, this would be a security issue if
>>> someone
>>>> did
>>>>>>> it on
>>>>>>>> purpose.   Someone could sneak malicious code into our repo
>>>> disguised
>>>>>>> as a
>>>>>>>> legit PR.  It wouldn't be easy to catch during code review.
>>>>>>> Trust me, if people wanted to do that. They wouldn't be dumb just
>>>>>>> a single line
>>>>>>>
>>>>>>>>> 5. This only makes sense on scenarios where dev cannot rely on
>>> npm
>>>>>>>>> dependencies.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> IMO option #2 would be the most viable. Projects from RedHat
>>>> already
>>>>>>> do
>>>>>>>>> this[1] with some success. So I don't see any need for it.
>>>>>>>>>
>>>>>>>>> [1] - https://github.com/aerogear/aerogear-unifiedpush-server/
>>>> blob
>>>>>>> /02b133ffb49677effa347788c28c392ed3f275f0/admin-ui/pom.xml#L42
>>>>>>>> Doesn't this make the build a LOT slower?
>>>>>>> If slowness is the major concern, we should commit every single JAR
>>>>>>> inside the repo and call it a day. But I don't think we do that,
>>>> right?
>>>>>>> Plus, Travis can cache the dependencies[1].
>>>>>>>
>>>>>>> [1] - https://docs.travis-ci.com/user/caching/
>>>>>>>
>>>>>>>> How is Aerogear dealing with productization?
>>>>>>> You have to ask them, more precisely Matthias.
>>>>>>>
>>>>>>>>>
>>>>>>>>>> Any thoughts?
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> abstractj
>>>>>>> --
>>>>>>>
>>>>>>> abstractj
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>> --
>>>>
>>>> abstractj
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri May 12 09:40:40 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 May 2017 09:40:40 -0400
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
	<76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
	<CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>
Message-ID: <dab97268-b4d8-f089-1af8-e6a7660ebf2e@redhat.com>

I want business as usual for existing deployments.  I don't want people 
to have to go and reconfigure existing admins when they want to add a 
restricted admin.  Basically we can avoid access token bloat for 
old-school admins.  The new console roles will not be added for them.  
Only restricted admins using new permission model will have the extra 
"console" roles.

Let's walk through an example of creating a restricted admin that can 
only manage users that belong to a specific group.

1. Create Group "Sales"

2. Turn on fine grain permissions for "Sales" group

3. Add policy for "manage-members" for "Sales" group.  Let's say if 
restricted admin has "sales-manager" role, they can manage members of 
"Sales" group

4. Lookup user "bdecoste" who is a sales manager.

5. Grant bdecoste "sales-manager" role

6. Grant bdecoste "console-access-users" role.


Now bdecoste logs into admin console.

1. admin console queries permissions endpoint gets back a json doc:

{

    "realm-view" : false,

    "clients-view" : false,

    "users-view" : true

    "groups-view" : false

}

admin console only displays "Users" menu option because bdecoste only 
has the "console-access-users" role.

2. bdecoste goes to user list screen and clicks "view all users"

3. REST invocation filters out users that don't belong to "Sales" group 
based on policies set earlier

4. bdecoste clicks on a sales associate he wants to manage

5. REST call to get permissions for that user that the restricted admin 
has:

{

    "user" : "username",

    "view" : true,

    "manage" : true

}

6. Admin console displays user detail based on permissions call for that 
user


On 5/12/17 3:39 AM, Stian Thorgersen wrote:
> Just to be clear I'm a bit too much of a noob on the authz services to 
> be very helpful, so I'm just trying to help as much as I can.
>
> What about there's two modes for a realm. Old backwards compatible 
> mode with no authz services involved. This will just work exactly how 
> it does today. Then there's the new mode which uses authz services. 
> The new mode doesn't have to be compatible, but I guess we'd need to 
> be able to easily switch a realm from the old to the new.
>
> That way you could switch the behaviour to what you're saying below. 
> "view-users" just gives permission to invoke the endpoints and show 
> the console bits, then authz services kicks in to control what users a 
> user can see?
>
> On 11 May 2017 at 23:02, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I don't want to add more roles either, but I currently don't see a
>     way to model your suggestion. This is why I'm posting to dev,
>     because I need ideas.  Everything is currently modeled as granting
>     additional access, not restricting existing access. "view-users"
>     grants viewing access to all users and we can't break backward
>     compatibility.  I just don't know how restricting viewing to a
>     specific group of users could be modeled.
>
>     The current way I have it modeled is:
>
>     1. See if admin can view all users .  There is a resource that
>     represents all users.  I ask policy engine if admin has "view"
>     scope for "Users" resource (i.e. (has "view-users" role).  If this
>     passes, I let them view the user
>
>     2. If #1 fails, then loop through each group the user belongs to. 
>     If admin has "view_members" scope for the group, i let the admin
>     view the user
>
>
>     If we do as you suggest, then you'd have to do the opposite of above
>
>     1. See if admin can view all users. (has "view-users" role).  This
>     doesn't grant access yet, proceed to step 2.
>     2. Loop through each group the user belongs to and see if the
>     admin is restricted from viewing members of this group.
>
>     Do you see the problem here?   How do you model the restriction
>     AND, at the same time, make sure you're backward compatible with
>     "view-users" behavior?
>
>
>
>
>
>     On 5/11/17 1:07 AM, Stian Thorgersen wrote:
>>     +1 To having a way to hide bits of the console
>>
>>     Why not just leverage the already existing roles? We could for
>>     example require the view-users role to be able to view users at
>>     all. Then authz services simply determines what users are displayed.
>>
>>     I'd be reluctant to add more roles as it's already quite messy
>>     IMO. Especially with the master realm. Then there's also the
>>     token size with large number of realms. Adding yet more roles
>>     would just make that even worse right?
>>
>>     On 11 May 2017 at 00:07, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         I'm thinking of adding additional admin roles:
>>         "admin-console-users",
>>         "admin-console-groups", "admin-console-clients" and a
>>         composite of all
>>         three: "admin-console-access".  These roles exist solely for
>>         the admin
>>         console and determine whether or not the "Users", "Clients",
>>         or "Groups"
>>         menu items show up.  It is unfeasible to calculate this
>>         considering that
>>         a restricted admin may have access to only one client in the
>>         admin
>>         console or a specific set of users in a specific group.
>>
>>         Alternatively, I could just display the "Users', "Clients"
>>         and "Groups"
>>         menu item no matter what role mappings or permissions the
>>         restricted
>>         admin has.  Then when they click on that menu item, query
>>         results are
>>         filtered based on individual permissions. I like the latter
>>         better
>>         because its a better user experience.  For example, if a
>>         restricted
>>         admin can only manage one client and nothing else, the admin
>>         console
>>         could bring the admin directly to that client's management page.
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From psilva at redhat.com  Fri May 12 10:47:38 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 12 May 2017 11:47:38 -0300
Subject: [keycloak-dev] Clearing AuthZ Cache
Message-ID: <CAJrcDBevQF9j-vo2NU2vE=1tFn9twwR=JaEii9FJxY=rMFfZFA@mail.gmail.com>

May I add a "Authorization Cache" to realm's "Cache" tab ?

Regards.
Pedro Igor

From psilva at redhat.com  Fri May 12 11:05:26 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 12 May 2017 12:05:26 -0300
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <dab97268-b4d8-f089-1af8-e6a7660ebf2e@redhat.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
	<76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
	<CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>
	<dab97268-b4d8-f089-1af8-e6a7660ebf2e@redhat.com>
Message-ID: <CAJrcDBdeKA2H4VOssW5Nj3sj3hyegyauBovLfLGM0mj8FmrAWQ@mail.gmail.com>

On Fri, May 12, 2017 at 10:40 AM, Bill Burke <bburke at redhat.com> wrote:

> I want business as usual for existing deployments.  I don't want people
> to have to go and reconfigure existing admins when they want to add a
> restricted admin.  Basically we can avoid access token bloat for
> old-school admins.  The new console roles will not be added for them.
> Only restricted admins using new permission model will have the extra
> "console" roles.
>
> Let's walk through an example of creating a restricted admin that can
> only manage users that belong to a specific group.
>
> 1. Create Group "Sales"
>
> 2. Turn on fine grain permissions for "Sales" group
>
> 3. Add policy for "manage-members" for "Sales" group.  Let's say if
> restricted admin has "sales-manager" role, they can manage members of
> "Sales" group
>
> 4. Lookup user "bdecoste" who is a sales manager.
>
> 5. Grant bdecoste "sales-manager" role
>
> 6. Grant bdecoste "console-access-users" role.
>
>
> Now bdecoste logs into admin console.
>
> 1. admin console queries permissions endpoint gets back a json doc:
>
> {
>
>     "realm-view" : false,
>
>     "clients-view" : false,
>
>     "users-view" : true
>
>     "groups-view" : false
>
> }
>

It seems you have created a "permission endpoint" to build this permission
json doc. But i'm wondering if can just make the admin console behave like
any other client accessing an API protected by our policy enforcers.

The idea is that the admin console would basically manage whatever the
permissions are within a RPT and send this RPT on every single request. So
we would also have the Admin REST API protected.

For instance.

1. User logs in.
2. We invoke the Entitlement API to obtain permissions for a specific set
of resources that we need to build the UI.
3. We get a RPT with the permissions. Something like that:

{
    permissions: {
        "resource_set_name" : "User",
       "scopes": {
           "view"
       }
    }
}

4. The admin console reads this permissions and build the Menu accordingly
where only "User" menu option is displayed.


>
> admin console only displays "Users" menu option because bdecoste only
> has the "console-access-users" role.
>
> 2. bdecoste goes to user list screen and clicks "view all users"
>
> 3. REST invocation filters out users that don't belong to "Sales" group
> based on policies set earlier
>
> 4. bdecoste clicks on a sales associate he wants to manage
>
> 5. REST call to get permissions for that user that the restricted admin
> has:
>
> {
>
>     "user" : "username",
>
>     "view" : true,
>
>     "manage" : true
>
> }
>
> 6. Admin console displays user detail based on permissions call for that
> user
>
>
> On 5/12/17 3:39 AM, Stian Thorgersen wrote:
> > Just to be clear I'm a bit too much of a noob on the authz services to
> > be very helpful, so I'm just trying to help as much as I can.
> >
> > What about there's two modes for a realm. Old backwards compatible
> > mode with no authz services involved. This will just work exactly how
> > it does today. Then there's the new mode which uses authz services.
> > The new mode doesn't have to be compatible, but I guess we'd need to
> > be able to easily switch a realm from the old to the new.
> >
> > That way you could switch the behaviour to what you're saying below.
> > "view-users" just gives permission to invoke the endpoints and show
> > the console bits, then authz services kicks in to control what users a
> > user can see?
> >
> > On 11 May 2017 at 23:02, Bill Burke <bburke at redhat.com
> > <mailto:bburke at redhat.com>> wrote:
> >
> >     I don't want to add more roles either, but I currently don't see a
> >     way to model your suggestion. This is why I'm posting to dev,
> >     because I need ideas.  Everything is currently modeled as granting
> >     additional access, not restricting existing access. "view-users"
> >     grants viewing access to all users and we can't break backward
> >     compatibility.  I just don't know how restricting viewing to a
> >     specific group of users could be modeled.
> >
> >     The current way I have it modeled is:
> >
> >     1. See if admin can view all users .  There is a resource that
> >     represents all users.  I ask policy engine if admin has "view"
> >     scope for "Users" resource (i.e. (has "view-users" role).  If this
> >     passes, I let them view the user
> >
> >     2. If #1 fails, then loop through each group the user belongs to.
> >     If admin has "view_members" scope for the group, i let the admin
> >     view the user
> >
> >
> >     If we do as you suggest, then you'd have to do the opposite of above
> >
> >     1. See if admin can view all users. (has "view-users" role).  This
> >     doesn't grant access yet, proceed to step 2.
> >     2. Loop through each group the user belongs to and see if the
> >     admin is restricted from viewing members of this group.
> >
> >     Do you see the problem here?   How do you model the restriction
> >     AND, at the same time, make sure you're backward compatible with
> >     "view-users" behavior?
> >
> >
> >
> >
> >
> >     On 5/11/17 1:07 AM, Stian Thorgersen wrote:
> >>     +1 To having a way to hide bits of the console
> >>
> >>     Why not just leverage the already existing roles? We could for
> >>     example require the view-users role to be able to view users at
> >>     all. Then authz services simply determines what users are displayed.
> >>
> >>     I'd be reluctant to add more roles as it's already quite messy
> >>     IMO. Especially with the master realm. Then there's also the
> >>     token size with large number of realms. Adding yet more roles
> >>     would just make that even worse right?
> >>
> >>     On 11 May 2017 at 00:07, Bill Burke <bburke at redhat.com
> >>     <mailto:bburke at redhat.com>> wrote:
> >>
> >>         I'm thinking of adding additional admin roles:
> >>         "admin-console-users",
> >>         "admin-console-groups", "admin-console-clients" and a
> >>         composite of all
> >>         three: "admin-console-access".  These roles exist solely for
> >>         the admin
> >>         console and determine whether or not the "Users", "Clients",
> >>         or "Groups"
> >>         menu items show up.  It is unfeasible to calculate this
> >>         considering that
> >>         a restricted admin may have access to only one client in the
> >>         admin
> >>         console or a specific set of users in a specific group.
> >>
> >>         Alternatively, I could just display the "Users', "Clients"
> >>         and "Groups"
> >>         menu item no matter what role mappings or permissions the
> >>         restricted
> >>         admin has.  Then when they click on that menu item, query
> >>         results are
> >>         filtered based on individual permissions. I like the latter
> >>         better
> >>         because its a better user experience.  For example, if a
> >>         restricted
> >>         admin can only manage one client and nothing else, the admin
> >>         console
> >>         could bring the admin directly to that client's management page.
> >>         _______________________________________________
> >>         keycloak-dev mailing list
> >>         keycloak-dev at lists.jboss.org
> >>         <mailto:keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Fri May 12 11:37:00 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 May 2017 11:37:00 -0400
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <CAJrcDBdeKA2H4VOssW5Nj3sj3hyegyauBovLfLGM0mj8FmrAWQ@mail.gmail.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
	<76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
	<CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>
	<dab97268-b4d8-f089-1af8-e6a7660ebf2e@redhat.com>
	<CAJrcDBdeKA2H4VOssW5Nj3sj3hyegyauBovLfLGM0mj8FmrAWQ@mail.gmail.com>
Message-ID: <0091df17-58c5-b0b4-009d-587e8289637d@redhat.com>



On 5/12/17 11:05 AM, Pedro Igor Silva wrote:
> On Fri, May 12, 2017 at 10:40 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I want business as usual for existing deployments.  I don't want
>     people
>     to have to go and reconfigure existing admins when they want to add a
>     restricted admin.  Basically we can avoid access token bloat for
>     old-school admins.  The new console roles will not be added for them.
>     Only restricted admins using new permission model will have the extra
>     "console" roles.
>
>     Let's walk through an example of creating a restricted admin that can
>     only manage users that belong to a specific group.
>
>     1. Create Group "Sales"
>
>     2. Turn on fine grain permissions for "Sales" group
>
>     3. Add policy for "manage-members" for "Sales" group. Let's say if
>     restricted admin has "sales-manager" role, they can manage members of
>     "Sales" group
>
>     4. Lookup user "bdecoste" who is a sales manager.
>
>     5. Grant bdecoste "sales-manager" role
>
>     6. Grant bdecoste "console-access-users" role.
>
>
>     Now bdecoste logs into admin console.
>
>     1. admin console queries permissions endpoint gets back a json doc:
>
>     {
>
>         "realm-view" : false,
>
>         "clients-view" : false,
>
>         "users-view" : true
>
>         "groups-view" : false
>
>     }
>
>
> It seems you have created a "permission endpoint" to build this 
> permission json doc. But i'm wondering if can just make the admin 
> console behave like any other client accessing an API protected by our 
> policy enforcers.
>
> The idea is that the admin console would basically manage whatever the 
> permissions are within a RPT and send this RPT on every single 
> request. So we would also have the Admin REST API protected.
>
> For instance.
>
> 1. User logs in.
> 2. We invoke the Entitlement API to obtain permissions for a specific 
> set of resources that we need to build the UI.
> 3. We get a RPT with the permissions. Something like that:
>
> {
>     permissions: {
>         "resource_set_name" : "User",
>        "scopes": {
>            "view"
>        }
>     }
> }
>
You made me think awhile if I should do this or not.  I don't think I 
can use the entitlement service for most things.

I do this custom endpoint because Authz may not be initialized yet for 
the particular resource I"m interested in.  We aren't going to create a 
Migration script that creates Authz resources for every Group, Role, and 
Client.  We have deployments of Keycloak that have tens of thousands of 
Groups and Roles and hundreds of clients.  We also have deployments that 
may have hundreds of Realms.  We have to be very careful what we do in 
Migration scripts as we don't want Keycloak to have a 1 hour boot up 
time as it creates thousands and thousands of new rows in the database.  
There also will NEVER be a resource created per-user as this would just 
not be scalable.  This is why I want the Authz model to be populated as 
needed, not out of the box.

So, if I wanted to use the entitlement service, I really could only use 
it for what menu items to show on the front page of the admin console. 
Permissions for individual groups, clients, roles, and users will need a 
custom REST API as the corresponding Authz datamodel might not be 
initialized yet.

Bill

From psilva at redhat.com  Fri May 12 12:06:19 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 12 May 2017 13:06:19 -0300
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <0091df17-58c5-b0b4-009d-587e8289637d@redhat.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
	<76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
	<CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>
	<dab97268-b4d8-f089-1af8-e6a7660ebf2e@redhat.com>
	<CAJrcDBdeKA2H4VOssW5Nj3sj3hyegyauBovLfLGM0mj8FmrAWQ@mail.gmail.com>
	<0091df17-58c5-b0b4-009d-587e8289637d@redhat.com>
Message-ID: <CAJrcDBc2ZRXJAbiehFumwF+uMdFtxBOe4dqwS7Zre1hC1TSwNg@mail.gmail.com>

On Fri, May 12, 2017 at 12:37 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 5/12/17 11:05 AM, Pedro Igor Silva wrote:
>
> On Fri, May 12, 2017 at 10:40 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> I want business as usual for existing deployments.  I don't want people
>> to have to go and reconfigure existing admins when they want to add a
>> restricted admin.  Basically we can avoid access token bloat for
>> old-school admins.  The new console roles will not be added for them.
>> Only restricted admins using new permission model will have the extra
>> "console" roles.
>>
>> Let's walk through an example of creating a restricted admin that can
>> only manage users that belong to a specific group.
>>
>> 1. Create Group "Sales"
>>
>> 2. Turn on fine grain permissions for "Sales" group
>>
>> 3. Add policy for "manage-members" for "Sales" group.  Let's say if
>> restricted admin has "sales-manager" role, they can manage members of
>> "Sales" group
>>
>> 4. Lookup user "bdecoste" who is a sales manager.
>>
>> 5. Grant bdecoste "sales-manager" role
>>
>> 6. Grant bdecoste "console-access-users" role.
>>
>>
>> Now bdecoste logs into admin console.
>>
>> 1. admin console queries permissions endpoint gets back a json doc:
>>
>> {
>>
>>     "realm-view" : false,
>>
>>     "clients-view" : false,
>>
>>     "users-view" : true
>>
>>     "groups-view" : false
>>
>> }
>>
>
> It seems you have created a "permission endpoint" to build this permission
> json doc. But i'm wondering if can just make the admin console behave like
> any other client accessing an API protected by our policy enforcers.
>
> The idea is that the admin console would basically manage whatever the
> permissions are within a RPT and send this RPT on every single request. So
> we would also have the Admin REST API protected.
>
> For instance.
>
> 1. User logs in.
> 2. We invoke the Entitlement API to obtain permissions for a specific set
> of resources that we need to build the UI.
> 3. We get a RPT with the permissions. Something like that:
>
> {
>     permissions: {
>         "resource_set_name" : "User",
>        "scopes": {
>            "view"
>        }
>     }
> }
>
> You made me think awhile if I should do this or not.  I don't think I can
> use the entitlement service for most things.
>
> I do this custom endpoint because Authz may not be initialized yet for the
> particular resource I"m interested in.  We aren't going to create a
> Migration script that creates Authz resources for every Group, Role, and
> Client.  We have deployments of Keycloak that have tens of thousands of
> Groups and Roles and hundreds of clients.  We also have deployments that
> may have hundreds of Realms.  We have to be very careful what we do in
> Migration scripts as we don't want Keycloak to have a 1 hour boot up time
> as it creates thousands and thousands of new rows in the database.  There
> also will NEVER be a resource created per-user as this would just not be
> scalable.  This is why I want the Authz model to be populated as needed,
> not out of the box.
>
> So, if I wanted to use the entitlement service, I really could only use it
> for what menu items to show on the front page of the admin console.
> Permissions for individual groups, clients, roles, and users will need a
> custom REST API as the corresponding Authz datamodel might not be
> initialized yet.
>

+1. That is my point. We can use it for building UI based on current user
permissions.

For resource specific permissions, I'm not sure. Before saying something at
this regard I need to understand better how are you doing this.


>
> Bill
>

From psilva at redhat.com  Fri May 12 12:08:12 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 12 May 2017 13:08:12 -0300
Subject: [keycloak-dev] restricted admin console access
In-Reply-To: <CAJrcDBc2ZRXJAbiehFumwF+uMdFtxBOe4dqwS7Zre1hC1TSwNg@mail.gmail.com>
References: <5421ebb3-17bd-b279-1846-5164ab37919b@redhat.com>
	<CAJgngAdVcoWVLPQEpEGY4skkKven2FDxCVeUkVm7Eg3KYDmnXA@mail.gmail.com>
	<76bd4e21-72ce-d4c5-b48b-cbe2eca3e4a7@redhat.com>
	<CAJgngAc9hrmdT0Hot2jbiqb6R8gF_OJi+Wm0=sQfxXgZ4xKAfA@mail.gmail.com>
	<dab97268-b4d8-f089-1af8-e6a7660ebf2e@redhat.com>
	<CAJrcDBdeKA2H4VOssW5Nj3sj3hyegyauBovLfLGM0mj8FmrAWQ@mail.gmail.com>
	<0091df17-58c5-b0b4-009d-587e8289637d@redhat.com>
	<CAJrcDBc2ZRXJAbiehFumwF+uMdFtxBOe4dqwS7Zre1hC1TSwNg@mail.gmail.com>
Message-ID: <CAJrcDBcx1MbPu-474JNwDXKD=Sk57hTa8MPp0y3q26sWAHNvbw@mail.gmail.com>

Btw, for the UI part of the discussion I have a simple example. A fairly
simple angular client building a menu with the permissions obtained from
the server.

On Fri, May 12, 2017 at 1:06 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> On Fri, May 12, 2017 at 12:37 PM, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 5/12/17 11:05 AM, Pedro Igor Silva wrote:
>>
>> On Fri, May 12, 2017 at 10:40 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> I want business as usual for existing deployments.  I don't want people
>>> to have to go and reconfigure existing admins when they want to add a
>>> restricted admin.  Basically we can avoid access token bloat for
>>> old-school admins.  The new console roles will not be added for them.
>>> Only restricted admins using new permission model will have the extra
>>> "console" roles.
>>>
>>> Let's walk through an example of creating a restricted admin that can
>>> only manage users that belong to a specific group.
>>>
>>> 1. Create Group "Sales"
>>>
>>> 2. Turn on fine grain permissions for "Sales" group
>>>
>>> 3. Add policy for "manage-members" for "Sales" group.  Let's say if
>>> restricted admin has "sales-manager" role, they can manage members of
>>> "Sales" group
>>>
>>> 4. Lookup user "bdecoste" who is a sales manager.
>>>
>>> 5. Grant bdecoste "sales-manager" role
>>>
>>> 6. Grant bdecoste "console-access-users" role.
>>>
>>>
>>> Now bdecoste logs into admin console.
>>>
>>> 1. admin console queries permissions endpoint gets back a json doc:
>>>
>>> {
>>>
>>>     "realm-view" : false,
>>>
>>>     "clients-view" : false,
>>>
>>>     "users-view" : true
>>>
>>>     "groups-view" : false
>>>
>>> }
>>>
>>
>> It seems you have created a "permission endpoint" to build this
>> permission json doc. But i'm wondering if can just make the admin console
>> behave like any other client accessing an API protected by our policy
>> enforcers.
>>
>> The idea is that the admin console would basically manage whatever the
>> permissions are within a RPT and send this RPT on every single request. So
>> we would also have the Admin REST API protected.
>>
>> For instance.
>>
>> 1. User logs in.
>> 2. We invoke the Entitlement API to obtain permissions for a specific set
>> of resources that we need to build the UI.
>> 3. We get a RPT with the permissions. Something like that:
>>
>> {
>>     permissions: {
>>         "resource_set_name" : "User",
>>        "scopes": {
>>            "view"
>>        }
>>     }
>> }
>>
>> You made me think awhile if I should do this or not.  I don't think I can
>> use the entitlement service for most things.
>>
>> I do this custom endpoint because Authz may not be initialized yet for
>> the particular resource I"m interested in.  We aren't going to create a
>> Migration script that creates Authz resources for every Group, Role, and
>> Client.  We have deployments of Keycloak that have tens of thousands of
>> Groups and Roles and hundreds of clients.  We also have deployments that
>> may have hundreds of Realms.  We have to be very careful what we do in
>> Migration scripts as we don't want Keycloak to have a 1 hour boot up time
>> as it creates thousands and thousands of new rows in the database.  There
>> also will NEVER be a resource created per-user as this would just not be
>> scalable.  This is why I want the Authz model to be populated as needed,
>> not out of the box.
>>
>> So, if I wanted to use the entitlement service, I really could only use
>> it for what menu items to show on the front page of the admin console.
>> Permissions for individual groups, clients, roles, and users will need a
>> custom REST API as the corresponding Authz datamodel might not be
>> initialized yet.
>>
>
> +1. That is my point. We can use it for building UI based on current user
> permissions.
>
> For resource specific permissions, I'm not sure. Before saying something
> at this regard I need to understand better how are you doing this.
>
>
>>
>> Bill
>>
>
>

From thomas.darimont at googlemail.com  Sat May 13 03:32:45 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 13 May 2017 09:32:45 +0200
Subject: [keycloak-dev] JOSEPH JavaScript Object Signing and Encryption
	Pentesting Helper
Message-ID: <CAK-7U1h1oMDRnvbYKcrDkbzjXgFDT+YB23ou=PtAnY_RMcf-kw@mail.gmail.com>

Hello group,

I just stumbled upon the interesting tool JOSPEH (
https://github.com/RUB-NDS/JOSEPH)
that was presented at the OWASP AppSec EU Conference (
https://2017.appsec.eu/program/)
which I'd like to share.

JOSEPH is basically a BURP extension that allows to analyze JWE / JWS
structures in HTTP messages and to pentest endpoints which can process JWS
structures with a list of well-known attacks.

Talk: On the (in-)security of JavaScript Object Signing and Encryption
https://appseceurope2017.sched.com/event/A65e/on-the-in-security-of-javascript-object-signing-and-encryption?iframe=no&w=100%&sidebar=yes&bg=no

Cheers,
Thomas

From manwoodvice at gmail.com  Sat May 13 05:20:45 2017
From: manwoodvice at gmail.com (mark)
Date: Sat, 13 May 2017 17:20:45 +0800
Subject: [keycloak-dev] Help getting started configuring the server?
Message-ID: <CABgaDxjin=dapwGYigrVA82f5hNUoVH5F0v1eU-qWyLsLZRJ2g@mail.gmail.com>

I am new to Keycloak and have been through the manual, I have also seen the
code quickstarts, what I am missing is the same for the server setup.

I am aiming for a simple setup initially:

- running locally in stand alone mode (already done)
- one realm, two user roles
- users can register as one of the two roles
- client application uses the initialization code flow
- client is using spring boot (if that makes a difference)

Are there any walk throughs for server config?

Thanks

From braoru at gmail.com  Sat May 13 06:22:47 2017
From: braoru at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Pasche?=)
Date: Sat, 13 May 2017 12:22:47 +0200
Subject: [keycloak-dev] Trying to ADD WS-Fed support for both protocol and
	broker into keycloak
Message-ID: <CAPfD7PnnXg5m0hDH4PxxHHBLBKqaweX3fmKCzu1LAECYTPh-xA@mail.gmail.com>

Hello,


We are a small team starting to develop/assembly an open source CASB solution.


We just wanted to say we will start to work on the code developed by
dbarentine  On PR ?KEYCLOAK-2000 WS-Fed support for both protocol and
broker?. https://github.com/keycloak/keycloak/pull/1766


The idea is to first work on a module to improve the current code
until it reaches WS-FED protocol support & quality level to make a new
proper PR (or keep it a module if it?s should be that way).


@dbarentine offered the latest version of his code (target 2.5.5.Final)
The new repository is here : https://github.com/cloudtrust/keycloak-wsfed


We will start to work on making it run on the latest version of
keycloak then start to complete it.

Anyone who want to help us is welcome :-)

Best

Sebastien


From pnalyvayko at agi.com  Sat May 13 13:06:24 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Sat, 13 May 2017 17:06:24 +0000
Subject: [keycloak-dev] Trying to ADD WS-Fed support for both protocol
	and	broker into keycloak
In-Reply-To: <CAPfD7PnnXg5m0hDH4PxxHHBLBKqaweX3fmKCzu1LAECYTPh-xA@mail.gmail.com>
References: <CAPfD7PnnXg5m0hDH4PxxHHBLBKqaweX3fmKCzu1LAECYTPh-xA@mail.gmail.com>
Message-ID: <DM5PR07MB2937889A20E96F562594571FDAE30@DM5PR07MB2937.namprd07.prod.outlook.com>

Hi Sebastien,

Perhaps we can combine our efforts. I've done a fair amount of work to adopt the work originally developed by Dan Barentine and his team to support WS-Fed protocol in keycloak. The current version is based off of version 2.3.0. Among new features not present in the original submission is the support for SAML 1.1 tokens which was added to enable older clients. 

The wsfed related repository is here: https://github.com/brat000012001/keycloak/tree/wsfed-2.3.0.x

Let me know how you and your team want to proceed.

Cheers,
Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of S?bastien Pasche [braoru at gmail.com]
Sent: Saturday, May 13, 2017 6:22 AM
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] Trying to ADD WS-Fed support for both protocol and      broker into keycloak

Hello,


We are a small team starting to develop/assembly an open source CASB solution.


We just wanted to say we will start to work on the code developed by
dbarentine  On PR ?KEYCLOAK-2000 WS-Fed support for both protocol and
broker?. https://github.com/keycloak/keycloak/pull/1766


The idea is to first work on a module to improve the current code
until it reaches WS-FED protocol support & quality level to make a new
proper PR (or keep it a module if it?s should be that way).


@dbarentine offered the latest version of his code (target 2.5.5.Final)
The new repository is here : https://github.com/cloudtrust/keycloak-wsfed


We will start to work on making it run on the latest version of
keycloak then start to complete it.

Anyone who want to help us is welcome :-)

Best

Sebastien

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From braoru at gmail.com  Sun May 14 08:07:48 2017
From: braoru at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Pasche?=)
Date: Sun, 14 May 2017 14:07:48 +0200
Subject: [keycloak-dev] Trying to ADD WS-Fed support for both protocol
 and broker into keycloak
In-Reply-To: <DM5PR07MB2937889A20E96F562594571FDAE30@DM5PR07MB2937.namprd07.prod.outlook.com>
References: <CAPfD7PnnXg5m0hDH4PxxHHBLBKqaweX3fmKCzu1LAECYTPh-xA@mail.gmail.com>
	<DM5PR07MB2937889A20E96F562594571FDAE30@DM5PR07MB2937.namprd07.prod.outlook.com>
Message-ID: <CAPfD7Pkzy5n7Zu=UbiY9VhnNU9pkM20_OMr2kGB72XrO1SAWkA@mail.gmail.com>

Hello,

This is an excellent idea I'm trying to get one of our dev to help us
for a few month (as we will use this plugin internally). This will
certainly not complete the whole things but it will help :-).

I think we could try to merge everything into the module on the
cloudtrust repository. As stianst said in the PR, they don't know if
they want this support to be included natively within keycloak so, the
module approach is cleaner.

What do you think about it ?

Sebastien



2017-05-13 19:06 GMT+02:00 Nalyvayko, Peter <pnalyvayko at agi.com>:
> Hi Sebastien,
>
> Perhaps we can combine our efforts. I've done a fair amount of work to adopt the work originally developed by Dan Barentine and his team to support WS-Fed protocol in keycloak. The current version is based off of version 2.3.0. Among new features not present in the original submission is the support for SAML 1.1 tokens which was added to enable older clients.
>
> The wsfed related repository is here: https://github.com/brat000012001/keycloak/tree/wsfed-2.3.0.x
>
> Let me know how you and your team want to proceed.
>
> Cheers,
> Peter
> ________________________________________
> From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of S?bastien Pasche [braoru at gmail.com]
> Sent: Saturday, May 13, 2017 6:22 AM
> To: keycloak-dev at lists.jboss.org
> Subject: [keycloak-dev] Trying to ADD WS-Fed support for both protocol and      broker into keycloak
>
> Hello,
>
>
> We are a small team starting to develop/assembly an open source CASB solution.
>
>
> We just wanted to say we will start to work on the code developed by
> dbarentine  On PR ?KEYCLOAK-2000 WS-Fed support for both protocol and
> broker?. https://github.com/keycloak/keycloak/pull/1766
>
>
> The idea is to first work on a module to improve the current code
> until it reaches WS-FED protocol support & quality level to make a new
> proper PR (or keep it a module if it?s should be that way).
>
>
> @dbarentine offered the latest version of his code (target 2.5.5.Final)
> The new repository is here : https://github.com/cloudtrust/keycloak-wsfed
>
>
> We will start to work on making it run on the latest version of
> keycloak then start to complete it.
>
> Anyone who want to help us is welcome :-)
>
> Best
>
> Sebastien
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Mon May 15 03:47:12 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 May 2017 09:47:12 +0200
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
Message-ID: <35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>

Hi,

we are adding some sticky session support, so this routeId is used by 
the loadbalancer to track to which cluster backend node it should 
forward the request. This is pretty much similar to what Wildfly is 
doing to track the session stickiness of servlet httpSessions. However 
I've added the SPI, so it would be possible to avoid adding the route to 
the cookie or use different strategy to add the route to the request. 
But without sticky sessions, you might have worse performance in cluster 
environment.

Btv. do you want to avoid sticky sessions at all or your loadbalancer 
has some other way to track them rather than through browser cookie? 
Which loadbalancer are you using?

Marek


On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> Is there a technical reason for including the routeid explicitely in the Cookie?
> Normally, I would be reluctant to give out information about the setup behind
> the load balancer, like how many nodes the cluster consists of.
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda
> Sent: Donnerstag, 11. Mai 2017 22:33
> To: keycloak-dev at lists.jboss.org
> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>
> I've finally sent the PR https://github.com/keycloak/keycloak/pull/4132
> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>
> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
> Just some highlights:
>
> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>
> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>
> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>
> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>
> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>
> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>
> [1] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
> [3] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Mon May 15 04:04:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 15 May 2017 10:04:39 +0200
Subject: [keycloak-dev] Clearing AuthZ Cache
In-Reply-To: <CAJrcDBevQF9j-vo2NU2vE=1tFn9twwR=JaEii9FJxY=rMFfZFA@mail.gmail.com>
References: <CAJrcDBevQF9j-vo2NU2vE=1tFn9twwR=JaEii9FJxY=rMFfZFA@mail.gmail.com>
Message-ID: <CAJgngAcXiJC9ViXQa2AdUFYogQss-0SGoN9pMoJWGzo4AF6ecg@mail.gmail.com>

-1 Just make the clear realm cache button also clear authz services

On 12 May 2017 5:19 pm, "Pedro Igor Silva" <psilva at redhat.com> wrote:

> May I add a "Authorization Cache" to realm's "Cache" tab ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Schuster at bosch-si.com  Mon May 15 04:20:47 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Mon, 15 May 2017 08:20:47 +0000
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
Message-ID: <e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>

Hi Marek,

I guess using sticky sessions is fine. I was only referring to the fact that the cookie content looked like it contains
some route identifier that is visible to the client. This way a client could find out how many nodes are behind the
load balancer or it could target individual nodes. I think this would be a security issue and should be avoided by
using just an opaque session id in the cookie. The load balancer will keep track of which node generated the
session id and will route further requests accordingly.

Best regards,
Sebastian


Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Montag, 15. Mai 2017 09:47
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR

Hi,

we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request. 
But without sticky sessions, you might have worse performance in cluster environment.

Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie? 
Which loadbalancer are you using?

Marek


On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> Is there a technical reason for including the routeid explicitely in the Cookie?
> Normally, I would be reluctant to give out information about the setup 
> behind the load balancer, like how many nodes the cluster consists of.
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 
> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 
> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 
> B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek 
> Posolda
> Sent: Donnerstag, 11. Mai 2017 22:33
> To: keycloak-dev at lists.jboss.org
> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>
> I've finally sent the PR 
> https://github.com/keycloak/keycloak/pull/4132
> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>
> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
> Just some highlights:
>
> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>
> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>
> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>
> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>
> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>
> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>
> [1] 
> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
> [2] 
> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
> [3] 
> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From mposolda at redhat.com  Mon May 15 06:52:26 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 May 2017 12:52:26 +0200
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <c64151ab-9194-42ba-a215-cd6b60f993a9@redhat.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<c64151ab-9194-42ba-a215-cd6b60f993a9@redhat.com>
Message-ID: <a9ba8c79-e87a-f542-26ea-844a59a59aa3@redhat.com>

So the PR is merged.

The next step is to update docs, migrations, create the blogpost and 
describe that people may need to update their authenticators etc. We 
expect the feedback in next days/weeks, so if you have questions or if 
you are seeing that something is broken, feel free to blame us :) 
Hopefully it won't be so bad, and you will rather see the improvements 
instead of regressions.

Marek

On 12/05/17 01:15, Bill Burke wrote:
> Nice work...Cut/paste this to docs
>
>
> On 5/11/17 4:33 PM, Marek Posolda wrote:
>> I've finally sent the PR https://github.com/keycloak/keycloak/pull/4132
>> with the work for $subject. This includes the work by Hynek and me on
>> Authentication sessions and action tokens. We finally managed to sort
>> various kinks and have all tests passing.
>>
>> Some things and concepts were already discussed in some previous threads
>> [1], [2], [3] and during presentations. So I won't repeat everything.
>> Just some highlights:
>>
>> - authenticationSession replaces the old ClientSessionModel. There is
>> separate AuthenticationSessionProvider and separate infinispan cache
>> "authenticationSessions" . This cache typicaly won't be replicated over
>> all the datacenters, but instead it will rely on browser sticky
>> sessions, hence browser will be redirected by loadbalancer to correct
>> node in correct datacenter. So typicaly there won't be cross-dc
>> communication needed during authentication.
>>
>> - I've added some support for sticky sessions already. In cluster
>> environment, the authentication session cookie is created in the format
>> like "sessionId.routeId" . For example
>> "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format
>> like JSESSIONID cookie used as a cookie in classic java web
>> applications. One side-effect of this PR is, that it also covers the
>> support for running clustering tests on embedded undertow and from IDE.
>>
>> - Support for browser back/forward/refresh buttons was improved since my
>> presentation last month. There are no browser redirects after the form
>> submit, but instead there is a change of browser history through the
>> javascript history.replaceState function. This pretty much removes all
>> the POST requests from the browser history and helps with having good
>> experience regarding browser buttons. In case that you have old browser
>> not supporting this, the behaviour is same like before. Hence default
>> browser "Page expired" page after clicking back from POST request (same
>> behaviour like latest master). There are no additional redirects.
>>
>> - For action tokens, Hynek will likely add more. For quick summary, I
>> can just mention that action token is JWT signed by realm secret key.
>> You can generate it in your authenticator or requiredActionProvider and
>> send it somehow to user. Typically through email. Once user opens the
>> actionToken URL from the email, it is processed on LoginActionsService
>> endpoint, which provides most of the common basic functionality and
>> verifications. LoginActionsService then finds the correct implementation
>> of ActionTokenHandler, which is separate SPI. This allows to specify the
>> details how can be actionToken handled, whether it's single use or not
>> etc. There is support for the scenario if user opened link in the same
>> browser when he started authenticationSession or in different browser etc.
>>
>> - Regarding PR, I've tried to squash the commits a bit. However PR still
>> consists of more commits to track at least what was done by me and what
>> by Hynek. Do you think it is the issue to have more commits in the PR?
>>
>> - This is hopefully the bigest task for the cross-dc support. My hope is
>> that PR can be reviewed and merged soon as the work is more and more
>> unsynced with the latest master and rebasing is a bit of pain. But I
>> understand that this will require time. There is change in 324 files :)
>> There are still a lot things to cover for cross-dc, but I think those
>> can be done in smaller pieces and commit more often.
>>
>> [1] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>> [2] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>> [3] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Mon May 15 07:02:22 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 May 2017 13:02:22 +0200
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
	<e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
Message-ID: <ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>

On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> I guess using sticky sessions is fine. I was only referring to the fact that the cookie content looked like it contains
> some route identifier that is visible to the client. This way a client could find out how many nodes are behind the
> load balancer or it could target individual nodes. I think this would be a security issue and should be avoided by
> using just an opaque session id in the cookie. The load balancer will keep track of which node generated the
> session id and will route further requests accordingly.
Yes, it works this way. However AFAIK using the cookie to route requests 
is standard way, which most loadbalancers are using. Exposing some 
informations about underlying routes, and possibly count of cluster 
nodes, might be a price to pay.

It is possible to avoid it by:
- Avoid sticky sessions.
- I suppose some loadbalancers might have tools to somehow hide this 
(eg. encrypt the cookie), or track the mapping of the session-to-routes 
in some internal memory.

I must admin that I am not so experienced in what admins are typically 
doing. I am curious about your setup. Do you want to avoid sticky 
sessions at all or your loadbalancer has some other way to track them 
rather than through browser cookie? Which loadbalancer are you using?

Marek
>
> Best regards,
> Sebastian
>
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 15. Mai 2017 09:47
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> Hi,
>
> we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request.
> But without sticky sessions, you might have worse performance in cluster environment.
>
> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie?
> Which loadbalancer are you using?
>
> Marek
>
>
> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> Is there a technical reason for including the routeid explicitely in the Cookie?
>> Normally, I would be reluctant to give out information about the setup
>> behind the load balancer, like how many nodes the cluster consists of.
>>
>> Best regards,
>> Sebastian
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>    Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>> B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org
>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
>> Posolda
>> Sent: Donnerstag, 11. Mai 2017 22:33
>> To: keycloak-dev at lists.jboss.org
>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>
>> I've finally sent the PR
>> https://github.com/keycloak/keycloak/pull/4132
>> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>>
>> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
>> Just some highlights:
>>
>> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>>
>> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>>
>> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>>
>> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
>> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>>
>> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>>
>> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>>
>> [1]
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>> [2]
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>> [3]
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From psilva at redhat.com  Mon May 15 07:13:33 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 15 May 2017 08:13:33 -0300
Subject: [keycloak-dev] Clearing AuthZ Cache
In-Reply-To: <CAJgngAcXiJC9ViXQa2AdUFYogQss-0SGoN9pMoJWGzo4AF6ecg@mail.gmail.com>
References: <CAJrcDBevQF9j-vo2NU2vE=1tFn9twwR=JaEii9FJxY=rMFfZFA@mail.gmail.com>
	<CAJgngAcXiJC9ViXQa2AdUFYogQss-0SGoN9pMoJWGzo4AF6ecg@mail.gmail.com>
Message-ID: <CAJrcDBdmBtN=Ar9jweEBxFBoGOsgrtkYO+H358sW5MwKdr+1Vg@mail.gmail.com>

Yes, that is what you suggested in our last meeting. After talking with
Marek, I have confirmed that I can change the event to also send messages
to the sender. Without this change, is only be possible to notify other
nodes.

On Mon, May 15, 2017 at 5:04 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> -1 Just make the clear realm cache button also clear authz services
>
> On 12 May 2017 5:19 pm, "Pedro Igor Silva" <psilva at redhat.com> wrote:
>
>> May I add a "Authorization Cache" to realm's "Cache" tab ?
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From Sebastian.Schuster at bosch-si.com  Mon May 15 08:14:37 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Mon, 15 May 2017 12:14:37 +0000
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
	<e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
	<ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>
Message-ID: <3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>

Hi Marek,

There are a lot of different ways how load balancers can create stickiness. They can use source or destination IP, they can use cookie insertion or cookie rewriting adding a route identifier to the response (this is similar to what you did), or they can also maintain sticky tables holding state like opaque session ids to map future requests to the right node.

There is some documentation how to do this in a simple way for nginx (https://www.nginx.com/products/session-persistence/), while (https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-stick%20store-request) shows you can store arbitrary things to realize stickiness in HAProxy if you want to (e.g to act differently for requests coming from a proxy).

Anyways, I guess my point is that you can create session stickiness by just configuring your load balancer to use whatever mechanism you prefer. Ideally, Keycloak should not care and should not require a specific mechanism to be used. If I want a higher level of protection for my cluster more and not give out any information, I should be able to do this (at the cost of more work for the load balancers).

Of course, I am assuming Keycloak still works fine without session stickiness being configured correctly (just with reduced efficiency).

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Montag, 15. Mai 2017 13:02
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR

On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> I guess using sticky sessions is fine. I was only referring to the 
> fact that the cookie content looked like it contains some route 
> identifier that is visible to the client. This way a client could find 
> out how many nodes are behind the load balancer or it could target 
> individual nodes. I think this would be a security issue and should be avoided by using just an opaque session id in the cookie. The load balancer will keep track of which node generated the session id and will route further requests accordingly.
Yes, it works this way. However AFAIK using the cookie to route requests is standard way, which most loadbalancers are using. Exposing some informations about underlying routes, and possibly count of cluster nodes, might be a price to pay.

It is possible to avoid it by:
- Avoid sticky sessions.
- I suppose some loadbalancers might have tools to somehow hide this (eg. encrypt the cookie), or track the mapping of the session-to-routes in some internal memory.

I must admin that I am not so experienced in what admins are typically doing. I am curious about your setup. Do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie? Which loadbalancer are you using?

Marek
>
> Best regards,
> Sebastian
>
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 
> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 
> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 
> B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 15. Mai 2017 09:47
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; 
> keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> Hi,
>
> we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request.
> But without sticky sessions, you might have worse performance in cluster environment.
>
> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie?
> Which loadbalancer are you using?
>
> Marek
>
>
> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> Is there a technical reason for including the routeid explicitely in the Cookie?
>> Normally, I would be reluctant to give out information about the 
>> setup behind the load balancer, like how many nodes the cluster consists of.
>>
>> Best regards,
>> Sebastian
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>    Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 
>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 
>> B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org
>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek 
>> Posolda
>> Sent: Donnerstag, 11. Mai 2017 22:33
>> To: keycloak-dev at lists.jboss.org
>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>
>> I've finally sent the PR
>> https://github.com/keycloak/keycloak/pull/4132
>> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>>
>> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
>> Just some highlights:
>>
>> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>>
>> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>>
>> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>>
>> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
>> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>>
>> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>>
>> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>>
>> [1]
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>> [2]
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>> [3]
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



From bburke at redhat.com  Mon May 15 09:49:28 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 May 2017 09:49:28 -0400
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
	<e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
	<ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>
	<3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>
Message-ID: <82a874e1-bd7e-8a60-4e17-7e7da9483165@redhat.com>

TLDR; For performance, sticky sessions are really important.

Keycloak is not stateless.  We use a distributed cache for user 
sessions.  This means that the user session is not stored on every node 
in the cluster and is "queried" if the node doesn't have it. Also, our 
db caches are all invalidation based.  So, for a specific user it is 
highly likely that the node will not have that user loaded and have to 
hit the database.  This problem is exacerbated since OIDC has 
out-of-band (non-browser) requests. code-to-token and refresh token are 
all out of band.



On 5/15/17 8:14 AM, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> There are a lot of different ways how load balancers can create stickiness. They can use source or destination IP, they can use cookie insertion or cookie rewriting adding a route identifier to the response (this is similar to what you did), or they can also maintain sticky tables holding state like opaque session ids to map future requests to the right node.
>
> There is some documentation how to do this in a simple way for nginx (https://www.nginx.com/products/session-persistence/), while (https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-stick%20store-request) shows you can store arbitrary things to realize stickiness in HAProxy if you want to (e.g to act differently for requests coming from a proxy).
>
> Anyways, I guess my point is that you can create session stickiness by just configuring your load balancer to use whatever mechanism you prefer. Ideally, Keycloak should not care and should not require a specific mechanism to be used. If I want a higher level of protection for my cluster more and not give out any information, I should be able to do this (at the cost of more work for the load balancers).
>
> Of course, I am assuming Keycloak still works fine without session stickiness being configured correctly (just with reduced efficiency).
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 15. Mai 2017 13:02
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> I guess using sticky sessions is fine. I was only referring to the
>> fact that the cookie content looked like it contains some route
>> identifier that is visible to the client. This way a client could find
>> out how many nodes are behind the load balancer or it could target
>> individual nodes. I think this would be a security issue and should be avoided by using just an opaque session id in the cookie. The load balancer will keep track of which node generated the session id and will route further requests accordingly.
> Yes, it works this way. However AFAIK using the cookie to route requests is standard way, which most loadbalancers are using. Exposing some informations about underlying routes, and possibly count of cluster nodes, might be a price to pay.
>
> It is possible to avoid it by:
> - Avoid sticky sessions.
> - I suppose some loadbalancers might have tools to somehow hide this (eg. encrypt the cookie), or track the mapping of the session-to-routes in some internal memory.
>
> I must admin that I am not so experienced in what admins are typically doing. I am curious about your setup. Do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie? Which loadbalancer are you using?
>
> Marek
>> Best regards,
>> Sebastian
>>
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>    Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>> B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: Marek Posolda [mailto:mposolda at redhat.com]
>> Sent: Montag, 15. Mai 2017 09:47
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>>
>> Hi,
>>
>> we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request.
>> But without sticky sessions, you might have worse performance in cluster environment.
>>
>> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie?
>> Which loadbalancer are you using?
>>
>> Marek
>>
>>
>> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>>> Hi Marek,
>>>
>>> Is there a technical reason for including the routeid explicitely in the Cookie?
>>> Normally, I would be reluctant to give out information about the
>>> setup behind the load balancer, like how many nodes the cluster consists of.
>>>
>>> Best regards,
>>> Sebastian
>>>
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>     Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>>> B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org
>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
>>> Posolda
>>> Sent: Donnerstag, 11. Mai 2017 22:33
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>>
>>> I've finally sent the PR
>>> https://github.com/keycloak/keycloak/pull/4132
>>> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>>>
>>> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
>>> Just some highlights:
>>>
>>> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>>>
>>> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>>>
>>> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>>>
>>> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
>>> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>>>
>>> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>>>
>>> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>>>
>>> [1]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>>> [2]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>>> [3]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From Sebastian.Schuster at bosch-si.com  Mon May 15 09:56:31 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Mon, 15 May 2017 13:56:31 +0000
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <82a874e1-bd7e-8a60-4e17-7e7da9483165@redhat.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
	<e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
	<ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>
	<3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>
	<82a874e1-bd7e-8a60-4e17-7e7da9483165@redhat.com>
Message-ID: <9fd5355dfcb543e1a4e4e8a35089ea20@FE-MBX1028.de.bosch.com>

Hi Bill,

I totally understand it is necessary for optimal performance. I am just arguing this is possible by just configuring your load balancers correctly
without Keycloak doing anything about it (especially leaking the number of nodes in the cluster or introducing the ability to target individual nodes
from the outside).

Best regards,
Sebastian

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: Montag, 15. Mai 2017 15:49
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR

TLDR; For performance, sticky sessions are really important.

Keycloak is not stateless.  We use a distributed cache for user sessions.  This means that the user session is not stored on every node in the cluster and is "queried" if the node doesn't have it. Also, our db caches are all invalidation based.  So, for a specific user it is highly likely that the node will not have that user loaded and have to hit the database.  This problem is exacerbated since OIDC has out-of-band (non-browser) requests. code-to-token and refresh token are all out of band.



On 5/15/17 8:14 AM, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> There are a lot of different ways how load balancers can create stickiness. They can use source or destination IP, they can use cookie insertion or cookie rewriting adding a route identifier to the response (this is similar to what you did), or they can also maintain sticky tables holding state like opaque session ids to map future requests to the right node.
>
> There is some documentation how to do this in a simple way for nginx (https://www.nginx.com/products/session-persistence/), while (https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-stick%20store-request) shows you can store arbitrary things to realize stickiness in HAProxy if you want to (e.g to act differently for requests coming from a proxy).
>
> Anyways, I guess my point is that you can create session stickiness by just configuring your load balancer to use whatever mechanism you prefer. Ideally, Keycloak should not care and should not require a specific mechanism to be used. If I want a higher level of protection for my cluster more and not give out any information, I should be able to do this (at the cost of more work for the load balancers).
>
> Of course, I am assuming Keycloak still works fine without session stickiness being configured correctly (just with reduced efficiency).
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 
> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49 
> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 
> B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 15. Mai 2017 13:02
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; 
> keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> I guess using sticky sessions is fine. I was only referring to the 
>> fact that the cookie content looked like it contains some route 
>> identifier that is visible to the client. This way a client could 
>> find out how many nodes are behind the load balancer or it could 
>> target individual nodes. I think this would be a security issue and should be avoided by using just an opaque session id in the cookie. The load balancer will keep track of which node generated the session id and will route further requests accordingly.
> Yes, it works this way. However AFAIK using the cookie to route requests is standard way, which most loadbalancers are using. Exposing some informations about underlying routes, and possibly count of cluster nodes, might be a price to pay.
>
> It is possible to avoid it by:
> - Avoid sticky sessions.
> - I suppose some loadbalancers might have tools to somehow hide this (eg. encrypt the cookie), or track the mapping of the session-to-routes in some internal memory.
>
> I must admin that I am not so experienced in what admins are typically doing. I am curious about your setup. Do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie? Which loadbalancer are you using?
>
> Marek
>> Best regards,
>> Sebastian
>>
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>    Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 
>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 
>> B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: Marek Posolda [mailto:mposolda at redhat.com]
>> Sent: Montag, 15. Mai 2017 09:47
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens 
>> PR
>>
>> Hi,
>>
>> we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request.
>> But without sticky sessions, you might have worse performance in cluster environment.
>>
>> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie?
>> Which loadbalancer are you using?
>>
>> Marek
>>
>>
>> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>>> Hi Marek,
>>>
>>> Is there a technical reason for including the routeid explicitely in the Cookie?
>>> Normally, I would be reluctant to give out information about the 
>>> setup behind the load balancer, like how many nodes the cluster consists of.
>>>
>>> Best regards,
>>> Sebastian
>>>
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>     Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 
>>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 
>>> 148411 B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org
>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek 
>>> Posolda
>>> Sent: Donnerstag, 11. Mai 2017 22:33
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>>
>>> I've finally sent the PR
>>> https://github.com/keycloak/keycloak/pull/4132
>>> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>>>
>>> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
>>> Just some highlights:
>>>
>>> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>>>
>>> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>>>
>>> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>>>
>>> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
>>> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>>>
>>> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>>>
>>> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>>>
>>> [1]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>>> [2]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>>> [3]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Mon May 15 09:58:33 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 May 2017 15:58:33 +0200
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
	<e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
	<ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>
	<3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>
Message-ID: <fcd5a0e2-6aaa-1642-0bc7-1901bb9768ac@redhat.com>

On 15/05/17 14:14, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> There are a lot of different ways how load balancers can create stickiness. They can use source or destination IP, they can use cookie insertion or cookie rewriting adding a route identifier to the response (this is similar to what you did), or they can also maintain sticky tables holding state like opaque session ids to map future requests to the right node.
Yes, that's what I though.
>
> There is some documentation how to do this in a simple way for nginx (https://www.nginx.com/products/session-persistence/), while (https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-stick%20store-request) shows you can store arbitrary things to realize stickiness in HAProxy if you want to (e.g to act differently for requests coming from a proxy).
Thanks! Will need to take a look at those docs.
>
> Anyways, I guess my point is that you can create session stickiness by just configuring your load balancer to use whatever mechanism you prefer. Ideally, Keycloak should not care and should not require a specific mechanism to be used. If I want a higher level of protection for my cluster more and not give out any information, I should be able to do this (at the cost of more work for the load balancers).
>
> Of course, I am assuming Keycloak still works fine without session stickiness being configured correctly (just with reduced efficiency).
Yes, exactly. I've added the SPI exactly for this purpose, so you would 
be able to eventually disable the generation of the routeId. I've added 
the JIRA https://issues.jboss.org/browse/KEYCLOAK-4906 . This will have 
some performance penalty though. Especially in cross-datacenter 
environment the performance penalty will be quite big without sticky 
sessions and you may even need to re-configure the infinispan caches to 
replicate more informations between data-centers.

Marek
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Montag, 15. Mai 2017 13:02
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> I guess using sticky sessions is fine. I was only referring to the
>> fact that the cookie content looked like it contains some route
>> identifier that is visible to the client. This way a client could find
>> out how many nodes are behind the load balancer or it could target
>> individual nodes. I think this would be a security issue and should be avoided by using just an opaque session id in the cookie. The load balancer will keep track of which node generated the session id and will route further requests accordingly.
> Yes, it works this way. However AFAIK using the cookie to route requests is standard way, which most loadbalancers are using. Exposing some informations about underlying routes, and possibly count of cluster nodes, might be a price to pay.
>
> It is possible to avoid it by:
> - Avoid sticky sessions.
> - I suppose some loadbalancers might have tools to somehow hide this (eg. encrypt the cookie), or track the mapping of the session-to-routes in some internal memory.
>
> I must admin that I am not so experienced in what admins are typically doing. I am curious about your setup. Do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie? Which loadbalancer are you using?
>
> Marek
>> Best regards,
>> Sebastian
>>
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>    Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>> B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: Marek Posolda [mailto:mposolda at redhat.com]
>> Sent: Montag, 15. Mai 2017 09:47
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>>
>> Hi,
>>
>> we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request.
>> But without sticky sessions, you might have worse performance in cluster environment.
>>
>> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie?
>> Which loadbalancer are you using?
>>
>> Marek
>>
>>
>> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>>> Hi Marek,
>>>
>>> Is there a technical reason for including the routeid explicitely in the Cookie?
>>> Normally, I would be reluctant to give out information about the
>>> setup behind the load balancer, like how many nodes the cluster consists of.
>>>
>>> Best regards,
>>> Sebastian
>>>
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>     Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>>> B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org
>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
>>> Posolda
>>> Sent: Donnerstag, 11. Mai 2017 22:33
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>>
>>> I've finally sent the PR
>>> https://github.com/keycloak/keycloak/pull/4132
>>> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>>>
>>> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
>>> Just some highlights:
>>>
>>> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>>>
>>> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>>>
>>> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>>>
>>> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
>>> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>>>
>>> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>>>
>>> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>>>
>>> [1]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>>> [2]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>>> [3]
>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bburke at redhat.com  Mon May 15 10:06:56 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 May 2017 10:06:56 -0400
Subject: [keycloak-dev] Authentication sessions & Action tokens PR
In-Reply-To: <9fd5355dfcb543e1a4e4e8a35089ea20@FE-MBX1028.de.bosch.com>
References: <e297944d-b34a-021f-e2d1-1f3bc2113fcc@redhat.com>
	<9db7b9aeb93b411e84537bc6da4edf67@FE-MBX1028.de.bosch.com>
	<35f99109-a1f1-c390-fbcd-20843a753b39@redhat.com>
	<e5180e5850f14b50b576ddf0c4545d0c@FE-MBX1028.de.bosch.com>
	<ffcaddf7-59db-435c-367a-ed874fcc1d2d@redhat.com>
	<3829fdace88244a1a44cd8da3869acde@FE-MBX1028.de.bosch.com>
	<82a874e1-bd7e-8a60-4e17-7e7da9483165@redhat.com>
	<9fd5355dfcb543e1a4e4e8a35089ea20@FE-MBX1028.de.bosch.com>
Message-ID: <47c02f94-c292-d8b9-a2bf-dcb51f700815@redhat.com>

HA Proxy rocks, BTW.

On 5/15/17 9:56 AM, Schuster Sebastian (INST/ESY1) wrote:
> Hi Bill,
>
> I totally understand it is necessary for optimal performance. I am just arguing this is possible by just configuring your load balancers correctly
> without Keycloak doing anything about it (especially leaking the number of nodes in the cluster or introducing the ability to target individual nodes
> from the outside).
>
> Best regards,
> Sebastian
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
> Sent: Montag, 15. Mai 2017 15:49
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>
> TLDR; For performance, sticky sessions are really important.
>
> Keycloak is not stateless.  We use a distributed cache for user sessions.  This means that the user session is not stored on every node in the cluster and is "queried" if the node doesn't have it. Also, our db caches are all invalidation based.  So, for a specific user it is highly likely that the node will not have that user loaded and have to hit the database.  This problem is exacerbated since OIDC has out-of-band (non-browser) requests. code-to-token and refresh token are all out of band.
>
>
>
> On 5/15/17 8:14 AM, Schuster Sebastian (INST/ESY1) wrote:
>> Hi Marek,
>>
>> There are a lot of different ways how load balancers can create stickiness. They can use source or destination IP, they can use cookie insertion or cookie rewriting adding a route identifier to the response (this is similar to what you did), or they can also maintain sticky tables holding state like opaque session ids to map future requests to the right node.
>>
>> There is some documentation how to do this in a simple way for nginx (https://www.nginx.com/products/session-persistence/), while (https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-stick%20store-request) shows you can store arbitrary things to realize stickiness in HAProxy if you want to (e.g to act differently for requests coming from a proxy).
>>
>> Anyways, I guess my point is that you can create session stickiness by just configuring your load balancer to use whatever mechanism you prefer. Ideally, Keycloak should not care and should not require a specific mechanism to be used. If I want a higher level of protection for my cluster more and not give out any information, I should be able to do this (at the cost of more work for the load balancers).
>>
>> Of course, I am assuming Keycloak still works fine without session stickiness being configured correctly (just with reduced efficiency).
>>
>> Best regards,
>> Sebastian
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>    Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>> B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>> From: Marek Posolda [mailto:mposolda at redhat.com]
>> Sent: Montag, 15. Mai 2017 13:02
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens PR
>>
>> On 15/05/17 10:20, Schuster Sebastian (INST/ESY1) wrote:
>>> Hi Marek,
>>>
>>> I guess using sticky sessions is fine. I was only referring to the
>>> fact that the cookie content looked like it contains some route
>>> identifier that is visible to the client. This way a client could
>>> find out how many nodes are behind the load balancer or it could
>>> target individual nodes. I think this would be a security issue and should be avoided by using just an opaque session id in the cookie. The load balancer will keep track of which node generated the session id and will route further requests accordingly.
>> Yes, it works this way. However AFAIK using the cookie to route requests is standard way, which most loadbalancers are using. Exposing some informations about underlying routes, and possibly count of cluster nodes, might be a price to pay.
>>
>> It is possible to avoid it by:
>> - Avoid sticky sessions.
>> - I suppose some loadbalancers might have tools to somehow hide this (eg. encrypt the cookie), or track the mapping of the session-to-routes in some internal memory.
>>
>> I must admin that I am not so experienced in what admins are typically doing. I am curious about your setup. Do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie? Which loadbalancer are you using?
>>
>> Marek
>>> Best regards,
>>> Sebastian
>>>
>>>
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>     Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>>> B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Marek Posolda [mailto:mposolda at redhat.com]
>>> Sent: Montag, 15. Mai 2017 09:47
>>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>>> keycloak-dev at lists.jboss.org
>>> Subject: Re: [keycloak-dev] Authentication sessions & Action tokens
>>> PR
>>>
>>> Hi,
>>>
>>> we are adding some sticky session support, so this routeId is used by the loadbalancer to track to which cluster backend node it should forward the request. This is pretty much similar to what Wildfly is doing to track the session stickiness of servlet httpSessions. However I've added the SPI, so it would be possible to avoid adding the route to the cookie or use different strategy to add the route to the request.
>>> But without sticky sessions, you might have worse performance in cluster environment.
>>>
>>> Btv. do you want to avoid sticky sessions at all or your loadbalancer has some other way to track them rather than through browser cookie?
>>> Which loadbalancer are you using?
>>>
>>> Marek
>>>
>>>
>>> On 12/05/17 08:30, Schuster Sebastian (INST/ESY1) wrote:
>>>> Hi Marek,
>>>>
>>>> Is there a technical reason for including the routeid explicitely in the Cookie?
>>>> Normally, I would be reluctant to give out information about the
>>>> setup behind the load balancer, like how many nodes the cluster consists of.
>>>>
>>>> Best regards,
>>>> Sebastian
>>>>
>>>> Mit freundlichen Gr??en / Best regards
>>>>
>>>>      Sebastian Schuster
>>>>
>>>> Engineering and Support (INST/ESY1)
>>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>>>
>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>>>> 148411 B
>>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: keycloak-dev-bounces at lists.jboss.org
>>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
>>>> Posolda
>>>> Sent: Donnerstag, 11. Mai 2017 22:33
>>>> To: keycloak-dev at lists.jboss.org
>>>> Subject: [keycloak-dev] Authentication sessions & Action tokens PR
>>>>
>>>> I've finally sent the PR
>>>> https://github.com/keycloak/keycloak/pull/4132
>>>> with the work for $subject. This includes the work by Hynek and me on Authentication sessions and action tokens. We finally managed to sort various kinks and have all tests passing.
>>>>
>>>> Some things and concepts were already discussed in some previous threads [1], [2], [3] and during presentations. So I won't repeat everything.
>>>> Just some highlights:
>>>>
>>>> - authenticationSession replaces the old ClientSessionModel. There is separate AuthenticationSessionProvider and separate infinispan cache "authenticationSessions" . This cache typicaly won't be replicated over all the datacenters, but instead it will rely on browser sticky sessions, hence browser will be redirected by loadbalancer to correct node in correct datacenter. So typicaly there won't be cross-dc communication needed during authentication.
>>>>
>>>> - I've added some support for sticky sessions already. In cluster environment, the authentication session cookie is created in the format like "sessionId.routeId" . For example "aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format like JSESSIONID cookie used as a cookie in classic java web applications. One side-effect of this PR is, that it also covers the support for running clustering tests on embedded undertow and from IDE.
>>>>
>>>> - Support for browser back/forward/refresh buttons was improved since my presentation last month. There are no browser redirects after the form submit, but instead there is a change of browser history through the javascript history.replaceState function. This pretty much removes all the POST requests from the browser history and helps with having good experience regarding browser buttons. In case that you have old browser not supporting this, the behaviour is same like before. Hence default browser "Page expired" page after clicking back from POST request (same behaviour like latest master). There are no additional redirects.
>>>>
>>>> - For action tokens, Hynek will likely add more. For quick summary, I can just mention that action token is JWT signed by realm secret key.
>>>> You can generate it in your authenticator or requiredActionProvider and send it somehow to user. Typically through email. Once user opens the actionToken URL from the email, it is processed on LoginActionsService endpoint, which provides most of the common basic functionality and verifications. LoginActionsService then finds the correct implementation of ActionTokenHandler, which is separate SPI. This allows to specify the details how can be actionToken handled, whether it's single use or not etc. There is support for the scenario if user opened link in the same browser when he started authenticationSession or in different browser etc.
>>>>
>>>> - Regarding PR, I've tried to squash the commits a bit. However PR still consists of more commits to track at least what was done by me and what by Hynek. Do you think it is the issue to have more commits in the PR?
>>>>
>>>> - This is hopefully the bigest task for the cross-dc support. My hope is that PR can be reviewed and merged soon as the work is more and more unsynced with the latest master and rebasing is a bit of pain. But I understand that this will require time. There is change in 324 files :) There are still a lot things to cover for cross-dc, but I think those can be done in smaller pieces and commit more often.
>>>>
>>>> [1]
>>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
>>>> [2]
>>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
>>>> [3]
>>>> http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
>>>>
>>>> Marek
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Mon May 15 12:24:59 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 May 2017 18:24:59 +0200
Subject: [keycloak-dev] Slight refactoring of InfinispanUserSessionProvider
Message-ID: <fd61a0fd-0dd6-b4af-cd9f-8f7992289414@redhat.com>

In today's call with Stian and Hynek, we discussed the possible 
refactoring of InfinispanUserSessionProvider to be reliable in 
cluster/cross-dc environment.

Current implementation has tightly couple between the model 
(UserSessionAdapter) and underlying infinispan entity. For example when 
you call "userSessionModel.setLastSessionRefresh(123)" it directly 
delegates this call to infinispan entity and calls 
"entity.setLastSessionRefresh(123)" .

Some issues with this approach:

1) Possibility of lost updates in cluster - It can happen that there are 
more concurrent requests updating same userSession. There is a fix by 
Bill [1], which adds the thread-safety to UserSessionEntity and fixes 
the issue in local environment. However in cluster with more nodes, it 
can still happen that there is "lost update". I've created the JIRA [2] 
for this with details. In shortcut, what can happen is, that there is 
request1 processed on node1 and request2 processed on node2 in parallel. 
Both requests read the sessionEntity and then both perform concurrent 
update and commits their transaction. Then the latter update wins and 
overwrites the first update as the state when it read the entity didn't 
yet contain the first update.

2) Rollback doesn't work correctly. Basically when we do this:

{code}
userSession.setLastSessionRefresh(123);
session.transaction().rollback();
{code}

the keycloak transaction should be rolled-back and session in infinispan 
cache shouldn't be updated to lastSessionRefresh 123. However in current 
implementation, rollback doesn't work and entity is always updated in 
local environment and may be updated in cluster too (in case that 
calling node is the owner of session entity). That's because we are not 
using infinispan transaction API and calling 
"entity.setLastSessionRefresh(123)" directly updates the entity instance 
referenced by infinispan storage.

3) Cross-dc support with good performance

Ideal is to fix all issues and ensure consistency, but have the 
same/similar performance at the same time and not introduce additional 
uneccessary locking.


Possible solution:

- Every change to UserSessionModel won't delegate directly to infinispan 
sessionEntity as it's now. Instead it will track the change through 
changelogs/events, which are saved locally in our infinispan transaction 
(eg. AddClientToSessionEvent, LastSessionRefreshUpdateEvent).

- During Keycloak transaction commit are changelogs applied to 
sessionEntity. It may use atomic operation "cache.replace(key, oldValue, 
newValue)" and the pattern like this:

{code}
boolean replaced = false;

while (!replaced) {
     SessionEntity oldSession = cache.get("123");
     // Will update session entity based on the changes tracked in 
infinispan transaction
     SessionEntity updatedSession = applyChanges(oldSession);
     replaced = cache.replace("123", oldSession, updatedSession);
}
{code}

- In cross-dc environment are changes sent to another datacenter. That 
will receive changes (eg. AddClientToSessionEvent) and apply changes 
locally in the datacenter and update the sessionEntity in the 
infinispan. It shouldn't be a problem that those events are sent between 
datacenters through the asynchronous channel. The changes may not be 
guaranteed in same order in every DC, but all of them will be triggered 
and there won't be lost updates. So the cache "sessions" won't be 
directly replicated through the cross-dc, but instead the changes will 
be sent between datacenters.

What do you think? Can you see some issues with this approach?

Thanks,
Marek

[1] https://issues.jboss.org/browse/KEYCLOAK-4821
[2] https://issues.jboss.org/browse/KEYCLOAK-4898


From Sebastian.Schuster at bosch-si.com  Tue May 16 03:38:02 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 16 May 2017 07:38:02 +0000
Subject: [keycloak-dev] Slight refactoring of
 InfinispanUserSessionProvider
In-Reply-To: <fd61a0fd-0dd6-b4af-cd9f-8f7992289414@redhat.com>
References: <fd61a0fd-0dd6-b4af-cd9f-8f7992289414@redhat.com>
Message-ID: <fee600fd8d0a4972ac3f2cbe21e00741@FE-MBX1028.de.bosch.com>

Hi Marek,

You mentioned in your proposed solution that " The changes may not be guaranteed in same order in every DC". Wouldn't that be a problem as it leads to inconsistent data in different data centers?

Best regards,
Sebastian

P.S.: If I recall correctly, Infinispan does not support a "serializable" isolation level preventing lost updates, so even if Keycloak used the transaction API, it would not help...

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda
Sent: Montag, 15. Mai 2017 18:25
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] Slight refactoring of InfinispanUserSessionProvider

In today's call with Stian and Hynek, we discussed the possible refactoring of InfinispanUserSessionProvider to be reliable in cluster/cross-dc environment.

Current implementation has tightly couple between the model
(UserSessionAdapter) and underlying infinispan entity. For example when you call "userSessionModel.setLastSessionRefresh(123)" it directly delegates this call to infinispan entity and calls "entity.setLastSessionRefresh(123)" .

Some issues with this approach:

1) Possibility of lost updates in cluster - It can happen that there are more concurrent requests updating same userSession. There is a fix by Bill [1], which adds the thread-safety to UserSessionEntity and fixes the issue in local environment. However in cluster with more nodes, it can still happen that there is "lost update". I've created the JIRA [2] for this with details. In shortcut, what can happen is, that there is
request1 processed on node1 and request2 processed on node2 in parallel. 
Both requests read the sessionEntity and then both perform concurrent update and commits their transaction. Then the latter update wins and overwrites the first update as the state when it read the entity didn't yet contain the first update.

2) Rollback doesn't work correctly. Basically when we do this:

{code}
userSession.setLastSessionRefresh(123);
session.transaction().rollback();
{code}

the keycloak transaction should be rolled-back and session in infinispan cache shouldn't be updated to lastSessionRefresh 123. However in current implementation, rollback doesn't work and entity is always updated in local environment and may be updated in cluster too (in case that calling node is the owner of session entity). That's because we are not using infinispan transaction API and calling "entity.setLastSessionRefresh(123)" directly updates the entity instance referenced by infinispan storage.

3) Cross-dc support with good performance

Ideal is to fix all issues and ensure consistency, but have the same/similar performance at the same time and not introduce additional uneccessary locking.


Possible solution:

- Every change to UserSessionModel won't delegate directly to infinispan sessionEntity as it's now. Instead it will track the change through changelogs/events, which are saved locally in our infinispan transaction (eg. AddClientToSessionEvent, LastSessionRefreshUpdateEvent).

- During Keycloak transaction commit are changelogs applied to sessionEntity. It may use atomic operation "cache.replace(key, oldValue, newValue)" and the pattern like this:

{code}
boolean replaced = false;

while (!replaced) {
     SessionEntity oldSession = cache.get("123");
     // Will update session entity based on the changes tracked in infinispan transaction
     SessionEntity updatedSession = applyChanges(oldSession);
     replaced = cache.replace("123", oldSession, updatedSession); } {code}

- In cross-dc environment are changes sent to another datacenter. That will receive changes (eg. AddClientToSessionEvent) and apply changes locally in the datacenter and update the sessionEntity in the infinispan. It shouldn't be a problem that those events are sent between datacenters through the asynchronous channel. The changes may not be guaranteed in same order in every DC, but all of them will be triggered and there won't be lost updates. So the cache "sessions" won't be directly replicated through the cross-dc, but instead the changes will be sent between datacenters.

What do you think? Can you see some issues with this approach?

Thanks,
Marek

[1] https://issues.jboss.org/browse/KEYCLOAK-4821
[2] https://issues.jboss.org/browse/KEYCLOAK-4898

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Tue May 16 04:19:51 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 May 2017 10:19:51 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
Message-ID: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>

I was thinking about possibilities how to solve the issue with sticky 
sessions in backchannel requests. It seems that we need to support the 
scenarios, when backchannel requests won't be able to share the sticky 
session cookie with the browser. However in many cases it may be 
possible that backchannel requests can participate in the "sticky 
session", which will have great advantage for performance. Some thoughts:

- OAuth code (the one used in code-to-token backchannel request) can be 
JWT signed by realm HMAC key. One of the claims in the code could be 
"route-id"

- Refresh tokens will also contain "route-id" claim

- Keycloak OIDC adapters will be able to read the "route-id" from the 
code and they will attach sticky session information to the single 
backchannel request. Hence the backchannel request will be able to 
participate in sticky session and will be properly routed by 
loadbalancer to the correct node. Same for requests using refresh token.

- It seems we will need some flexibility how is the "sticky session" 
added to the request to support various loadbalancers (cookie, 
path-parameters etc). Maybe we need some SPI on adapter side? Or just 
some kind of expressions/tokens, which will help to configure how 
exactly will cookie/path parameter look like?

- Keycloak.js adapter seems to be working already. Ajax requests are 
re-sending the browser cookies and they are available in backchannel 
endpoint on server-side. This is true even if AUTH_SESSION_ID cookie is 
httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not sure if 
this is different in other browsers/devices (cordova etc)?

- For SAML backchannel requests (backchannel logout), we can add the 
same to our own SAML adapters though.

- If people use 3rd party adapters, they won't have this. However we can 
also have support for some loadbalancers to route the requests directly 
based on the content of the route-id inside code (or refresh token). In 
many cases, customers will already have established loadbalancer in 
their deployments. However some others might be starting their 
deployment from the scratch and we can suggest them to use some of our 
preferred loadbalancers though.

I've checked that if wildfly+mod_cluster is used as loadbalancer, we 
have the flexibility to inject custom undertow handler, which will be 
able to look into JWT and add the route info to the HttpServerExchange, 
from where mod_cluster will read it. Maybe we can investigate this 
possibility in the other popular loadbalancers (nginx etc) ?

So in summary: Backchannel requests won't be able to participate in 
sticky session just if: 3rd party adapter is used AND customer can't use 
our preferred loadbalancer.

WDYT?

Marek


From mposolda at redhat.com  Tue May 16 04:40:39 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 May 2017 10:40:39 +0200
Subject: [keycloak-dev] Slight refactoring of
 InfinispanUserSessionProvider
In-Reply-To: <fee600fd8d0a4972ac3f2cbe21e00741@FE-MBX1028.de.bosch.com>
References: <fd61a0fd-0dd6-b4af-cd9f-8f7992289414@redhat.com>
	<fee600fd8d0a4972ac3f2cbe21e00741@FE-MBX1028.de.bosch.com>
Message-ID: <6df1aed4-8d5e-1faa-b61e-e0fc7e78a121@redhat.com>

On 16/05/17 09:38, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> You mentioned in your proposed solution that " The changes may not be guaranteed in same order in every DC". Wouldn't that be a problem as it leads to inconsistent data in different data centers?
I was thinking about that and ATM I can't see the scenario when it is a 
problem with respect to our business logic related to userSession model.

For example it can happen that there is request1 for add client 
"client1" in dc1. And at the same time request2 for add "client2" in 
dc2.  So it may happen that request1 will add "client1" to the 
userSession and send the message to dc2 for add "client1" . At the same 
time request2 will add "client2" to the userSession in dc2 and send the 
message to dc1 for add "client1" . After some time, both DCs will 
receive the message from the other DC and both will update their client 
list to be ["client1", "client2"] .

Important is, that there won't be lost update (which can easily happen 
now).

There are various corner cases (eg. DC will receive the message about 
update of userSession, which was already logged-out/removed in this DC 
etc), but all of those can be handled IMO.

One special thing is code-to-token request as it can happen very quickly 
after the userSession is created. And it can be processed on different 
DC then the one when userSession was created. So my current thinking is 
to not lookup userSession in code-to-token request at all, but instead 
rely on the information in the code, which will itself be JWT and will 
encapsulate all the informations to be put into the token itself. I will 
likely send another email about that..

I think that for the case when you want to ensure very consistent 
behaviour, you will be able to configure the channel between datacenters 
to be SYNC instead of ASYNC. However that will have performance penalty.

Marek
>
> Best regards,
> Sebastian
>
> P.S.: If I recall correctly, Infinispan does not support a "serializable" isolation level preventing lost updates, so even if Keycloak used the transaction API, it would not help...
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda
> Sent: Montag, 15. Mai 2017 18:25
> To: keycloak-dev at lists.jboss.org
> Subject: [keycloak-dev] Slight refactoring of InfinispanUserSessionProvider
>
> In today's call with Stian and Hynek, we discussed the possible refactoring of InfinispanUserSessionProvider to be reliable in cluster/cross-dc environment.
>
> Current implementation has tightly couple between the model
> (UserSessionAdapter) and underlying infinispan entity. For example when you call "userSessionModel.setLastSessionRefresh(123)" it directly delegates this call to infinispan entity and calls "entity.setLastSessionRefresh(123)" .
>
> Some issues with this approach:
>
> 1) Possibility of lost updates in cluster - It can happen that there are more concurrent requests updating same userSession. There is a fix by Bill [1], which adds the thread-safety to UserSessionEntity and fixes the issue in local environment. However in cluster with more nodes, it can still happen that there is "lost update". I've created the JIRA [2] for this with details. In shortcut, what can happen is, that there is
> request1 processed on node1 and request2 processed on node2 in parallel.
> Both requests read the sessionEntity and then both perform concurrent update and commits their transaction. Then the latter update wins and overwrites the first update as the state when it read the entity didn't yet contain the first update.
>
> 2) Rollback doesn't work correctly. Basically when we do this:
>
> {code}
> userSession.setLastSessionRefresh(123);
> session.transaction().rollback();
> {code}
>
> the keycloak transaction should be rolled-back and session in infinispan cache shouldn't be updated to lastSessionRefresh 123. However in current implementation, rollback doesn't work and entity is always updated in local environment and may be updated in cluster too (in case that calling node is the owner of session entity). That's because we are not using infinispan transaction API and calling "entity.setLastSessionRefresh(123)" directly updates the entity instance referenced by infinispan storage.
>
> 3) Cross-dc support with good performance
>
> Ideal is to fix all issues and ensure consistency, but have the same/similar performance at the same time and not introduce additional uneccessary locking.
>
>
> Possible solution:
>
> - Every change to UserSessionModel won't delegate directly to infinispan sessionEntity as it's now. Instead it will track the change through changelogs/events, which are saved locally in our infinispan transaction (eg. AddClientToSessionEvent, LastSessionRefreshUpdateEvent).
>
> - During Keycloak transaction commit are changelogs applied to sessionEntity. It may use atomic operation "cache.replace(key, oldValue, newValue)" and the pattern like this:
>
> {code}
> boolean replaced = false;
>
> while (!replaced) {
>       SessionEntity oldSession = cache.get("123");
>       // Will update session entity based on the changes tracked in infinispan transaction
>       SessionEntity updatedSession = applyChanges(oldSession);
>       replaced = cache.replace("123", oldSession, updatedSession); } {code}
>
> - In cross-dc environment are changes sent to another datacenter. That will receive changes (eg. AddClientToSessionEvent) and apply changes locally in the datacenter and update the sessionEntity in the infinispan. It shouldn't be a problem that those events are sent between datacenters through the asynchronous channel. The changes may not be guaranteed in same order in every DC, but all of them will be triggered and there won't be lost updates. So the cache "sessions" won't be directly replicated through the cross-dc, but instead the changes will be sent between datacenters.
>
> What do you think? Can you see some issues with this approach?
>
> Thanks,
> Marek
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-4821
> [2] https://issues.jboss.org/browse/KEYCLOAK-4898
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From Sebastian.Schuster at bosch-si.com  Tue May 16 11:04:10 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 16 May 2017 15:04:10 +0000
Subject: [keycloak-dev] Slight refactoring of
 InfinispanUserSessionProvider
In-Reply-To: <6df1aed4-8d5e-1faa-b61e-e0fc7e78a121@redhat.com>
References: <fd61a0fd-0dd6-b4af-cd9f-8f7992289414@redhat.com>
	<fee600fd8d0a4972ac3f2cbe21e00741@FE-MBX1028.de.bosch.com>
	<6df1aed4-8d5e-1faa-b61e-e0fc7e78a121@redhat.com>
Message-ID: <acd13377b21645988fde55400d9c8cf5@FE-MBX1028.de.bosch.com>

Hi Marek,

comment inline...

> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Dienstag, 16. Mai 2017 10:41
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Slight refactoring of InfinispanUserSessionProvider
> 
> On 16/05/17 09:38, Schuster Sebastian (INST/ESY1) wrote:
> > Hi Marek,
> >
> > You mentioned in your proposed solution that " The changes may not be
> guaranteed in same order in every DC". Wouldn't that be a problem as it leads to
> inconsistent data in different data centers?
> I was thinking about that and ATM I can't see the scenario when it is a problem with
> respect to our business logic related to userSession model.
> 
> For example it can happen that there is request1 for add client "client1" in dc1. And
> at the same time request2 for add "client2" in dc2.  So it may happen that request1
> will add "client1" to the userSession and send the message to dc2 for add "client1"
> . At the same time request2 will add "client2" to the userSession in dc2 and send
> the message to dc1 for add "client1" . After some time, both DCs will receive the
> message from the other DC and both will update their client list to be ["client1",
> "client2"] .

Agreed, if having intermediate inconsistent states does not hurt anybody else, doing this
in an eventually-consistent style should be fine. I found some indications the Infinispan
guys want to add eventual consistency anyways, maybe it is worthwile to talk to them?
See http://infinispan.org/docs/stable/glossary/glossary.html#basically_available_soft_state_eventually_consistent_base
and https://issues.jboss.org/browse/ISPN-999 (and adore the issue number).

> 
> Important is, that there won't be lost update (which can easily happen now).
> 
> There are various corner cases (eg. DC will receive the message about update of
> userSession, which was already logged-out/removed in this DC etc), but all of
> those can be handled IMO.

To be honest, I am a bit afraid of them. Concurrency related corner cases are like the end
boss and really hard to get right, typically. :)

Best regards.
Sebastian

> 
> One special thing is code-to-token request as it can happen very quickly after the
> userSession is created. And it can be processed on different DC then the one
> when userSession was created. So my current thinking is to not lookup
> userSession in code-to-token request at all, but instead rely on the information in
> the code, which will itself be JWT and will encapsulate all the informations to be
> put into the token itself. I will likely send another email about that..
> 
> I think that for the case when you want to ensure very consistent behaviour, you
> will be able to configure the channel between datacenters to be SYNC instead of
> ASYNC. However that will have performance penalty.
> 
> Marek
> >
> > Best regards,
> > Sebastian
> >
> > P.S.: If I recall correctly, Infinispan does not support a "serializable" isolation
> level preventing lost updates, so even if Keycloak used the transaction API, it
> would not help...
> >
> > Mit freundlichen Gr??en / Best regards
> >
> >   Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
> > Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
> > 30 726112-100 | Sebastian.Schuster at bosch-si.com
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
> > B
> > Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >
> >
> > -----Original Message-----
> > From: keycloak-dev-bounces at lists.jboss.org
> > [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
> > Posolda
> > Sent: Montag, 15. Mai 2017 18:25
> > To: keycloak-dev at lists.jboss.org
> > Subject: [keycloak-dev] Slight refactoring of
> > InfinispanUserSessionProvider
> >
> > In today's call with Stian and Hynek, we discussed the possible refactoring of
> InfinispanUserSessionProvider to be reliable in cluster/cross-dc environment.
> >
> > Current implementation has tightly couple between the model
> > (UserSessionAdapter) and underlying infinispan entity. For example when you
> call "userSessionModel.setLastSessionRefresh(123)" it directly delegates this call
> to infinispan entity and calls "entity.setLastSessionRefresh(123)" .
> >
> > Some issues with this approach:
> >
> > 1) Possibility of lost updates in cluster - It can happen that there
> > are more concurrent requests updating same userSession. There is a fix
> > by Bill [1], which adds the thread-safety to UserSessionEntity and
> > fixes the issue in local environment. However in cluster with more
> > nodes, it can still happen that there is "lost update". I've created
> > the JIRA [2] for this with details. In shortcut, what can happen is,
> > that there is
> > request1 processed on node1 and request2 processed on node2 in parallel.
> > Both requests read the sessionEntity and then both perform concurrent update
> and commits their transaction. Then the latter update wins and overwrites the first
> update as the state when it read the entity didn't yet contain the first update.
> >
> > 2) Rollback doesn't work correctly. Basically when we do this:
> >
> > {code}
> > userSession.setLastSessionRefresh(123);
> > session.transaction().rollback();
> > {code}
> >
> > the keycloak transaction should be rolled-back and session in infinispan cache
> shouldn't be updated to lastSessionRefresh 123. However in current
> implementation, rollback doesn't work and entity is always updated in local
> environment and may be updated in cluster too (in case that calling node is the
> owner of session entity). That's because we are not using infinispan transaction
> API and calling "entity.setLastSessionRefresh(123)" directly updates the entity
> instance referenced by infinispan storage.
> >
> > 3) Cross-dc support with good performance
> >
> > Ideal is to fix all issues and ensure consistency, but have the same/similar
> performance at the same time and not introduce additional uneccessary locking.
> >
> >
> > Possible solution:
> >
> > - Every change to UserSessionModel won't delegate directly to infinispan
> sessionEntity as it's now. Instead it will track the change through
> changelogs/events, which are saved locally in our infinispan transaction (eg.
> AddClientToSessionEvent, LastSessionRefreshUpdateEvent).
> >
> > - During Keycloak transaction commit are changelogs applied to sessionEntity. It
> may use atomic operation "cache.replace(key, oldValue, newValue)" and the
> pattern like this:
> >
> > {code}
> > boolean replaced = false;
> >
> > while (!replaced) {
> >       SessionEntity oldSession = cache.get("123");
> >       // Will update session entity based on the changes tracked in infinispan
> transaction
> >       SessionEntity updatedSession = applyChanges(oldSession);
> >       replaced = cache.replace("123", oldSession, updatedSession); }
> > {code}
> >
> > - In cross-dc environment are changes sent to another datacenter. That will
> receive changes (eg. AddClientToSessionEvent) and apply changes locally in the
> datacenter and update the sessionEntity in the infinispan. It shouldn't be a problem
> that those events are sent between datacenters through the asynchronous channel.
> The changes may not be guaranteed in same order in every DC, but all of them will
> be triggered and there won't be lost updates. So the cache "sessions" won't be
> directly replicated through the cross-dc, but instead the changes will be sent
> between datacenters.
> >
> > What do you think? Can you see some issues with this approach?
> >
> > Thanks,
> > Marek
> >
> > [1] https://issues.jboss.org/browse/KEYCLOAK-4821
> > [2] https://issues.jboss.org/browse/KEYCLOAK-4898
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 



From mposolda at redhat.com  Wed May 17 05:36:09 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 May 2017 11:36:09 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on a
	Timeout
Message-ID: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>

We have the issue that after session timeout, the page "An error 
occurred, please login again through your application." can be shown. 
This is even worse when there is no link to go back to the application 
as users might be confused what to do. Details in 
https://issues.jboss.org/browse/KEYCLOAK-4016 .

This is already handled in many cases as when authentication session is 
expired, it is always restarted from the KC_RESTART cookie.

However there are still cases when this error is shown, which is when 
the restart from the cookie failed. This can happen when browser history 
(including cookies) was cleared or when user restarted the browser (as 
the KC_RESTART cookie is not persistent).

Some possibilities to solve:
1) Make the KC_RESTART cookie persistent. That will handle browser 
restart, however it won't handle the case when browser history is deleted

2) Add client-id to every link as Stefan Baust suggested. Then we can 
add the link to client base uri on the page. This is more work with the 
possibility of error-prone if we miss to add the client-id to some link. 
Also we will be able to provide the link just if client has "base-uri" 
configured.

3) Add the link to the account management application page. After 
successful login will be shown list of applications in account 
management and user can click to his favourite application. Message 
would need to be changed to something like "An error occurred, please 
login again through your application or go to the <link>list of 
applications<link> and select your application after login."

My preference is 3, 2, 1. WDYT? Any other ideas?

Thanks,
Marek


From mposolda at redhat.com  Wed May 17 05:47:58 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 May 2017 11:47:58 +0200
Subject: [keycloak-dev] Slight refactoring of
 InfinispanUserSessionProvider
In-Reply-To: <acd13377b21645988fde55400d9c8cf5@FE-MBX1028.de.bosch.com>
References: <fd61a0fd-0dd6-b4af-cd9f-8f7992289414@redhat.com>
	<fee600fd8d0a4972ac3f2cbe21e00741@FE-MBX1028.de.bosch.com>
	<6df1aed4-8d5e-1faa-b61e-e0fc7e78a121@redhat.com>
	<acd13377b21645988fde55400d9c8cf5@FE-MBX1028.de.bosch.com>
Message-ID: <0761d87a-f25f-f92e-5208-99e1962431bf@redhat.com>

On 16/05/17 17:04, Schuster Sebastian (INST/ESY1) wrote:
> Hi Marek,
>
> comment inline...
>
>> -----Original Message-----
>> From: Marek Posolda [mailto:mposolda at redhat.com]
>> Sent: Dienstag, 16. Mai 2017 10:41
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Slight refactoring of InfinispanUserSessionProvider
>>
>> On 16/05/17 09:38, Schuster Sebastian (INST/ESY1) wrote:
>>> Hi Marek,
>>>
>>> You mentioned in your proposed solution that " The changes may not be
>> guaranteed in same order in every DC". Wouldn't that be a problem as it leads to
>> inconsistent data in different data centers?
>> I was thinking about that and ATM I can't see the scenario when it is a problem with
>> respect to our business logic related to userSession model.
>>
>> For example it can happen that there is request1 for add client "client1" in dc1. And
>> at the same time request2 for add "client2" in dc2.  So it may happen that request1
>> will add "client1" to the userSession and send the message to dc2 for add "client1"
>> . At the same time request2 will add "client2" to the userSession in dc2 and send
>> the message to dc1 for add "client1" . After some time, both DCs will receive the
>> message from the other DC and both will update their client list to be ["client1",
>> "client2"] .
> Agreed, if having intermediate inconsistent states does not hurt anybody else, doing this
> in an eventually-consistent style should be fine. I found some indications the Infinispan
> guys want to add eventual consistency anyways, maybe it is worthwile to talk to them?
> See http://infinispan.org/docs/stable/glossary/glossary.html#basically_available_soft_state_eventually_consistent_base
> and https://issues.jboss.org/browse/ISPN-999 (and adore the issue number).
Just a note that we can be always consistent in "simple" cluster. The 
eventual inconsistency can happen just in the cross-datacenter 
environment. Doing everything synchronously can be a big challenge for 
the performance though as the network connection between data-centers 
can be slow and blocking user requests until the message is transferred 
to the other DC will be performance blocker.
>
>> Important is, that there won't be lost update (which can easily happen now).
>>
>> There are various corner cases (eg. DC will receive the message about update of
>> userSession, which was already logged-out/removed in this DC etc), but all of
>> those can be handled IMO.
> To be honest, I am a bit afraid of them. Concurrency related corner cases are like the end
> boss and really hard to get right, typically. :)
It won't be so easy, but it's doable. Hopefully :) For example when you 
receive the message for update the session, which was already removed 
locally, then you just ignore the message. Or updating 
"lastSessionRefresh" to the earlier time then the current value of 
session will be ignored too. etc.

Marek
>
> Best regards.
> Sebastian
>
>> One special thing is code-to-token request as it can happen very quickly after the
>> userSession is created. And it can be processed on different DC then the one
>> when userSession was created. So my current thinking is to not lookup
>> userSession in code-to-token request at all, but instead rely on the information in
>> the code, which will itself be JWT and will encapsulate all the informations to be
>> put into the token itself. I will likely send another email about that..
>>
>> I think that for the case when you want to ensure very consistent behaviour, you
>> will be able to configure the channel between datacenters to be SYNC instead of
>> ASYNC. However that will have performance penalty.
>>
>> Marek
>>> Best regards,
>>> Sebastian
>>>
>>> P.S.: If I recall correctly, Infinispan does not support a "serializable" isolation
>> level preventing lost updates, so even if Keycloak used the transaction API, it
>> would not help...
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>    Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>> Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
>>> 30 726112-100 | Sebastian.Schuster at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
>>> B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org
>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
>>> Posolda
>>> Sent: Montag, 15. Mai 2017 18:25
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: [keycloak-dev] Slight refactoring of
>>> InfinispanUserSessionProvider
>>>
>>> In today's call with Stian and Hynek, we discussed the possible refactoring of
>> InfinispanUserSessionProvider to be reliable in cluster/cross-dc environment.
>>> Current implementation has tightly couple between the model
>>> (UserSessionAdapter) and underlying infinispan entity. For example when you
>> call "userSessionModel.setLastSessionRefresh(123)" it directly delegates this call
>> to infinispan entity and calls "entity.setLastSessionRefresh(123)" .
>>> Some issues with this approach:
>>>
>>> 1) Possibility of lost updates in cluster - It can happen that there
>>> are more concurrent requests updating same userSession. There is a fix
>>> by Bill [1], which adds the thread-safety to UserSessionEntity and
>>> fixes the issue in local environment. However in cluster with more
>>> nodes, it can still happen that there is "lost update". I've created
>>> the JIRA [2] for this with details. In shortcut, what can happen is,
>>> that there is
>>> request1 processed on node1 and request2 processed on node2 in parallel.
>>> Both requests read the sessionEntity and then both perform concurrent update
>> and commits their transaction. Then the latter update wins and overwrites the first
>> update as the state when it read the entity didn't yet contain the first update.
>>> 2) Rollback doesn't work correctly. Basically when we do this:
>>>
>>> {code}
>>> userSession.setLastSessionRefresh(123);
>>> session.transaction().rollback();
>>> {code}
>>>
>>> the keycloak transaction should be rolled-back and session in infinispan cache
>> shouldn't be updated to lastSessionRefresh 123. However in current
>> implementation, rollback doesn't work and entity is always updated in local
>> environment and may be updated in cluster too (in case that calling node is the
>> owner of session entity). That's because we are not using infinispan transaction
>> API and calling "entity.setLastSessionRefresh(123)" directly updates the entity
>> instance referenced by infinispan storage.
>>> 3) Cross-dc support with good performance
>>>
>>> Ideal is to fix all issues and ensure consistency, but have the same/similar
>> performance at the same time and not introduce additional uneccessary locking.
>>>
>>> Possible solution:
>>>
>>> - Every change to UserSessionModel won't delegate directly to infinispan
>> sessionEntity as it's now. Instead it will track the change through
>> changelogs/events, which are saved locally in our infinispan transaction (eg.
>> AddClientToSessionEvent, LastSessionRefreshUpdateEvent).
>>> - During Keycloak transaction commit are changelogs applied to sessionEntity. It
>> may use atomic operation "cache.replace(key, oldValue, newValue)" and the
>> pattern like this:
>>> {code}
>>> boolean replaced = false;
>>>
>>> while (!replaced) {
>>>        SessionEntity oldSession = cache.get("123");
>>>        // Will update session entity based on the changes tracked in infinispan
>> transaction
>>>        SessionEntity updatedSession = applyChanges(oldSession);
>>>        replaced = cache.replace("123", oldSession, updatedSession); }
>>> {code}
>>>
>>> - In cross-dc environment are changes sent to another datacenter. That will
>> receive changes (eg. AddClientToSessionEvent) and apply changes locally in the
>> datacenter and update the sessionEntity in the infinispan. It shouldn't be a problem
>> that those events are sent between datacenters through the asynchronous channel.
>> The changes may not be guaranteed in same order in every DC, but all of them will
>> be triggered and there won't be lost updates. So the cache "sessions" won't be
>> directly replicated through the cross-dc, but instead the changes will be sent
>> between datacenters.
>>> What do you think? Can you see some issues with this approach?
>>>
>>> Thanks,
>>> Marek
>>>
>>> [1] https://issues.jboss.org/browse/KEYCLOAK-4821
>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4898
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From Sebastian.Schuster at bosch-si.com  Wed May 17 09:09:48 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 17 May 2017 13:09:48 +0000
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
	a	Timeout
In-Reply-To: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
Message-ID: <41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>

Wouldn't 1) be a good option as browser restarts are the vast majority compared to history deletion?
Even our very restrictive company directives don't clear the browser history on exit while messing around
with a lot of my other browser settings...

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> bounces at lists.jboss.org] On Behalf Of Marek Posolda
> Sent: Mittwoch, 17. Mai 2017 11:36
> To: keycloak-dev at lists.jboss.org
> Subject: [keycloak-dev] Provide a Link to go Back to The Application on a Timeout
> 
> We have the issue that after session timeout, the page "An error occurred, please
> login again through your application." can be shown.
> This is even worse when there is no link to go back to the application as users
> might be confused what to do. Details in
> https://issues.jboss.org/browse/KEYCLOAK-4016 .
> 
> This is already handled in many cases as when authentication session is expired, it
> is always restarted from the KC_RESTART cookie.
> 
> However there are still cases when this error is shown, which is when the restart
> from the cookie failed. This can happen when browser history (including cookies)
> was cleared or when user restarted the browser (as the KC_RESTART cookie is not
> persistent).
> 
> Some possibilities to solve:
> 1) Make the KC_RESTART cookie persistent. That will handle browser restart,
> however it won't handle the case when browser history is deleted
> 
> 2) Add client-id to every link as Stefan Baust suggested. Then we can add the link
> to client base uri on the page. This is more work with the possibility of error-prone
> if we miss to add the client-id to some link.
> Also we will be able to provide the link just if client has "base-uri"
> configured.
> 
> 3) Add the link to the account management application page. After successful
> login will be shown list of applications in account management and user can click
> to his favourite application. Message would need to be changed to something like
> "An error occurred, please login again through your application or go to the
> <link>list of applications<link> and select your application after login."
> 
> My preference is 3, 2, 1. WDYT? Any other ideas?
> 
> Thanks,
> Marek
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Wed May 17 09:29:05 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 May 2017 15:29:05 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>
Message-ID: <d4b71e85-3d51-561c-4b83-f2d4465b31d6@redhat.com>

Maybe yes.

There is also the case when the link of login page can be copy/pasted 
somehow and opened in new browser. The KC_RESTART cookie then also won't 
be visible. But this really looks like corner case...

Maybe we can have the combination of 1 and 3? Have the cookie persistent 
and show the page with account management link just if KC_RESTART cookie 
is really unavailable.

Marek

On 17/05/17 15:09, Schuster Sebastian (INST/ESY1) wrote:
> Wouldn't 1) be a good option as browser restarts are the vast majority compared to history deletion?
> Even our very restrictive company directives don't clear the browser history on exit while messing around
> with a lot of my other browser settings...
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>> bounces at lists.jboss.org] On Behalf Of Marek Posolda
>> Sent: Mittwoch, 17. Mai 2017 11:36
>> To: keycloak-dev at lists.jboss.org
>> Subject: [keycloak-dev] Provide a Link to go Back to The Application on a Timeout
>>
>> We have the issue that after session timeout, the page "An error occurred, please
>> login again through your application." can be shown.
>> This is even worse when there is no link to go back to the application as users
>> might be confused what to do. Details in
>> https://issues.jboss.org/browse/KEYCLOAK-4016 .
>>
>> This is already handled in many cases as when authentication session is expired, it
>> is always restarted from the KC_RESTART cookie.
>>
>> However there are still cases when this error is shown, which is when the restart
>> from the cookie failed. This can happen when browser history (including cookies)
>> was cleared or when user restarted the browser (as the KC_RESTART cookie is not
>> persistent).
>>
>> Some possibilities to solve:
>> 1) Make the KC_RESTART cookie persistent. That will handle browser restart,
>> however it won't handle the case when browser history is deleted
>>
>> 2) Add client-id to every link as Stefan Baust suggested. Then we can add the link
>> to client base uri on the page. This is more work with the possibility of error-prone
>> if we miss to add the client-id to some link.
>> Also we will be able to provide the link just if client has "base-uri"
>> configured.
>>
>> 3) Add the link to the account management application page. After successful
>> login will be shown list of applications in account management and user can click
>> to his favourite application. Message would need to be changed to something like
>> "An error occurred, please login again through your application or go to the
>> <link>list of applications<link> and select your application after login."
>>
>> My preference is 3, 2, 1. WDYT? Any other ideas?
>>
>> Thanks,
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From ssilvert at redhat.com  Wed May 17 15:04:20 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 17 May 2017 15:04:20 -0400
Subject: [keycloak-dev] add-user-keycloak.bat broken?
Message-ID: <dccadd17-50aa-11a7-7c4a-be703248e490@redhat.com>

I don't have time to look into it right now, but it's not working on my 
Windows box.

Hoping someone touched this recently and might know what the problem 
is?  Biggest clue is that it spits out "null" instead of the usual "file 
created" message.

c:\GitHub\keycloak\distribution\server-dist\target\keycloak-3.2.0.CR1-SNAPSHOT\bin>add-user-keycloak 
-u admin -p admin
null
Press any key to continue . . .



From luke at anotherrobbo.com  Wed May 17 21:26:32 2017
From: luke at anotherrobbo.com (luke at anotherrobbo.com)
Date: Thu, 18 May 2017 11:26:32 +1000
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <d4b71e85-3d51-561c-4b83-f2d4465b31d6@redhat.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>
	<d4b71e85-3d51-561c-4b83-f2d4465b31d6@redhat.com>
Message-ID: <20170518112632.Horde.J-9m-I9POcsntyLglFFxjdU@brian.zuver.net.au>

For what it's worth, option 3 is similar to what we have implemented  
in our theme's error.ftl.

Our main use case was for expired email confirmation / password reset  
links (we'd really like to see something done with  
https://issues.jboss.org/browse/KEYCLOAK-3631 so we can increase our  
limits past the SSO idle time but that's another issue!)

We've hardcoded the url (${msg("attemptLogin", "/auth/realms/" +  
realm.name + "/account/applications")}), it would certainly be nice to  
have a better way of doing this so the theme doesn't need to know the  
URL?

Cheers,

Luke

Quoting Marek Posolda <mposolda at redhat.com>:

> Maybe yes.
>
> There is also the case when the link of login page can be copy/pasted
> somehow and opened in new browser. The KC_RESTART cookie then also won't
> be visible. But this really looks like corner case...
>
> Maybe we can have the combination of 1 and 3? Have the cookie persistent
> and show the page with account management link just if KC_RESTART cookie
> is really unavailable.
>
> Marek
>
> On 17/05/17 15:09, Schuster Sebastian (INST/ESY1) wrote:
>> Wouldn't 1) be a good option as browser restarts are the vast  
>> majority compared to history deletion?
>> Even our very restrictive company directives don't clear the  
>> browser history on exit while messing around
>> with a lot of my other browser settings...
>>
>> Best regards,
>> Sebastian
>>
>> Mit freundlichen Gr??en / Best regards
>>
>>   Sebastian Schuster
>>
>> Engineering and Support (INST/ESY1)
>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785  
>> Berlin | GERMANY | www.bosch-si.com
>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |  
>> Sebastian.Schuster at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>> bounces at lists.jboss.org] On Behalf Of Marek Posolda
>>> Sent: Mittwoch, 17. Mai 2017 11:36
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: [keycloak-dev] Provide a Link to go Back to The  
>>> Application on a Timeout
>>>
>>> We have the issue that after session timeout, the page "An error  
>>> occurred, please
>>> login again through your application." can be shown.
>>> This is even worse when there is no link to go back to the  
>>> application as users
>>> might be confused what to do. Details in
>>> https://issues.jboss.org/browse/KEYCLOAK-4016 .
>>>
>>> This is already handled in many cases as when authentication  
>>> session is expired, it
>>> is always restarted from the KC_RESTART cookie.
>>>
>>> However there are still cases when this error is shown, which is  
>>> when the restart
>>> from the cookie failed. This can happen when browser history  
>>> (including cookies)
>>> was cleared or when user restarted the browser (as the KC_RESTART  
>>> cookie is not
>>> persistent).
>>>
>>> Some possibilities to solve:
>>> 1) Make the KC_RESTART cookie persistent. That will handle browser restart,
>>> however it won't handle the case when browser history is deleted
>>>
>>> 2) Add client-id to every link as Stefan Baust suggested. Then we  
>>> can add the link
>>> to client base uri on the page. This is more work with the  
>>> possibility of error-prone
>>> if we miss to add the client-id to some link.
>>> Also we will be able to provide the link just if client has "base-uri"
>>> configured.
>>>
>>> 3) Add the link to the account management application page. After  
>>> successful
>>> login will be shown list of applications in account management and  
>>> user can click
>>> to his favourite application. Message would need to be changed to  
>>> something like
>>> "An error occurred, please login again through your application or  
>>> go to the
>>> <link>list of applications<link> and select your application after login."
>>>
>>> My preference is 3, 2, 1. WDYT? Any other ideas?
>>>
>>> Thanks,
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From crafton.williams at qut.edu.au  Thu May 18 02:17:44 2017
From: crafton.williams at qut.edu.au (Crafton Williams)
Date: Thu, 18 May 2017 06:17:44 +0000
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
Message-ID: <SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>

Hi All:

I?m trying to configure a basic springboot app using the springboot keycloak adapter. Authentication works as expected but I?m a bit confused as to how to configure the policy enforcer in yaml. The documentation shows configuring the policy-enforcer as a json document however the springboot config implies a only policy-enforcer-config. In any case, I did try the json doc but it wasn?t picked up by the adapter.

I?m using 3.0.0.Final and tried the following in my yaml file(omitted the rest of the path info for brevity):

Policy-enforcer-config:
  Enforcement-mode: ENFORCING
  paths:

  *   name: blah

The exception I got was:

org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'tomcatEmbeddedServletContainerFactory' defined in class path resource [org/springframework/boot/autoconfigure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]: Initialization of bean failed; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.keycloak.adapters.springboot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed through method 'setKeycloakSpringBootProperties' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'keycloak-org.keycloak.adapters.springboot.KeycloakSpringBootProperties': Could not bind properties to KeycloakSpringBootProperties (prefix=keycloak, ignoreInvalidFields=false, ignoreUnknownFields=false, ignoreNestedProperties=false); nested exception is org.springframework.beans.InvalidPropertyException: Invalid property 'policyEnforcerConfig.paths[0]' of bean class [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]: Illegal attempt to get property 'paths' threw exception; nested exception is java.lang.UnsupportedOperationException

Is there an example project somewhere that can guide me in configuring the policy enforcer for the springboot adapter?

Cheers,

Crafton


From mposolda at redhat.com  Thu May 18 02:38:31 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 May 2017 08:38:31 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <20170518112632.Horde.J-9m-I9POcsntyLglFFxjdU@brian.zuver.net.au>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>
	<d4b71e85-3d51-561c-4b83-f2d4465b31d6@redhat.com>
	<20170518112632.Horde.J-9m-I9POcsntyLglFFxjdU@brian.zuver.net.au>
Message-ID: <eab9debc-77c2-5576-9114-b86ea441e305@redhat.com>

On 18/05/17 03:26, luke at anotherrobbo.com wrote:
> For what it's worth, option 3 is similar to what we have implemented
> in our theme's error.ftl.
>
> Our main use case was for expired email confirmation / password reset
> links (we'd really like to see something done with
> https://issues.jboss.org/browse/KEYCLOAK-3631 so we can increase our
> limits past the SSO idle time but that's another issue!)
Good news for you. We introduced action tokens recently and it's in 
latest master. This introduces separate timeout for admin actions (among 
other things). In other words, your use-case from KEYCLOAK-3631 should 
be already possible with latest master and will be in 3.2.0 release.
>
> We've hardcoded the url (${msg("attemptLogin", "/auth/realms/" +
> realm.name + "/account/applications")}), it would certainly be nice to
> have a better way of doing this so the theme doesn't need to know the
> URL?
Yes, we already have URLBean, which is used to abstracts the URL 
creation logic from the freemarker template itself.

Marek
>
> Cheers,
>
> Luke
>
> Quoting Marek Posolda <mposolda at redhat.com>:
>
>> Maybe yes.
>>
>> There is also the case when the link of login page can be copy/pasted
>> somehow and opened in new browser. The KC_RESTART cookie then also won't
>> be visible. But this really looks like corner case...
>>
>> Maybe we can have the combination of 1 and 3? Have the cookie persistent
>> and show the page with account management link just if KC_RESTART cookie
>> is really unavailable.
>>
>> Marek
>>
>> On 17/05/17 15:09, Schuster Sebastian (INST/ESY1) wrote:
>>> Wouldn't 1) be a good option as browser restarts are the vast
>>> majority compared to history deletion?
>>> Even our very restrictive company directives don't clear the
>>> browser history on exit while messing around
>>> with a lot of my other browser settings...
>>>
>>> Best regards,
>>> Sebastian
>>>
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>    Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>> Berlin | GERMANY | www.bosch-si.com
>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>> Sebastian.Schuster at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>> bounces at lists.jboss.org] On Behalf Of Marek Posolda
>>>> Sent: Mittwoch, 17. Mai 2017 11:36
>>>> To: keycloak-dev at lists.jboss.org
>>>> Subject: [keycloak-dev] Provide a Link to go Back to The
>>>> Application on a Timeout
>>>>
>>>> We have the issue that after session timeout, the page "An error
>>>> occurred, please
>>>> login again through your application." can be shown.
>>>> This is even worse when there is no link to go back to the
>>>> application as users
>>>> might be confused what to do. Details in
>>>> https://issues.jboss.org/browse/KEYCLOAK-4016 .
>>>>
>>>> This is already handled in many cases as when authentication
>>>> session is expired, it
>>>> is always restarted from the KC_RESTART cookie.
>>>>
>>>> However there are still cases when this error is shown, which is
>>>> when the restart
>>>> from the cookie failed. This can happen when browser history
>>>> (including cookies)
>>>> was cleared or when user restarted the browser (as the KC_RESTART
>>>> cookie is not
>>>> persistent).
>>>>
>>>> Some possibilities to solve:
>>>> 1) Make the KC_RESTART cookie persistent. That will handle browser restart,
>>>> however it won't handle the case when browser history is deleted
>>>>
>>>> 2) Add client-id to every link as Stefan Baust suggested. Then we
>>>> can add the link
>>>> to client base uri on the page. This is more work with the
>>>> possibility of error-prone
>>>> if we miss to add the client-id to some link.
>>>> Also we will be able to provide the link just if client has "base-uri"
>>>> configured.
>>>>
>>>> 3) Add the link to the account management application page. After
>>>> successful
>>>> login will be shown list of applications in account management and
>>>> user can click
>>>> to his favourite application. Message would need to be changed to
>>>> something like
>>>> "An error occurred, please login again through your application or
>>>> go to the
>>>> <link>list of applications<link> and select your application after login."
>>>>
>>>> My preference is 3, 2, 1. WDYT? Any other ideas?
>>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Thu May 18 02:49:15 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 May 2017 08:49:15 +0200
Subject: [keycloak-dev] add-user-keycloak.bat broken?
In-Reply-To: <dccadd17-50aa-11a7-7c4a-be703248e490@redhat.com>
References: <dccadd17-50aa-11a7-7c4a-be703248e490@redhat.com>
Message-ID: <CAJgngAdEDnhssXHXJSYA9P6KThJ6k2wwEVDsEs8ZWWrQeyKHbg@mail.gmail.com>

add-user-keycloak.sh broken as well and it's probably my fault.

https://issues.jboss.org/browse/KEYCLOAK-4921

On 17 May 2017 at 21:04, Stan Silvert <ssilvert at redhat.com> wrote:

> I don't have time to look into it right now, but it's not working on my
> Windows box.
>
> Hoping someone touched this recently and might know what the problem
> is?  Biggest clue is that it spits out "null" instead of the usual "file
> created" message.
>
> c:\GitHub\keycloak\distribution\server-dist\target\keycloak-3.2.0.CR1-
> SNAPSHOT\bin>add-user-keycloak
> -u admin -p admin
> null
> Press any key to continue . . .
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From luke at anotherrobbo.com  Thu May 18 03:07:45 2017
From: luke at anotherrobbo.com (Luke Robinson)
Date: Thu, 18 May 2017 17:07:45 +1000
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <eab9debc-77c2-5576-9114-b86ea441e305@redhat.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>
	<d4b71e85-3d51-561c-4b83-f2d4465b31d6@redhat.com>
	<20170518112632.Horde.J-9m-I9POcsntyLglFFxjdU@brian.zuver.net.au>
	<eab9debc-77c2-5576-9114-b86ea441e305@redhat.com>
Message-ID: <20170518170745.Horde.vm9Gwi7fpRtat4Aj1E4zK45@brian.zuver.net.au>

I did look at using UrlBean because I knew that  
org.keycloak.forms.account.freemarker.model.UrlBean has  
getApplicationsUrl() for use in the account theme but I couldn't find  
anything in the org.keycloak.forms.login.freemarker.model.UrlBean  
available to error.ftl that would give us what we are after.

We're using RHSSO 7.0 (moving to 7.1 shortly) so things may have  
changed since 1.9.8 / 2.5.5 but having a quick skim of the code in  
master now I expect that this is still the case.

Luke


Quoting Marek Posolda <mposolda at redhat.com>:

> On 18/05/17 03:26, luke at anotherrobbo.com wrote:
>> For what it's worth, option 3 is similar to what we have implemented
>> in our theme's error.ftl.
>>
>> Our main use case was for expired email confirmation / password reset
>> links (we'd really like to see something done with
>> https://issues.jboss.org/browse/KEYCLOAK-3631 so we can increase our
>> limits past the SSO idle time but that's another issue!)
> Good news for you. We introduced action tokens recently and it's in  
> latest master. This introduces separate timeout for admin actions  
> (among other things). In other words, your use-case from  
> KEYCLOAK-3631 should be already possible with latest master and will  
> be in 3.2.0 release.
>>
>> We've hardcoded the url (${msg("attemptLogin", "/auth/realms/" +
>> realm.name + "/account/applications")}), it would certainly be nice to
>> have a better way of doing this so the theme doesn't need to know the
>> URL?
> Yes, we already have URLBean, which is used to abstracts the URL  
> creation logic from the freemarker template itself.
>
> Marek
>>
>> Cheers,
>>
>> Luke
>>
>> Quoting Marek Posolda <mposolda at redhat.com>:
>>
>>> Maybe yes.
>>>
>>> There is also the case when the link of login page can be copy/pasted
>>> somehow and opened in new browser. The KC_RESTART cookie then also won't
>>> be visible. But this really looks like corner case...
>>>
>>> Maybe we can have the combination of 1 and 3? Have the cookie persistent
>>> and show the page with account management link just if KC_RESTART cookie
>>> is really unavailable.
>>>
>>> Marek
>>>
>>> On 17/05/17 15:09, Schuster Sebastian (INST/ESY1) wrote:
>>>> Wouldn't 1) be a good option as browser restarts are the vast
>>>> majority compared to history deletion?
>>>> Even our very restrictive company directives don't clear the
>>>> browser history on exit while messing around
>>>> with a lot of my other browser settings...
>>>>
>>>> Best regards,
>>>> Sebastian
>>>>
>>>> Mit freundlichen Gr??en / Best regards
>>>>
>>>>   Sebastian Schuster
>>>>
>>>> Engineering and Support (INST/ESY1)
>>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>>> Berlin | GERMANY | www.bosch-si.com
>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>>> Sebastian.Schuster at bosch-si.com
>>>>
>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>>> bounces at lists.jboss.org] On Behalf Of Marek Posolda
>>>>> Sent: Mittwoch, 17. Mai 2017 11:36
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Subject: [keycloak-dev] Provide a Link to go Back to The
>>>>> Application on a Timeout
>>>>>
>>>>> We have the issue that after session timeout, the page "An error
>>>>> occurred, please
>>>>> login again through your application." can be shown.
>>>>> This is even worse when there is no link to go back to the
>>>>> application as users
>>>>> might be confused what to do. Details in
>>>>> https://issues.jboss.org/browse/KEYCLOAK-4016 .
>>>>>
>>>>> This is already handled in many cases as when authentication
>>>>> session is expired, it
>>>>> is always restarted from the KC_RESTART cookie.
>>>>>
>>>>> However there are still cases when this error is shown, which is
>>>>> when the restart
>>>>> from the cookie failed. This can happen when browser history
>>>>> (including cookies)
>>>>> was cleared or when user restarted the browser (as the KC_RESTART
>>>>> cookie is not
>>>>> persistent).
>>>>>
>>>>> Some possibilities to solve:
>>>>> 1) Make the KC_RESTART cookie persistent. That will handle  
>>>>> browser restart,
>>>>> however it won't handle the case when browser history is deleted
>>>>>
>>>>> 2) Add client-id to every link as Stefan Baust suggested. Then we
>>>>> can add the link
>>>>> to client base uri on the page. This is more work with the
>>>>> possibility of error-prone
>>>>> if we miss to add the client-id to some link.
>>>>> Also we will be able to provide the link just if client has "base-uri"
>>>>> configured.
>>>>>
>>>>> 3) Add the link to the account management application page. After
>>>>> successful
>>>>> login will be shown list of applications in account management and
>>>>> user can click
>>>>> to his favourite application. Message would need to be changed to
>>>>> something like
>>>>> "An error occurred, please login again through your application or
>>>>> go to the
>>>>> <link>list of applications<link> and select your application  
>>>>> after login."
>>>>>
>>>>> My preference is 3, 2, 1. WDYT? Any other ideas?
>>>>>
>>>>> Thanks,
>>>>> Marek
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From mposolda at redhat.com  Thu May 18 03:13:05 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 May 2017 09:13:05 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <20170518170745.Horde.vm9Gwi7fpRtat4Aj1E4zK45@brian.zuver.net.au>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<41890e812a4e4cbbbbd910d2ff974ac5@FE-MBX1028.de.bosch.com>
	<d4b71e85-3d51-561c-4b83-f2d4465b31d6@redhat.com>
	<20170518112632.Horde.J-9m-I9POcsntyLglFFxjdU@brian.zuver.net.au>
	<eab9debc-77c2-5576-9114-b86ea441e305@redhat.com>
	<20170518170745.Horde.vm9Gwi7fpRtat4Aj1E4zK45@brian.zuver.net.au>
Message-ID: <dbc21abf-4236-175a-ab33-cf28090ee576@redhat.com>

Sorry. What I meant is, that if we introduce this, we won't need to put 
the URL into the freemarker template itself, but instead put it to 
UrlBean. You're right that it's probably not here right now, so in your 
theme, you may need to hardcode it in freemarker theme itself at this 
moment.

Marek

On 18/05/17 09:07, Luke Robinson wrote:
> I did look at using UrlBean because I knew that 
> org.keycloak.forms.account.freemarker.model.UrlBean has 
> getApplicationsUrl() for use in the account theme but I couldn't find 
> anything in the org.keycloak.forms.login.freemarker.model.UrlBean 
> available to error.ftl that would give us what we are after.
>
> We're using RHSSO 7.0 (moving to 7.1 shortly) so things may have 
> changed since 1.9.8 / 2.5.5 but having a quick skim of the code in 
> master now I expect that this is still the case.
>
> Luke
>
>
> Quoting Marek Posolda <mposolda at redhat.com>:
>
>> On 18/05/17 03:26, luke at anotherrobbo.com wrote:
>>> For what it's worth, option 3 is similar to what we have implemented
>>> in our theme's error.ftl.
>>>
>>> Our main use case was for expired email confirmation / password reset
>>> links (we'd really like to see something done with
>>> https://issues.jboss.org/browse/KEYCLOAK-3631 so we can increase our
>>> limits past the SSO idle time but that's another issue!)
>> Good news for you. We introduced action tokens recently and it's in 
>> latest master. This introduces separate timeout for admin actions 
>> (among other things). In other words, your use-case from 
>> KEYCLOAK-3631 should be already possible with latest master and will 
>> be in 3.2.0 release.
>>>
>>> We've hardcoded the url (${msg("attemptLogin", "/auth/realms/" +
>>> realm.name + "/account/applications")}), it would certainly be nice to
>>> have a better way of doing this so the theme doesn't need to know the
>>> URL?
>> Yes, we already have URLBean, which is used to abstracts the URL 
>> creation logic from the freemarker template itself.
>>
>> Marek
>>>
>>> Cheers,
>>>
>>> Luke
>>>
>>> Quoting Marek Posolda <mposolda at redhat.com>:
>>>
>>>> Maybe yes.
>>>>
>>>> There is also the case when the link of login page can be copy/pasted
>>>> somehow and opened in new browser. The KC_RESTART cookie then also 
>>>> won't
>>>> be visible. But this really looks like corner case...
>>>>
>>>> Maybe we can have the combination of 1 and 3? Have the cookie 
>>>> persistent
>>>> and show the page with account management link just if KC_RESTART 
>>>> cookie
>>>> is really unavailable.
>>>>
>>>> Marek
>>>>
>>>> On 17/05/17 15:09, Schuster Sebastian (INST/ESY1) wrote:
>>>>> Wouldn't 1) be a good option as browser restarts are the vast
>>>>> majority compared to history deletion?
>>>>> Even our very restrictive company directives don't clear the
>>>>> browser history on exit while messing around
>>>>> with a lot of my other browser settings...
>>>>>
>>>>> Best regards,
>>>>> Sebastian
>>>>>
>>>>> Mit freundlichen Gr??en / Best regards
>>>>>
>>>>>   Sebastian Schuster
>>>>>
>>>>> Engineering and Support (INST/ESY1)
>>>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>>>> Berlin | GERMANY | www.bosch-si.com
>>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>>>> Sebastian.Schuster at bosch-si.com
>>>>>
>>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 
>>>>> 148411 B
>>>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>>>> bounces at lists.jboss.org] On Behalf Of Marek Posolda
>>>>>> Sent: Mittwoch, 17. Mai 2017 11:36
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Subject: [keycloak-dev] Provide a Link to go Back to The
>>>>>> Application on a Timeout
>>>>>>
>>>>>> We have the issue that after session timeout, the page "An error
>>>>>> occurred, please
>>>>>> login again through your application." can be shown.
>>>>>> This is even worse when there is no link to go back to the
>>>>>> application as users
>>>>>> might be confused what to do. Details in
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-4016 .
>>>>>>
>>>>>> This is already handled in many cases as when authentication
>>>>>> session is expired, it
>>>>>> is always restarted from the KC_RESTART cookie.
>>>>>>
>>>>>> However there are still cases when this error is shown, which is
>>>>>> when the restart
>>>>>> from the cookie failed. This can happen when browser history
>>>>>> (including cookies)
>>>>>> was cleared or when user restarted the browser (as the KC_RESTART
>>>>>> cookie is not
>>>>>> persistent).
>>>>>>
>>>>>> Some possibilities to solve:
>>>>>> 1) Make the KC_RESTART cookie persistent. That will handle 
>>>>>> browser restart,
>>>>>> however it won't handle the case when browser history is deleted
>>>>>>
>>>>>> 2) Add client-id to every link as Stefan Baust suggested. Then we
>>>>>> can add the link
>>>>>> to client base uri on the page. This is more work with the
>>>>>> possibility of error-prone
>>>>>> if we miss to add the client-id to some link.
>>>>>> Also we will be able to provide the link just if client has 
>>>>>> "base-uri"
>>>>>> configured.
>>>>>>
>>>>>> 3) Add the link to the account management application page. After
>>>>>> successful
>>>>>> login will be shown list of applications in account management and
>>>>>> user can click
>>>>>> to his favourite application. Message would need to be changed to
>>>>>> something like
>>>>>> "An error occurred, please login again through your application or
>>>>>> go to the
>>>>>> <link>list of applications<link> and select your application 
>>>>>> after login."
>>>>>>
>>>>>> My preference is 3, 2, 1. WDYT? Any other ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Marek
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>


From sthorger at redhat.com  Thu May 18 03:35:44 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 May 2017 09:35:44 +0200
Subject: [keycloak-dev] add-user-keycloak.bat broken?
In-Reply-To: <CAJgngAdEDnhssXHXJSYA9P6KThJ6k2wwEVDsEs8ZWWrQeyKHbg@mail.gmail.com>
References: <dccadd17-50aa-11a7-7c4a-be703248e490@redhat.com>
	<CAJgngAdEDnhssXHXJSYA9P6KThJ6k2wwEVDsEs8ZWWrQeyKHbg@mail.gmail.com>
Message-ID: <CAJgngAfS_7DftGuCQ1z9JtMLMdbKjbDF12wBZXv4m33p_iROtw@mail.gmail.com>

Fix on its way https://github.com/keycloak/keycloak/pull/4142

On 18 May 2017 at 08:49, Stian Thorgersen <sthorger at redhat.com> wrote:

> add-user-keycloak.sh broken as well and it's probably my fault.
>
> https://issues.jboss.org/browse/KEYCLOAK-4921
>
> On 17 May 2017 at 21:04, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> I don't have time to look into it right now, but it's not working on my
>> Windows box.
>>
>> Hoping someone touched this recently and might know what the problem
>> is?  Biggest clue is that it spits out "null" instead of the usual "file
>> created" message.
>>
>> c:\GitHub\keycloak\distribution\server-dist\target\keycloak-
>> 3.2.0.CR1-SNAPSHOT\bin>add-user-keycloak
>> -u admin -p admin
>> null
>> Press any key to continue . . .
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From thomas.raehalme at aitiofinland.com  Thu May 18 04:24:01 2017
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 18 May 2017 11:24:01 +0300
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
	a Timeout
In-Reply-To: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
Message-ID: <CAPyAMoa1_AWpijLQHMUyidwutk0_X5eNZJ1BCRbZt7BuXUZkZg@mail.gmail.com>

Hi!

On May 17, 2017 14:28, "Marek Posolda" <mposolda at redhat.com> wrote:

We have the issue that after session timeout, the page "An error
occurred, please login again through your application." can be shown.
This is even worse when there is no link to go back to the application
as users might be confused what to do. Details in
https://issues.jboss.org/browse/KEYCLOAK-4016 .
......
Some possibilities to solve:
1) Make the KC_RESTART cookie persistent. That will handle browser
restart, however it won't handle the case when browser history is deleted

2) Add client-id to every link as Stefan Baust suggested. Then we can
add the link to client base uri on the page. This is more work with the
possibility of error-prone if we miss to add the client-id to some link.
Also we will be able to provide the link just if client has "base-uri"
configured.


I'd appreciate option 2 as it is more user friendly because that's where
she came from. It's also more foolproof than option 1 where the browser
history can be deleted. If the base-uri is missing (probably by a
mistake?), maybe then fallback to the account management application.

Best regards,
Thomas

From psilva at redhat.com  Thu May 18 08:34:23 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 18 May 2017 09:34:23 -0300
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
Message-ID: <CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>

We are really missing examples and documentation to Spring Boot Adapter.
Will write an example/template and review docs.

Can give you an answer right now because I've tested authz with spring boot
only a very few times. But you should not get this error at all.

Will have something today.



On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <
crafton.williams at qut.edu.au> wrote:

> Hi All:
>
> I?m trying to configure a basic springboot app using the springboot
> keycloak adapter. Authentication works as expected but I?m a bit confused
> as to how to configure the policy enforcer in yaml. The documentation shows
> configuring the policy-enforcer as a json document however the springboot
> config implies a only policy-enforcer-config. In any case, I did try the
> json doc but it wasn?t picked up by the adapter.
>
> I?m using 3.0.0.Final and tried the following in my yaml file(omitted the
> rest of the path info for brevity):
>
> Policy-enforcer-config:
>   Enforcement-mode: ENFORCING
>   paths:
>
>   *   name: blah
>
> The exception I got was:
>
> org.springframework.context.ApplicationContextException: Unable to start
> embedded container; nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'tomcatEmbeddedServletContainerFactory'
> defined in class path resource [org/springframework/boot/
> autoconfigure/web/EmbeddedServletContainerAutoCo
> nfiguration$EmbeddedTomcat.class]: Initialization of bean failed; nested
> exception is org.springframework.beans.factory.
> UnsatisfiedDependencyException: Error creating bean with name
> 'org.keycloak.adapters.springboot.KeycloakSpringBootConfiguration':
> Unsatisfied dependency expressed through method '
> setKeycloakSpringBootProperties' parameter 0; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'keycloak-org.keycloak.adapters.springboot.KeycloakSpringBootProperties':
> Could not bind properties to KeycloakSpringBootProperties (prefix=keycloak,
> ignoreInvalidFields=false, ignoreUnknownFields=false,
> ignoreNestedProperties=false); nested exception is
> org.springframework.beans.InvalidPropertyException: Invalid property
> 'policyEnforcerConfig.paths[0]' of bean class [org.keycloak.adapters.
> springboot.KeycloakSpringBootProperties]: Illegal attempt to get property
> 'paths' threw exception; nested exception is java.lang.
> UnsupportedOperationException
>
> Is there an example project somewhere that can guide me in configuring the
> policy enforcer for the springboot adapter?
>
> Cheers,
>
> Crafton
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Thu May 18 08:35:41 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 18 May 2017 09:35:41 -0300
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
Message-ID: <CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>

Btw, you are not the first one asking for more details about Spring boot
integration. That is why I want to review this ....

On Thu, May 18, 2017 at 9:34 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> We are really missing examples and documentation to Spring Boot Adapter.
> Will write an example/template and review docs.
>
> Can give you an answer right now because I've tested authz with spring
> boot only a very few times. But you should not get this error at all.
>
> Will have something today.
>
>
>
> On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <
> crafton.williams at qut.edu.au> wrote:
>
>> Hi All:
>>
>> I?m trying to configure a basic springboot app using the springboot
>> keycloak adapter. Authentication works as expected but I?m a bit confused
>> as to how to configure the policy enforcer in yaml. The documentation shows
>> configuring the policy-enforcer as a json document however the springboot
>> config implies a only policy-enforcer-config. In any case, I did try the
>> json doc but it wasn?t picked up by the adapter.
>>
>> I?m using 3.0.0.Final and tried the following in my yaml file(omitted the
>> rest of the path info for brevity):
>>
>> Policy-enforcer-config:
>>   Enforcement-mode: ENFORCING
>>   paths:
>>
>>   *   name: blah
>>
>> The exception I got was:
>>
>> org.springframework.context.ApplicationContextException: Unable to start
>> embedded container; nested exception is org.springframework.beans.factory.BeanCreationException:
>> Error creating bean with name 'tomcatEmbeddedServletContainerFactory'
>> defined in class path resource [org/springframework/boot/auto
>> configure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]:
>> Initialization of bean failed; nested exception is
>> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
>> creating bean with name 'org.keycloak.adapters.springb
>> oot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed
>> through method 'setKeycloakSpringBootProperties' parameter 0; nested
>> exception is org.springframework.beans.factory.BeanCreationException:
>> Error creating bean with name 'keycloak-org.keycloak.adapter
>> s.springboot.KeycloakSpringBootProperties': Could not bind properties to
>> KeycloakSpringBootProperties (prefix=keycloak, ignoreInvalidFields=false,
>> ignoreUnknownFields=false, ignoreNestedProperties=false); nested exception
>> is org.springframework.beans.InvalidPropertyException: Invalid property
>> 'policyEnforcerConfig.paths[0]' of bean class
>> [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]: Illegal
>> attempt to get property 'paths' threw exception; nested exception is
>> java.lang.UnsupportedOperationException
>>
>> Is there an example project somewhere that can guide me in configuring
>> the policy enforcer for the springboot adapter?
>>
>> Cheers,
>>
>> Crafton
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bruno at abstractj.org  Thu May 18 12:57:23 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 May 2017 13:57:23 -0300
Subject: [keycloak-dev] Branches for the quickstarts
Message-ID: <20170518165723.GA21137@abstractj.org>

While working today on the fix of some quickstarts. I'm
considering to create a separated branch only for stable versions of the
quickstarts.

In this way 'master' would be used only for development based on the
latest bits from Keycloak repo. And 3.1.x, to the latest stable
release on Maven central.

Does it make any sense?

--

abstractj

From sblanc at redhat.com  Thu May 18 13:15:31 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 18 May 2017 17:15:31 +0000
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <20170518165723.GA21137@abstractj.org>
References: <20170518165723.GA21137@abstractj.org>
Message-ID: <CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>

We should also consider the opposite : master is the stable released
version and a branch for development . I already had confused people
downloading KC server and cloning the QuickStarts and expecting it to work.
But tbh I do not have a string opinion on that.
Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a ?crit :

> While working today on the fix of some quickstarts. I'm
> considering to create a separated branch only for stable versions of the
> quickstarts.
>
> In this way 'master' would be used only for development based on the
> latest bits from Keycloak repo. And 3.1.x, to the latest stable
> release on Maven central.
>
> Does it make any sense?
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Thu May 18 13:59:59 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 May 2017 17:59:59 +0000
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
Message-ID: <CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>

Hmmm I'm not sure about that. That would be the completely opposite of what
we already do to any repository today. If people want the stable release of
the quickstarts they could just get 3.x or download the zip files, nope?

On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> We should also consider the opposite : master is the stable released
> version and a branch for development . I already had confused people
> downloading KC server and cloning the QuickStarts and expecting it to work.
> But tbh I do not have a string opinion on that.
> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
> ?crit :
>
>> While working today on the fix of some quickstarts. I'm
>> considering to create a separated branch only for stable versions of the
>> quickstarts.
>>
>> In this way 'master' would be used only for development based on the
>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>> release on Maven central.
>>
>> Does it make any sense?
>>
>> --
>>
>> abstractj
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From ssilvert at redhat.com  Thu May 18 14:59:10 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 May 2017 14:59:10 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
Message-ID: <ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>

What we really need for the quickstarts is something Bill has been 
talking about for a long time.

It's a bundle of Keycloak and examples that just boots up and works.  
Otherwise, the quickstarts are way too hard to get running.  Nobody 
wants to spend 2 or 3 hours on a "quickstart". That's what I had to do 
recently and I already know what's going on.  I hate to think about what 
someone new to Keycloak needs to go through just to see an example.

This doesn't have to mean that everything runs in the same WildFly 
instance like the old demo dist.  The problem with that was that it 
didn't show Keycloak set up as a stand-alone server.

What you need is a single bundle that lets you run Keycloak standalone 
and a standalone app server.  I see a couple of ways to do it:
1) Use domain mode where you get a domain controller, Keycloak instance, 
and app server instance all in the same JVM.
2) Use two separate server configs and run in two JVM's.

I think #2 is the best.  The Keycloak instance runs on port 8180 and the 
app server runs on 8080.  You only need one download of 
WildFly/Keycloak, but you package it with two configs.  So you have:
/bin
/modules
/domain (don't actually need this one)
/standalone
/keycloak

To run Keycloak (preloaded with quickstart realm):
 > standalone --server-config=keycloak 
-Djboss.socket.binding.port-offset=100

To run app server (preloaded with quickstart apps):
 > standalone



On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
> Hmmm I'm not sure about that. That would be the completely opposite of what
> we already do to any repository today. If people want the stable release of
> the quickstarts they could just get 3.x or download the zip files, nope?
>
> On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> We should also consider the opposite : master is the stable released
>> version and a branch for development . I already had confused people
>> downloading KC server and cloning the QuickStarts and expecting it to work.
>> But tbh I do not have a string opinion on that.
>> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
>> ?crit :
>>
>>> While working today on the fix of some quickstarts. I'm
>>> considering to create a separated branch only for stable versions of the
>>> quickstarts.
>>>
>>> In this way 'master' would be used only for development based on the
>>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>>> release on Maven central.
>>>
>>> Does it make any sense?
>>>
>>> --
>>>
>>> abstractj
>>>
>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Thu May 18 15:57:48 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 May 2017 15:57:48 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
Message-ID: <1b8ce6bf-83dd-b9de-75d1-f92f26c7f717@redhat.com>

On 5/18/2017 2:59 PM, Stan Silvert wrote:
> What we really need for the quickstarts is something Bill has been 
> talking about for a long time.
>
> It's a bundle of Keycloak and examples that just boots up and works.  
> Otherwise, the quickstarts are way too hard to get running.  Nobody 
> wants to spend 2 or 3 hours on a "quickstart". That's what I had to do 
> recently and I already know what's going on.  I hate to think about 
> what someone new to Keycloak needs to go through just to see an example.
>
> This doesn't have to mean that everything runs in the same WildFly 
> instance like the old demo dist.  The problem with that was that it 
> didn't show Keycloak set up as a stand-alone server.
>
> What you need is a single bundle that lets you run Keycloak standalone 
> and a standalone app server.  I see a couple of ways to do it:
> 1) Use domain mode where you get a domain controller, Keycloak 
> instance, and app server instance all in the same JVM.
> 2) Use two separate server configs and run in two JVM's.
>
> I think #2 is the best.  The Keycloak instance runs on port 8180 and 
> the app server runs on 8080.  You only need one download of 
> WildFly/Keycloak, but you package it with two configs.  So you have:
> /bin
> /modules
> /domain (don't actually need this one)
> /standalone
> /keycloak
>
> To run Keycloak (preloaded with quickstart realm):
> > standalone --server-config=keycloak 
> -Djboss.socket.binding.port-offset=100
Oops.  That's wrong.  It should look like this:
 > standalone -Djboss.server.base.dir=keycloak 
-Djboss.socket.binding.port-offset=100
>
> To run app server (preloaded with quickstart apps):
> > standalone
>
>
>
> On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>> Hmmm I'm not sure about that. That would be the completely opposite 
>> of what
>> we already do to any repository today. If people want the stable 
>> release of
>> the quickstarts they could just get 3.x or download the zip files, nope?
>>
>> On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com> 
>> wrote:
>>
>>> We should also consider the opposite : master is the stable released
>>> version and a branch for development . I already had confused people
>>> downloading KC server and cloning the QuickStarts and expecting it 
>>> to work.
>>> But tbh I do not have a string opinion on that.
>>> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
>>> ?crit :
>>>
>>>> While working today on the fix of some quickstarts. I'm
>>>> considering to create a separated branch only for stable versions 
>>>> of the
>>>> quickstarts.
>>>>
>>>> In this way 'master' would be used only for development based on the
>>>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>>>> release on Maven central.
>>>>
>>>> Does it make any sense?
>>>>
>>>> -- 
>>>>
>>>> abstractj
>>>>
>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From psilva at redhat.com  Thu May 18 19:33:02 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 18 May 2017 20:33:02 -0300
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
	<CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>
Message-ID: <CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>

I've sent a PR [1] with a quickstart for Spring Boot. Will work with some
more examples covering specific features of Keycloak Authorization Services.

Please let me know what you think about it. It is basically a Spring Boot
Web application protected with simple fine-grained permissions.

[1] https://github.com/keycloak/keycloak-quickstarts/pull/26

Regards.
Pedro Igor


On Thu, May 18, 2017 at 9:35 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Btw, you are not the first one asking for more details about Spring boot
> integration. That is why I want to review this ....
>
> On Thu, May 18, 2017 at 9:34 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> We are really missing examples and documentation to Spring Boot Adapter.
>> Will write an example/template and review docs.
>>
>> Can give you an answer right now because I've tested authz with spring
>> boot only a very few times. But you should not get this error at all.
>>
>> Will have something today.
>>
>>
>>
>> On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <
>> crafton.williams at qut.edu.au> wrote:
>>
>>> Hi All:
>>>
>>> I?m trying to configure a basic springboot app using the springboot
>>> keycloak adapter. Authentication works as expected but I?m a bit confused
>>> as to how to configure the policy enforcer in yaml. The documentation shows
>>> configuring the policy-enforcer as a json document however the springboot
>>> config implies a only policy-enforcer-config. In any case, I did try the
>>> json doc but it wasn?t picked up by the adapter.
>>>
>>> I?m using 3.0.0.Final and tried the following in my yaml file(omitted
>>> the rest of the path info for brevity):
>>>
>>> Policy-enforcer-config:
>>>   Enforcement-mode: ENFORCING
>>>   paths:
>>>
>>>   *   name: blah
>>>
>>> The exception I got was:
>>>
>>> org.springframework.context.ApplicationContextException: Unable to
>>> start embedded container; nested exception is org.springframework.beans.factory.BeanCreationException:
>>> Error creating bean with name 'tomcatEmbeddedServletContainerFactory'
>>> defined in class path resource [org/springframework/boot/auto
>>> configure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]:
>>> Initialization of bean failed; nested exception is
>>> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
>>> creating bean with name 'org.keycloak.adapters.springb
>>> oot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed
>>> through method 'setKeycloakSpringBootProperties' parameter 0; nested
>>> exception is org.springframework.beans.factory.BeanCreationException:
>>> Error creating bean with name 'keycloak-org.keycloak.adapter
>>> s.springboot.KeycloakSpringBootProperties': Could not bind properties
>>> to KeycloakSpringBootProperties (prefix=keycloak,
>>> ignoreInvalidFields=false, ignoreUnknownFields=false,
>>> ignoreNestedProperties=false); nested exception is
>>> org.springframework.beans.InvalidPropertyException: Invalid property
>>> 'policyEnforcerConfig.paths[0]' of bean class
>>> [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]:
>>> Illegal attempt to get property 'paths' threw exception; nested exception
>>> is java.lang.UnsupportedOperationException
>>>
>>> Is there an example project somewhere that can guide me in configuring
>>> the policy enforcer for the springboot adapter?
>>>
>>> Cheers,
>>>
>>> Crafton
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From bruno at abstractj.org  Thu May 18 19:41:14 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 May 2017 23:41:14 +0000
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
Message-ID: <CAM5SUC6OvLHBYUeL_tda-rDhdLHQFm7OKqN1y6wpVf9vhYdKJw@mail.gmail.com>

I truly feel that we are talking about completely different things.

But you can add your considerations to this Jira:
https://issues.jboss.org/browse/KEYCLOAK-3577

On Thu, May 18, 2017, 4:58 PM Stan Silvert <ssilvert at redhat.com> wrote:

> What we really need for the quickstarts is something Bill has been
> talking about for a long time.
>
> It's a bundle of Keycloak and examples that just boots up and works.
> Otherwise, the quickstarts are way too hard to get running.  Nobody
> wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
> recently and I already know what's going on.  I hate to think about what
> someone new to Keycloak needs to go through just to see an example.
>
> This doesn't have to mean that everything runs in the same WildFly
> instance like the old demo dist.  The problem with that was that it
> didn't show Keycloak set up as a stand-alone server.
>
> What you need is a single bundle that lets you run Keycloak standalone
> and a standalone app server.  I see a couple of ways to do it:
> 1) Use domain mode where you get a domain controller, Keycloak instance,
> and app server instance all in the same JVM.
> 2) Use two separate server configs and run in two JVM's.
>
> I think #2 is the best.  The Keycloak instance runs on port 8180 and the
> app server runs on 8080.  You only need one download of
> WildFly/Keycloak, but you package it with two configs.  So you have:
> /bin
> /modules
> /domain (don't actually need this one)
> /standalone
> /keycloak
>
> To run Keycloak (preloaded with quickstart realm):
>  > standalone --server-config=keycloak
> -Djboss.socket.binding.port-offset=100
>
> To run app server (preloaded with quickstart apps):
>  > standalone
>
>
>
> On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
> > Hmmm I'm not sure about that. That would be the completely opposite of
> what
> > we already do to any repository today. If people want the stable release
> of
> > the quickstarts they could just get 3.x or download the zip files, nope?
> >
> > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com>
> wrote:
> >
> >> We should also consider the opposite : master is the stable released
> >> version and a branch for development . I already had confused people
> >> downloading KC server and cloning the QuickStarts and expecting it to
> work.
> >> But tbh I do not have a string opinion on that.
> >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
> >> ?crit :
> >>
> >>> While working today on the fix of some quickstarts. I'm
> >>> considering to create a separated branch only for stable versions of
> the
> >>> quickstarts.
> >>>
> >>> In this way 'master' would be used only for development based on the
> >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
> >>> release on Maven central.
> >>>
> >>> Does it make any sense?
> >>>
> >>> --
> >>>
> >>> abstractj
> >>>
> >> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From crafton.williams at qut.edu.au  Thu May 18 21:19:23 2017
From: crafton.williams at qut.edu.au (Crafton Williams)
Date: Fri, 19 May 2017 01:19:23 +0000
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
	<CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>,
	<CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>
Message-ID: <SY3PR01MB0827A7BC808199ADB777DF20AFE50@SY3PR01MB0827.ausprd01.prod.outlook.com>

Hi Pedro:

This is a huge help, thanks!

A few questions though...is this is the only way to implement Authz with keyclaok and springboot? Is it possible to use the keycloak-spring-boot-adapter along with keycloak.json configured as a policy enforcer? I found it to be a very nice way of separating the security concern from the code itself.


Cheers,

Crafton


From: Pedro Igor Silva<mailto:psilva at redhat.com>
Sent: Friday, 19 May 2017 9:33 AM
To: Crafton Williams<mailto:crafton.williams at qut.edu.au>
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Authorization with Springboot adapter

I've sent a PR [1] with a quickstart for Spring Boot. Will work with some more examples covering specific features of Keycloak Authorization Services.

Please let me know what you think about it. It is basically a Spring Boot Web application protected with simple fine-grained permissions.

[1] https://github.com/keycloak/keycloak-quickstarts/pull/26

Regards.
Pedro Igor


On Thu, May 18, 2017 at 9:35 AM, Pedro Igor Silva <psilva at redhat.com<mailto:psilva at redhat.com>> wrote:
Btw, you are not the first one asking for more details about Spring boot integration. That is why I want to review this ....

On Thu, May 18, 2017 at 9:34 AM, Pedro Igor Silva <psilva at redhat.com<mailto:psilva at redhat.com>> wrote:
We are really missing examples and documentation to Spring Boot Adapter. Will write an example/template and review docs.

Can give you an answer right now because I've tested authz with spring boot only a very few times. But you should not get this error at all.

Will have something today.



On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <crafton.williams at qut.edu.au<mailto:crafton.williams at qut.edu.au>> wrote:
Hi All:

I?m trying to configure a basic springboot app using the springboot keycloak adapter. Authentication works as expected but I?m a bit confused as to how to configure the policy enforcer in yaml. The documentation shows configuring the policy-enforcer as a json document however the springboot config implies a only policy-enforcer-config. In any case, I did try the json doc but it wasn?t picked up by the adapter.

I?m using 3.0.0.Final and tried the following in my yaml file(omitted the rest of the path info for brevity):

Policy-enforcer-config:
  Enforcement-mode: ENFORCING
  paths:

  *   name: blah

The exception I got was:

org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'tomcatEmbeddedServletContainerFactory' defined in class path resource [org/springframework/boot/autoconfigure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]: Initialization of bean failed; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.keycloak.adapters.springboot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed through method 'setKeycloakSpringBootProperties' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'keycloak-org.keycloak.adapters.springboot.KeycloakSpringBootProperties': Could not bind properties to KeycloakSpringBootProperties (prefix=keycloak, ignoreInvalidFields=false, ignoreUnknownFields=false, ignoreNestedProperties=false); nested exception is org.springframework.beans.InvalidPropertyException: Invalid property 'policyEnforcerConfig.paths[0]' of bean class [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]: Illegal attempt to get property 'paths' threw exception; nested exception is java.lang.UnsupportedOperationException

Is there an example project somewhere that can guide me in configuring the policy enforcer for the springboot adapter?

Cheers,

Crafton

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev





From srossillo at smartling.com  Thu May 18 21:48:31 2017
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 19 May 2017 01:48:31 +0000
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
	<CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>
	<CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>
Message-ID: <CALAqdu_DsOwvLFJPa6F=UwYeLr1q4oywNTxFx5eyEdJwUnyzOw@mail.gmail.com>

IMO, and I don't have time to do this right now, the Spring Boot adapter
should be rewritten simply as a way to configure the Spring Security
adapter via Spring Boot conventions.
On Thu, May 18, 2017 at 9:29 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> I've sent a PR [1] with a quickstart for Spring Boot. Will work with some
> more examples covering specific features of Keycloak Authorization
> Services.
>
> Please let me know what you think about it. It is basically a Spring Boot
> Web application protected with simple fine-grained permissions.
>
> [1] https://github.com/keycloak/keycloak-quickstarts/pull/26
>
> Regards.
> Pedro Igor
>
>
> On Thu, May 18, 2017 at 9:35 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
> > Btw, you are not the first one asking for more details about Spring boot
> > integration. That is why I want to review this ....
> >
> > On Thu, May 18, 2017 at 9:34 AM, Pedro Igor Silva <psilva at redhat.com>
> > wrote:
> >
> >> We are really missing examples and documentation to Spring Boot Adapter.
> >> Will write an example/template and review docs.
> >>
> >> Can give you an answer right now because I've tested authz with spring
> >> boot only a very few times. But you should not get this error at all.
> >>
> >> Will have something today.
> >>
> >>
> >>
> >> On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <
> >> crafton.williams at qut.edu.au> wrote:
> >>
> >>> Hi All:
> >>>
> >>> I?m trying to configure a basic springboot app using the springboot
> >>> keycloak adapter. Authentication works as expected but I?m a bit
> confused
> >>> as to how to configure the policy enforcer in yaml. The documentation
> shows
> >>> configuring the policy-enforcer as a json document however the
> springboot
> >>> config implies a only policy-enforcer-config. In any case, I did try
> the
> >>> json doc but it wasn?t picked up by the adapter.
> >>>
> >>> I?m using 3.0.0.Final and tried the following in my yaml file(omitted
> >>> the rest of the path info for brevity):
> >>>
> >>> Policy-enforcer-config:
> >>>   Enforcement-mode: ENFORCING
> >>>   paths:
> >>>
> >>>   *   name: blah
> >>>
> >>> The exception I got was:
> >>>
> >>> org.springframework.context.ApplicationContextException: Unable to
> >>> start embedded container; nested exception is
> org.springframework.beans.factory.BeanCreationException:
> >>> Error creating bean with name 'tomcatEmbeddedServletContainerFactory'
> >>> defined in class path resource [org/springframework/boot/auto
> >>>
> configure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]:
> >>> Initialization of bean failed; nested exception is
> >>> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> >>> creating bean with name 'org.keycloak.adapters.springb
> >>> oot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed
> >>> through method 'setKeycloakSpringBootProperties' parameter 0; nested
> >>> exception is org.springframework.beans.factory.BeanCreationException:
> >>> Error creating bean with name 'keycloak-org.keycloak.adapter
> >>> s.springboot.KeycloakSpringBootProperties': Could not bind properties
> >>> to KeycloakSpringBootProperties (prefix=keycloak,
> >>> ignoreInvalidFields=false, ignoreUnknownFields=false,
> >>> ignoreNestedProperties=false); nested exception is
> >>> org.springframework.beans.InvalidPropertyException: Invalid property
> >>> 'policyEnforcerConfig.paths[0]' of bean class
> >>> [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]:
> >>> Illegal attempt to get property 'paths' threw exception; nested
> exception
> >>> is java.lang.UnsupportedOperationException
> >>>
> >>> Is there an example project somewhere that can guide me in configuring
> >>> the policy enforcer for the springboot adapter?
> >>>
> >>> Cheers,
> >>>
> >>> Crafton
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Fri May 19 03:03:58 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 09:03:58 +0200
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAM5SUC6OvLHBYUeL_tda-rDhdLHQFm7OKqN1y6wpVf9vhYdKJw@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAM5SUC6OvLHBYUeL_tda-rDhdLHQFm7OKqN1y6wpVf9vhYdKJw@mail.gmail.com>
Message-ID: <CAJgngAfP9Et-LRPjEZ=Mz_gBXz9uu0iUp7+hrDtY-QsOJ0UOtg@mail.gmail.com>

The default branch regardless what it's called should be the branch users
should use for the latest Keycloak release. The reasoning for that is that
a user when trying the quickstarts should not have to do a clone then
checkout another branch.

We could either go with:

1. master (default branch) and dev
2. latest (default branch) and master

My vote goes to option 2.

On 19 May 2017 at 01:41, Bruno Oliveira <bruno at abstractj.org> wrote:

> I truly feel that we are talking about completely different things.
>
> But you can add your considerations to this Jira:
> https://issues.jboss.org/browse/KEYCLOAK-3577
>
> On Thu, May 18, 2017, 4:58 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
> > What we really need for the quickstarts is something Bill has been
> > talking about for a long time.
> >
> > It's a bundle of Keycloak and examples that just boots up and works.
> > Otherwise, the quickstarts are way too hard to get running.  Nobody
> > wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
> > recently and I already know what's going on.  I hate to think about what
> > someone new to Keycloak needs to go through just to see an example.
> >
> > This doesn't have to mean that everything runs in the same WildFly
> > instance like the old demo dist.  The problem with that was that it
> > didn't show Keycloak set up as a stand-alone server.
> >
> > What you need is a single bundle that lets you run Keycloak standalone
> > and a standalone app server.  I see a couple of ways to do it:
> > 1) Use domain mode where you get a domain controller, Keycloak instance,
> > and app server instance all in the same JVM.
> > 2) Use two separate server configs and run in two JVM's.
> >
> > I think #2 is the best.  The Keycloak instance runs on port 8180 and the
> > app server runs on 8080.  You only need one download of
> > WildFly/Keycloak, but you package it with two configs.  So you have:
> > /bin
> > /modules
> > /domain (don't actually need this one)
> > /standalone
> > /keycloak
> >
> > To run Keycloak (preloaded with quickstart realm):
> >  > standalone --server-config=keycloak
> > -Djboss.socket.binding.port-offset=100
> >
> > To run app server (preloaded with quickstart apps):
> >  > standalone
> >
> >
> >
> > On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
> > > Hmmm I'm not sure about that. That would be the completely opposite of
> > what
> > > we already do to any repository today. If people want the stable
> release
> > of
> > > the quickstarts they could just get 3.x or download the zip files,
> nope?
> > >
> > > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com>
> > wrote:
> > >
> > >> We should also consider the opposite : master is the stable released
> > >> version and a branch for development . I already had confused people
> > >> downloading KC server and cloning the QuickStarts and expecting it to
> > work.
> > >> But tbh I do not have a string opinion on that.
> > >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
> > >> ?crit :
> > >>
> > >>> While working today on the fix of some quickstarts. I'm
> > >>> considering to create a separated branch only for stable versions of
> > the
> > >>> quickstarts.
> > >>>
> > >>> In this way 'master' would be used only for development based on the
> > >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
> > >>> release on Maven central.
> > >>>
> > >>> Does it make any sense?
> > >>>
> > >>> --
> > >>>
> > >>> abstractj
> > >>>
> > >> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri May 19 03:06:38 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 09:06:38 +0200
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
Message-ID: <CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>

That's rather off topic. Quickstarts is one thing and a demo/example is
another thing. Quickstarts is supposed to show you how to get started with
securing your apps with Keycloak. What you are proposing is a nice option
on just trying out Keycloak, but it doesn't really help users getting
started properly with securing their apps.

On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com> wrote:

> What we really need for the quickstarts is something Bill has been
> talking about for a long time.
>
> It's a bundle of Keycloak and examples that just boots up and works.
> Otherwise, the quickstarts are way too hard to get running.  Nobody
> wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
> recently and I already know what's going on.  I hate to think about what
> someone new to Keycloak needs to go through just to see an example.
>
> This doesn't have to mean that everything runs in the same WildFly
> instance like the old demo dist.  The problem with that was that it
> didn't show Keycloak set up as a stand-alone server.
>
> What you need is a single bundle that lets you run Keycloak standalone
> and a standalone app server.  I see a couple of ways to do it:
> 1) Use domain mode where you get a domain controller, Keycloak instance,
> and app server instance all in the same JVM.
> 2) Use two separate server configs and run in two JVM's.
>
> I think #2 is the best.  The Keycloak instance runs on port 8180 and the
> app server runs on 8080.  You only need one download of
> WildFly/Keycloak, but you package it with two configs.  So you have:
> /bin
> /modules
> /domain (don't actually need this one)
> /standalone
> /keycloak
>
> To run Keycloak (preloaded with quickstart realm):
>  > standalone --server-config=keycloak
> -Djboss.socket.binding.port-offset=100
>
> To run app server (preloaded with quickstart apps):
>  > standalone
>
>
>
> On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
> > Hmmm I'm not sure about that. That would be the completely opposite of
> what
> > we already do to any repository today. If people want the stable release
> of
> > the quickstarts they could just get 3.x or download the zip files, nope?
> >
> > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com>
> wrote:
> >
> >> We should also consider the opposite : master is the stable released
> >> version and a branch for development . I already had confused people
> >> downloading KC server and cloning the QuickStarts and expecting it to
> work.
> >> But tbh I do not have a string opinion on that.
> >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
> >> ?crit :
> >>
> >>> While working today on the fix of some quickstarts. I'm
> >>> considering to create a separated branch only for stable versions of
> the
> >>> quickstarts.
> >>>
> >>> In this way 'master' would be used only for development based on the
> >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
> >>> release on Maven central.
> >>>
> >>> Does it make any sense?
> >>>
> >>> --
> >>>
> >>> abstractj
> >>>
> >> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri May 19 03:19:59 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 09:19:59 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
	a Timeout
In-Reply-To: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
Message-ID: <CAJgngAfB2tkGyUXjnjCDegJMeNobbZTVYGVsrjy8u9DJEBasAw@mail.gmail.com>

I don't like option 3. It's rather unlikely that's the app folks actually
want to go to in this case.

I don't think option 1 is a full solution either. KC_RESTART cookie may be
missing as you say, but it could also be overwritten by another client
login.

Can't we do option 2 in the code that redirects to the next step in the
flow? That way it's always there. We should also add to action tokens so an
invalid action token page can also display a link back to the app.

On 17 May 2017 at 11:36, Marek Posolda <mposolda at redhat.com> wrote:

> We have the issue that after session timeout, the page "An error
> occurred, please login again through your application." can be shown.
> This is even worse when there is no link to go back to the application
> as users might be confused what to do. Details in
> https://issues.jboss.org/browse/KEYCLOAK-4016 .
>
> This is already handled in many cases as when authentication session is
> expired, it is always restarted from the KC_RESTART cookie.
>
> However there are still cases when this error is shown, which is when
> the restart from the cookie failed. This can happen when browser history
> (including cookies) was cleared or when user restarted the browser (as
> the KC_RESTART cookie is not persistent).
>
> Some possibilities to solve:
> 1) Make the KC_RESTART cookie persistent. That will handle browser
> restart, however it won't handle the case when browser history is deleted
>
> 2) Add client-id to every link as Stefan Baust suggested. Then we can
> add the link to client base uri on the page. This is more work with the
> possibility of error-prone if we miss to add the client-id to some link.
> Also we will be able to provide the link just if client has "base-uri"
> configured.
>
> 3) Add the link to the account management application page. After
> successful login will be shown list of applications in account
> management and user can click to his favourite application. Message
> would need to be changed to something like "An error occurred, please
> login again through your application or go to the <link>list of
> applications<link> and select your application after login."
>
> My preference is 3, 2, 1. WDYT? Any other ideas?
>
> Thanks,
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Fri May 19 04:01:39 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 10:01:39 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <CAJgngAfB2tkGyUXjnjCDegJMeNobbZTVYGVsrjy8u9DJEBasAw@mail.gmail.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<CAJgngAfB2tkGyUXjnjCDegJMeNobbZTVYGVsrjy8u9DJEBasAw@mail.gmail.com>
Message-ID: <90470c8a-3313-d0e5-b355-9336dbd003f8@redhat.com>

On 19/05/17 09:19, Stian Thorgersen wrote:
> I don't like option 3. It's rather unlikely that's the app folks 
> actually want to go to in this case.
>
> I don't think option 1 is a full solution either. KC_RESTART cookie 
> may be missing as you say, but it could also be overwritten by another 
> client login.
I've figured another reason why it won't work that after restarted login 
is finished and you're redirected back to the app, the application would 
reject it due to incorrect oauth "state" . Was thinking about adding 
separate cookie just with client_id, but links are always more reliable 
then cookies though. So I will try option 2. Hopefully there is not so 
much places where this needs to be changed. Will try to handle in action 
tokens as well.

Marek

>
> Can't we do option 2 in the code that redirects to the next step in 
> the flow? That way it's always there. We should also add to action 
> tokens so an invalid action token page can also display a link back to 
> the app.
>
> On 17 May 2017 at 11:36, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     We have the issue that after session timeout, the page "An error
>     occurred, please login again through your application." can be shown.
>     This is even worse when there is no link to go back to the application
>     as users might be confused what to do. Details in
>     https://issues.jboss.org/browse/KEYCLOAK-4016
>     <https://issues.jboss.org/browse/KEYCLOAK-4016> .
>
>     This is already handled in many cases as when authentication
>     session is
>     expired, it is always restarted from the KC_RESTART cookie.
>
>     However there are still cases when this error is shown, which is when
>     the restart from the cookie failed. This can happen when browser
>     history
>     (including cookies) was cleared or when user restarted the browser (as
>     the KC_RESTART cookie is not persistent).
>
>     Some possibilities to solve:
>     1) Make the KC_RESTART cookie persistent. That will handle browser
>     restart, however it won't handle the case when browser history is
>     deleted
>
>     2) Add client-id to every link as Stefan Baust suggested. Then we can
>     add the link to client base uri on the page. This is more work
>     with the
>     possibility of error-prone if we miss to add the client-id to some
>     link.
>     Also we will be able to provide the link just if client has "base-uri"
>     configured.
>
>     3) Add the link to the account management application page. After
>     successful login will be shown list of applications in account
>     management and user can click to his favourite application. Message
>     would need to be changed to something like "An error occurred, please
>     login again through your application or go to the <link>list of
>     applications<link> and select your application after login."
>
>     My preference is 3, 2, 1. WDYT? Any other ideas?
>
>     Thanks,
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mposolda at redhat.com  Fri May 19 04:24:18 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 10:24:18 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
Message-ID: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>

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


From sthorger at redhat.com  Fri May 19 04:30:33 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 10:30:33 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
Message-ID: <CAJgngAc6n2wgNON2mDf2pW8aesMwRpe74why50jOFBqE__1HiQ@mail.gmail.com>

Why do you need a separate route.id param? Wouldn't it just rely on the
session_state being the same value as the authentication session cookie?

The cookie approach with our adapters seems sensible option. Not sure about
the approach of looking into the code/JWT as we can't rely on the load
balancer implementation. There's loads of them out there and we need a
solution that works regardless of the load balancer.

One option if possible is on demand replication of sessions. A session
lives in one DC until it's requested from another DC. That means if users
use only apps that can be sticked to a DC either by cookie or some other
mechanism (for example the app itself is replicated in all DCs) the session
won't be replicated. If/when a user hits a third party app or another app
that for some reason is directed to the other DC that session is fetched
from the other DC and replicated afterwards.


On 16 May 2017 at 10:19, Marek Posolda <mposolda at redhat.com> wrote:

> I was thinking about possibilities how to solve the issue with sticky
> sessions in backchannel requests. It seems that we need to support the
> scenarios, when backchannel requests won't be able to share the sticky
> session cookie with the browser. However in many cases it may be
> possible that backchannel requests can participate in the "sticky
> session", which will have great advantage for performance. Some thoughts:
>
> - OAuth code (the one used in code-to-token backchannel request) can be
> JWT signed by realm HMAC key. One of the claims in the code could be
> "route-id"
>
> - Refresh tokens will also contain "route-id" claim
>
> - Keycloak OIDC adapters will be able to read the "route-id" from the
> code and they will attach sticky session information to the single
> backchannel request. Hence the backchannel request will be able to
> participate in sticky session and will be properly routed by
> loadbalancer to the correct node. Same for requests using refresh token.
>
> - It seems we will need some flexibility how is the "sticky session"
> added to the request to support various loadbalancers (cookie,
> path-parameters etc). Maybe we need some SPI on adapter side? Or just
> some kind of expressions/tokens, which will help to configure how
> exactly will cookie/path parameter look like?
>
> - Keycloak.js adapter seems to be working already. Ajax requests are
> re-sending the browser cookies and they are available in backchannel
> endpoint on server-side. This is true even if AUTH_SESSION_ID cookie is
> httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not sure if
> this is different in other browsers/devices (cordova etc)?
>
> - For SAML backchannel requests (backchannel logout), we can add the
> same to our own SAML adapters though.
>
> - If people use 3rd party adapters, they won't have this. However we can
> also have support for some loadbalancers to route the requests directly
> based on the content of the route-id inside code (or refresh token). In
> many cases, customers will already have established loadbalancer in
> their deployments. However some others might be starting their
> deployment from the scratch and we can suggest them to use some of our
> preferred loadbalancers though.
>
> I've checked that if wildfly+mod_cluster is used as loadbalancer, we
> have the flexibility to inject custom undertow handler, which will be
> able to look into JWT and add the route info to the HttpServerExchange,
> from where mod_cluster will read it. Maybe we can investigate this
> possibility in the other popular loadbalancers (nginx etc) ?
>
> So in summary: Backchannel requests won't be able to participate in
> sticky session just if: 3rd party adapter is used AND customer can't use
> our preferred loadbalancer.
>
> WDYT?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri May 19 04:40:50 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 10:40:50 +0200
Subject: [keycloak-dev] Adapter's blueprint
In-Reply-To: <CAMZCGg8uYA62Sr00p8KwQk8W1tQmtwzLS-MhvCqWkbMt0opinA@mail.gmail.com>
References: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
	<20170509210042.GB13745@abstractj.org>
	<CAMQSZyijTQNrqx2sohk2uQd_wTtjW9wT37r4LctXr=4gUMxZAw@mail.gmail.com>
	<CAMZCGg8uYA62Sr00p8KwQk8W1tQmtwzLS-MhvCqWkbMt0opinA@mail.gmail.com>
Message-ID: <CAJgngAfOM7cKY0FDEAto03HzgS-w5jHbbU5rROy2JEmXmik8bA@mail.gmail.com>

+1000 To a conformance testsuite. It would be much less work to have a
single testsuite that can be used regardless of adapter.

On 10 May 2017 at 11:46, Sebastien Blanc <sblanc at redhat.com> wrote:

> Yes it's a great idea and I tried to word the specs as test requirements
> "Should ..." .
>
> Regarding unified tests apps, yes, something around functional test could
> do it.
> For instance, if you look at these tests
> https://github.com/keycloak/keycloak-quickstarts/blob/
> master/service-jee-jaxrs/src/test/java/org/keycloak/quickstart/jaxrs/
> ArquillianServiceJeeJaxrsTest.java
> , even if it's written in Java, it's pretty agnostic against which secured
> back end it runs ... Some there is definitely some space for that.
>
> But first, let's make sure we have a complete and curated list of
> specifications.
>
>
> On Wed, May 10, 2017 at 11:20 AM, Vaclav Muzikar <vmuzikar at redhat.com>
> wrote:
>
> > +1
> > I think that's a great idea! However, not sure about implementation
> > possibilities for such conformance testsuite since the adapters are often
> > platform/framework/language specific. Perhaps some unified test app(s)
> > which could be protected by any adapter?
> >
> > On Tue, May 9, 2017 at 11:00 PM, Bruno Oliveira <bruno at abstractj.org>
> > wrote:
> >
> > > This is a great start Sebi. And I think we can always change along the
> > > way.
> > >
> > > I was just thinking here about something for the future, maybe. A way
> to
> > > certify our Keycloak adapter's implementation. This idea came from
> > > OpenID connect certification[1].
> > >
> > > Why? In this way people could run conformance tests against our server
> > > and make sure that their implementation is still compatible with the
> > > latest releases of Keycloak. This also would enable us to know which
> > > project is stable or not.
> > >
> > > I know this could be a lot of work, but maybe something we could
> > work/take
> > > into
> > > consideration for further releases.
> > >
> > > [1] - http://openid.net/certification/testing/
> > >
> > > On 2017-05-09, Sebastien Blanc wrote:
> > > > Hi !
> > > >
> > > > I've started this sheet [1] that attempt to list all the features and
> > > > checks that a Keycloak adapter should support + a support matrix for
> > our
> > > > existing adapters.
> > > >
> > > > Feel free to add any missing feature, it's a really early version
> > > started a
> > > > few hours ago,
> > > >
> > > > Sebi
> > > > [1]
> > > > https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHOR
> > > qIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > --
> > >
> > > abstractj
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
> >
> >
> > --
> > V?clav Muzik??
> > Quality Engineer
> > Keycloak / Red Hat Single Sign-On
> > Red Hat Czech s.r.o.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Fri May 19 04:54:02 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 10:54:02 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <CAJgngAc6n2wgNON2mDf2pW8aesMwRpe74why50jOFBqE__1HiQ@mail.gmail.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<CAJgngAc6n2wgNON2mDf2pW8aesMwRpe74why50jOFBqE__1HiQ@mail.gmail.com>
Message-ID: <3cf9b36c-c192-a8d2-e73e-8ee474f15736@redhat.com>

On 19/05/17 10:30, Stian Thorgersen wrote:
> Why do you need a separate route.id <http://route.id> param? Wouldn't 
> it just rely on the session_state being the same value as the 
> authentication session cookie?
Yes, that's also an option.
>
> The cookie approach with our adapters seems sensible option. Not sure 
> about the approach of looking into the code/JWT as we can't rely on 
> the load balancer implementation. There's loads of them out there and 
> we need a solution that works regardless of the load balancer.
I know we can't rely on used loadbalancer. However in some cases, people 
may start their environment from scratch. If we have optimized solution 
for some loadbalancers (wildfly/undertow based. Maybe nginx and HAProxy 
as those seem to be quite popular) it won't be bad?

For example the development of undertow handler to be used together with 
Wildfly based mod_cluster loadbalancer won't be hard to do. Maybe the 
bigger challenge is testing and maintenance.
>
> One option if possible is on demand replication of sessions. A session 
> lives in one DC until it's requested from another DC. That means if 
> users use only apps that can be sticked to a DC either by cookie or 
> some other mechanism (for example the app itself is replicated in all 
> DCs) the session won't be replicated. If/when a user hits a third 
> party app or another app that for some reason is directed to the other 
> DC that session is fetched from the other DC and replicated afterwards.
Yes, I sent something around that in another mail today on keycloak-dev. 
It seems to me that we may need asynchronous requests to not block 
undertow worker thread waiting for userSession to be fetched from the 
other DC?

Also I wonder how bad it is to have option of userSession replicated 
directly between DCs through ASYNC channel? In other words, when 
userSession is created, it is replicated directly to other DCs by ASYNC 
way. It means that worker in the other DCs won't need to block so big 
time until userSession is fetched from the second DC and/or userSession 
may be already available there. But obviously there is price to pay that 
more communication will happen between DC, as it may result in 
replicating userSessions, which won't be needed in second DC at all.

Marek
>
>
> On 16 May 2017 at 10:19, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I was thinking about possibilities how to solve the issue with sticky
>     sessions in backchannel requests. It seems that we need to support the
>     scenarios, when backchannel requests won't be able to share the sticky
>     session cookie with the browser. However in many cases it may be
>     possible that backchannel requests can participate in the "sticky
>     session", which will have great advantage for performance. Some
>     thoughts:
>
>     - OAuth code (the one used in code-to-token backchannel request)
>     can be
>     JWT signed by realm HMAC key. One of the claims in the code could be
>     "route-id"
>
>     - Refresh tokens will also contain "route-id" claim
>
>     - Keycloak OIDC adapters will be able to read the "route-id" from the
>     code and they will attach sticky session information to the single
>     backchannel request. Hence the backchannel request will be able to
>     participate in sticky session and will be properly routed by
>     loadbalancer to the correct node. Same for requests using refresh
>     token.
>
>     - It seems we will need some flexibility how is the "sticky session"
>     added to the request to support various loadbalancers (cookie,
>     path-parameters etc). Maybe we need some SPI on adapter side? Or just
>     some kind of expressions/tokens, which will help to configure how
>     exactly will cookie/path parameter look like?
>
>     - Keycloak.js adapter seems to be working already. Ajax requests are
>     re-sending the browser cookies and they are available in backchannel
>     endpoint on server-side. This is true even if AUTH_SESSION_ID
>     cookie is
>     httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not
>     sure if
>     this is different in other browsers/devices (cordova etc)?
>
>     - For SAML backchannel requests (backchannel logout), we can add the
>     same to our own SAML adapters though.
>
>     - If people use 3rd party adapters, they won't have this. However
>     we can
>     also have support for some loadbalancers to route the requests
>     directly
>     based on the content of the route-id inside code (or refresh
>     token). In
>     many cases, customers will already have established loadbalancer in
>     their deployments. However some others might be starting their
>     deployment from the scratch and we can suggest them to use some of our
>     preferred loadbalancers though.
>
>     I've checked that if wildfly+mod_cluster is used as loadbalancer, we
>     have the flexibility to inject custom undertow handler, which will be
>     able to look into JWT and add the route info to the
>     HttpServerExchange,
>     from where mod_cluster will read it. Maybe we can investigate this
>     possibility in the other popular loadbalancers (nginx etc) ?
>
>     So in summary: Backchannel requests won't be able to participate in
>     sticky session just if: 3rd party adapter is used AND customer
>     can't use
>     our preferred loadbalancer.
>
>     WDYT?
>
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From leo.c at gct.gov.uk  Fri May 19 05:22:15 2017
From: leo.c at gct.gov.uk (Leo C)
Date: Fri, 19 May 2017 09:22:15 +0000
Subject: [keycloak-dev] Keycloak as stateless broker
Message-ID: <81F5813F-818C-48B7-932D-1F0E977FBFC0@gct.gov.uk>


Hi,

We would like to use keycloak as an identity broker in such a way that the identity collected from the identity provider are not permanently stored, so to avoid a build-up of identities stored on the broker.

Ideally, we would like:


?         Keycloak, as identity broker to accept SAML assertion from one of several identity providers

?         To use (custom) authentication flows to normalise or transform some of the attributes to create a new UserModel and consequentially a new SAML response back to the service provider

?         To not bring the UserModel (or any other personal details to rest in the database), though we would accept storing just the unique ID of the user if we could avoid storing other attributes, whilst still propagating them back to the service provider

?         Ideally to make authorisation decisions based on groups or roles during the process ? and stopping the authentication if those fail

Leo


From sthorger at redhat.com  Fri May 19 06:21:40 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 12:21:40 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <3cf9b36c-c192-a8d2-e73e-8ee474f15736@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<CAJgngAc6n2wgNON2mDf2pW8aesMwRpe74why50jOFBqE__1HiQ@mail.gmail.com>
	<3cf9b36c-c192-a8d2-e73e-8ee474f15736@redhat.com>
Message-ID: <CAJgngAeevg06pQ1eihZctt-XFvkEwN5gZQ-Cz-JEvSDNZcNUKw@mail.gmail.com>

On 19 May 2017 at 10:54, Marek Posolda <mposolda at redhat.com> wrote:

> On 19/05/17 10:30, Stian Thorgersen wrote:
>
> Why do you need a separate route.id param? Wouldn't it just rely on the
> session_state being the same value as the authentication session cookie?
>
> Yes, that's also an option.
>
>
> The cookie approach with our adapters seems sensible option. Not sure
> about the approach of looking into the code/JWT as we can't rely on the
> load balancer implementation. There's loads of them out there and we need a
> solution that works regardless of the load balancer.
>
> I know we can't rely on used loadbalancer. However in some cases, people
> may start their environment from scratch. If we have optimized solution for
> some loadbalancers (wildfly/undertow based. Maybe nginx and HAProxy as
> those seem to be quite popular) it won't be bad?
>
> For example the development of undertow handler to be used together with
> Wildfly based mod_cluster loadbalancer won't be hard to do. Maybe the
> bigger challenge is testing and maintenance.
>

I doubt anyone will use undertow as a load balancer when they have multiple
DCs. Most likely it'll be whatever Amazon provides and there's probably
limited possibilities on how it's configured.


>
>
> One option if possible is on demand replication of sessions. A session
> lives in one DC until it's requested from another DC. That means if users
> use only apps that can be sticked to a DC either by cookie or some other
> mechanism (for example the app itself is replicated in all DCs) the session
> won't be replicated. If/when a user hits a third party app or another app
> that for some reason is directed to the other DC that session is fetched
> from the other DC and replicated afterwards.
>
> Yes, I sent something around that in another mail today on keycloak-dev.
> It seems to me that we may need asynchronous requests to not block undertow
> worker thread waiting for userSession to be fetched from the other DC?
>
> Also I wonder how bad it is to have option of userSession replicated
> directly between DCs through ASYNC channel? In other words, when
> userSession is created, it is replicated directly to other DCs by ASYNC
> way. It means that worker in the other DCs won't need to block so big time
> until userSession is fetched from the second DC and/or userSession may be
> already available there. But obviously there is price to pay that more
> communication will happen between DC, as it may result in replicating
> userSessions, which won't be needed in second DC at all.
>

Haven't had time to read that thread yet. Async replication is probably
fine as a starting point, but if you want to really scale things and in
situations when it's possible to route requests for a session to only one
DC it would scale better if we could have an option to replicate on demand.


>
>
> Marek
>
>
>
> On 16 May 2017 at 10:19, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I was thinking about possibilities how to solve the issue with sticky
>> sessions in backchannel requests. It seems that we need to support the
>> scenarios, when backchannel requests won't be able to share the sticky
>> session cookie with the browser. However in many cases it may be
>> possible that backchannel requests can participate in the "sticky
>> session", which will have great advantage for performance. Some thoughts:
>>
>> - OAuth code (the one used in code-to-token backchannel request) can be
>> JWT signed by realm HMAC key. One of the claims in the code could be
>> "route-id"
>>
>> - Refresh tokens will also contain "route-id" claim
>>
>> - Keycloak OIDC adapters will be able to read the "route-id" from the
>> code and they will attach sticky session information to the single
>> backchannel request. Hence the backchannel request will be able to
>> participate in sticky session and will be properly routed by
>> loadbalancer to the correct node. Same for requests using refresh token.
>>
>> - It seems we will need some flexibility how is the "sticky session"
>> added to the request to support various loadbalancers (cookie,
>> path-parameters etc). Maybe we need some SPI on adapter side? Or just
>> some kind of expressions/tokens, which will help to configure how
>> exactly will cookie/path parameter look like?
>>
>> - Keycloak.js adapter seems to be working already. Ajax requests are
>> re-sending the browser cookies and they are available in backchannel
>> endpoint on server-side. This is true even if AUTH_SESSION_ID cookie is
>> httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not sure if
>> this is different in other browsers/devices (cordova etc)?
>>
>> - For SAML backchannel requests (backchannel logout), we can add the
>> same to our own SAML adapters though.
>>
>> - If people use 3rd party adapters, they won't have this. However we can
>> also have support for some loadbalancers to route the requests directly
>> based on the content of the route-id inside code (or refresh token). In
>> many cases, customers will already have established loadbalancer in
>> their deployments. However some others might be starting their
>> deployment from the scratch and we can suggest them to use some of our
>> preferred loadbalancers though.
>>
>> I've checked that if wildfly+mod_cluster is used as loadbalancer, we
>> have the flexibility to inject custom undertow handler, which will be
>> able to look into JWT and add the route info to the HttpServerExchange,
>> from where mod_cluster will read it. Maybe we can investigate this
>> possibility in the other popular loadbalancers (nginx etc) ?
>>
>> So in summary: Backchannel requests won't be able to participate in
>> sticky session just if: 3rd party adapter is used AND customer can't use
>> our preferred loadbalancer.
>>
>> WDYT?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From sthorger at redhat.com  Fri May 19 06:38:08 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 12:38:08 +0200
Subject: [keycloak-dev] Sharding and smart proxy
Message-ID: <CAJgngAfyKgZRZDJHRA9E+fVnqVukKXN+6SC3D1N3v17pUefvPA@mail.gmail.com>

Scaling to a huge amount of load (realms, users and/or sessions) is only
going to be feasible through sharding. This could be handled by users
themselves by having clusters of clusters, but we could also consider
adding this as a built in feature.

We could enable sharding at different levels:

* Realm
* Users
* Sessions

Then have smart routers that are able to route requests accordingly.

We could also enable the option to configure what DCs a specific realm
should be replicated to. For example one realm is only replicate to EU,
while another to both EU and US.

Maybe this could be relatively easy to implement? Not sure, it depends on
how much work it would be in the cache layer. We'd also need to implement a
smart router. That could probably borrow/share code with a lightweight
proxy option.

From psilva at redhat.com  Fri May 19 07:01:10 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 19 May 2017 08:01:10 -0300
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <SY3PR01MB0827A7BC808199ADB777DF20AFE50@SY3PR01MB0827.ausprd01.prod.outlook.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
	<CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>
	<CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>
	<SY3PR01MB0827A7BC808199ADB777DF20AFE50@SY3PR01MB0827.ausprd01.prod.outlook.com>
Message-ID: <CAJrcDBdU2B1o9=HXv9-oRUz2fi3VoMSDS7ZUJr0KeGopQYbq0Q@mail.gmail.com>

I'm not sure. But I will check if that is possible. If so, will update that
quickstart to use keycloak.json instead.

I'm also thinking about a another quickstart to demonstrate how to protect
APIs in Spring Boot. The one I have is pretty much related with protecting
web applications, but we probably need another one to also demonstrate
API/service security.

On Thu, May 18, 2017 at 10:19 PM, Crafton Williams <
crafton.williams at qut.edu.au> wrote:

> Hi Pedro:
>
>
>
> This is a huge help, thanks!
>
>
>
> A few questions though...is this is the only way to implement Authz with
> keyclaok and springboot? Is it possible to use the
> keycloak-spring-boot-adapter along with keycloak.json configured as a
> policy enforcer? I found it to be a very nice way of separating the
> security concern from the code itself.
>
>
>
>
>
> Cheers,
>
>
>
> Crafton
>
>
>
>
>
> *From: *Pedro Igor Silva <psilva at redhat.com>
> *Sent: *Friday, 19 May 2017 9:33 AM
> *To: *Crafton Williams <crafton.williams at qut.edu.au>
> *Cc: *keycloak-dev at lists.jboss.org
> *Subject: *Re: [keycloak-dev] Authorization with Springboot adapter
>
>
>
> I've sent a PR [1] with a quickstart for Spring Boot. Will work with some
> more examples covering specific features of Keycloak Authorization
> Services.
>
>
>
> Please let me know what you think about it. It is basically a Spring Boot
> Web application protected with simple fine-grained permissions.
>
>
>
> [1] https://github.com/keycloak/keycloak-quickstarts/pull/26
>
>
>
> Regards.
> Pedro Igor
>
>
>
>
>
> On Thu, May 18, 2017 at 9:35 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
> Btw, you are not the first one asking for more details about Spring boot
> integration. That is why I want to review this ....
>
>
>
> On Thu, May 18, 2017 at 9:34 AM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
> We are really missing examples and documentation to Spring Boot Adapter.
> Will write an example/template and review docs.
>
>
>
> Can give you an answer right now because I've tested authz with spring
> boot only a very few times. But you should not get this error at all.
>
>
>
> Will have something today.
>
>
>
>
>
>
>
> On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <
> crafton.williams at qut.edu.au> wrote:
>
> Hi All:
>
> I?m trying to configure a basic springboot app using the springboot
> keycloak adapter. Authentication works as expected but I?m a bit confused
> as to how to configure the policy enforcer in yaml. The documentation shows
> configuring the policy-enforcer as a json document however the springboot
> config implies a only policy-enforcer-config. In any case, I did try the
> json doc but it wasn?t picked up by the adapter.
>
> I?m using 3.0.0.Final and tried the following in my yaml file(omitted the
> rest of the path info for brevity):
>
> Policy-enforcer-config:
>   Enforcement-mode: ENFORCING
>   paths:
>
>   *   name: blah
>
> The exception I got was:
>
> org.springframework.context.ApplicationContextException: Unable to start
> embedded container; nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name 'tomcatEmbeddedServletContainerFactory'
> defined in class path resource [org/springframework/boot/
> autoconfigure/web/EmbeddedServletContainerAutoCo
> nfiguration$EmbeddedTomcat.class]: Initialization of bean failed; nested
> exception is org.springframework.beans.factory.
> UnsatisfiedDependencyException: Error creating bean with name
> 'org.keycloak.adapters.springboot.KeycloakSpringBootConfiguration':
> Unsatisfied dependency expressed through method '
> setKeycloakSpringBootProperties' parameter 0; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'keycloak-org.keycloak.adapters.springboot.KeycloakSpringBootProperties':
> Could not bind properties to KeycloakSpringBootProperties (prefix=keycloak,
> ignoreInvalidFields=false, ignoreUnknownFields=false,
> ignoreNestedProperties=false); nested exception is
> org.springframework.beans.InvalidPropertyException: Invalid property
> 'policyEnforcerConfig.paths[0]' of bean class [org.keycloak.adapters.
> springboot.KeycloakSpringBootProperties]: Illegal attempt to get property
> 'paths' threw exception; nested exception is java.lang.
> UnsupportedOperationException
>
> Is there an example project somewhere that can guide me in configuring the
> policy enforcer for the springboot adapter?
>
> Cheers,
>
> Crafton
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
>
>
>
>

From mposolda at redhat.com  Fri May 19 07:46:29 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 13:46:29 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <CAJgngAeevg06pQ1eihZctt-XFvkEwN5gZQ-Cz-JEvSDNZcNUKw@mail.gmail.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<CAJgngAc6n2wgNON2mDf2pW8aesMwRpe74why50jOFBqE__1HiQ@mail.gmail.com>
	<3cf9b36c-c192-a8d2-e73e-8ee474f15736@redhat.com>
	<CAJgngAeevg06pQ1eihZctt-XFvkEwN5gZQ-Cz-JEvSDNZcNUKw@mail.gmail.com>
Message-ID: <21608204-1010-b2b3-cbd1-e166f8a5b803@redhat.com>

On 19/05/17 12:21, Stian Thorgersen wrote:
>
>
> On 19 May 2017 at 10:54, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 19/05/17 10:30, Stian Thorgersen wrote:
>>     Why do you need a separate route.id <http://route.id> param?
>>     Wouldn't it just rely on the session_state being the same value
>>     as the authentication session cookie?
>     Yes, that's also an option.
>>
>>     The cookie approach with our adapters seems sensible option. Not
>>     sure about the approach of looking into the code/JWT as we can't
>>     rely on the load balancer implementation. There's loads of them
>>     out there and we need a solution that works regardless of the
>>     load balancer.
>     I know we can't rely on used loadbalancer. However in some cases,
>     people may start their environment from scratch. If we have
>     optimized solution for some loadbalancers (wildfly/undertow based.
>     Maybe nginx and HAProxy as those seem to be quite popular) it
>     won't be bad?
>
>     For example the development of undertow handler to be used
>     together with Wildfly based mod_cluster loadbalancer won't be hard
>     to do. Maybe the bigger challenge is testing and maintenance.
>
>
> I doubt anyone will use undertow as a load balancer when they have 
> multiple DCs. Most likely it'll be whatever Amazon provides and 
> there's probably limited possibilities on how it's configured.
Ah true. I will try to look what may people typically use as deployment 
scenarios with more DCs. Which environment, loadbalancers they use etc. 
Not sure how much "user stories" are publicly available.

Still undertow and mod_cluster will be helpful even for classic cluster 
without multiple DCs. If you can achieve sticky sessions for all 
backchannel requests (even if you have 3rd party adapters), it's good 
improvement for performance. But I won't treat it as big priority. Maybe 
just if there is demand or time permits.

>
>>
>>     One option if possible is on demand replication of sessions. A
>>     session lives in one DC until it's requested from another DC.
>>     That means if users use only apps that can be sticked to a DC
>>     either by cookie or some other mechanism (for example the app
>>     itself is replicated in all DCs) the session won't be replicated.
>>     If/when a user hits a third party app or another app that for
>>     some reason is directed to the other DC that session is fetched
>>     from the other DC and replicated afterwards.
>     Yes, I sent something around that in another mail today on
>     keycloak-dev. It seems to me that we may need asynchronous
>     requests to not block undertow worker thread waiting for
>     userSession to be fetched from the other DC?
>
>     Also I wonder how bad it is to have option of userSession
>     replicated directly between DCs through ASYNC channel? In other
>     words, when userSession is created, it is replicated directly to
>     other DCs by ASYNC way. It means that worker in the other DCs
>     won't need to block so big time until userSession is fetched from
>     the second DC and/or userSession may be already available there.
>     But obviously there is price to pay that more communication will
>     happen between DC, as it may result in replicating userSessions,
>     which won't be needed in second DC at all.
>
>
> Haven't had time to read that thread yet. Async replication is 
> probably fine as a starting point, but if you want to really scale 
> things and in situations when it's possible to route requests for a 
> session to only one DC it would scale better if we could have an 
> option to replicate on demand.
yep, with async by default, it will be more network communication for 
sure. However throughput for user requests may be better due the fact 
that they don't need to wait until session is fetched, as session may be 
already available. But not sure, maybe performance tests will help with 
this.

Marek
>
>
>
>     Marek
>
>>
>>
>>     On 16 May 2017 at 10:19, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         I was thinking about possibilities how to solve the issue
>>         with sticky
>>         sessions in backchannel requests. It seems that we need to
>>         support the
>>         scenarios, when backchannel requests won't be able to share
>>         the sticky
>>         session cookie with the browser. However in many cases it may be
>>         possible that backchannel requests can participate in the "sticky
>>         session", which will have great advantage for performance.
>>         Some thoughts:
>>
>>         - OAuth code (the one used in code-to-token backchannel
>>         request) can be
>>         JWT signed by realm HMAC key. One of the claims in the code
>>         could be
>>         "route-id"
>>
>>         - Refresh tokens will also contain "route-id" claim
>>
>>         - Keycloak OIDC adapters will be able to read the "route-id"
>>         from the
>>         code and they will attach sticky session information to the
>>         single
>>         backchannel request. Hence the backchannel request will be
>>         able to
>>         participate in sticky session and will be properly routed by
>>         loadbalancer to the correct node. Same for requests using
>>         refresh token.
>>
>>         - It seems we will need some flexibility how is the "sticky
>>         session"
>>         added to the request to support various loadbalancers (cookie,
>>         path-parameters etc). Maybe we need some SPI on adapter side?
>>         Or just
>>         some kind of expressions/tokens, which will help to configure how
>>         exactly will cookie/path parameter look like?
>>
>>         - Keycloak.js adapter seems to be working already. Ajax
>>         requests are
>>         re-sending the browser cookies and they are available in
>>         backchannel
>>         endpoint on server-side. This is true even if AUTH_SESSION_ID
>>         cookie is
>>         httpOnly. I've tested with Firefox, Chrome, my mobile phone.
>>         Not sure if
>>         this is different in other browsers/devices (cordova etc)?
>>
>>         - For SAML backchannel requests (backchannel logout), we can
>>         add the
>>         same to our own SAML adapters though.
>>
>>         - If people use 3rd party adapters, they won't have this.
>>         However we can
>>         also have support for some loadbalancers to route the
>>         requests directly
>>         based on the content of the route-id inside code (or refresh
>>         token). In
>>         many cases, customers will already have established
>>         loadbalancer in
>>         their deployments. However some others might be starting their
>>         deployment from the scratch and we can suggest them to use
>>         some of our
>>         preferred loadbalancers though.
>>
>>         I've checked that if wildfly+mod_cluster is used as
>>         loadbalancer, we
>>         have the flexibility to inject custom undertow handler, which
>>         will be
>>         able to look into JWT and add the route info to the
>>         HttpServerExchange,
>>         from where mod_cluster will read it. Maybe we can investigate
>>         this
>>         possibility in the other popular loadbalancers (nginx etc) ?
>>
>>         So in summary: Backchannel requests won't be able to
>>         participate in
>>         sticky session just if: 3rd party adapter is used AND
>>         customer can't use
>>         our preferred loadbalancer.
>>
>>         WDYT?
>>
>>         Marek
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From ssilvert at redhat.com  Fri May 19 08:15:41 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 May 2017 08:15:41 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
Message-ID: <7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>

On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
> That's rather off topic. Quickstarts is one thing and a demo/example 
> is another thing. Quickstarts is supposed to show you how to get 
> started with securing your apps with Keycloak. What you are proposing 
> is a nice option on just trying out Keycloak, but it doesn't really 
> help users getting started properly with securing their apps.
I disagree.  It would help tremendously.  Right now, to get started 
securing your apps with the help of quickstart you must:
1) Set up a Keycloak instance and understand that you need to run it on 
port 8180.
2) Set up a Wildfly instance on port 8080.
3) Find multiple json files that you need to import to Keycloak
3.5) If you can't figure out what to import, follow the instructions to 
do Keycloak config by hand.
4) Create keycloak.json files for each app and put them in the proper place.
5) Do mvn wildfly:deploy for each app you want to run
6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
7) Try modifications to the quickstart apps so you can get an ideas 
about how you will secure your own apps
8) Deploy your modifications

What I propose is that we get rid of steps 1 through 6.  Quickstart 
doesn't help if you can't get to steps 7 and 8 "quickly".

>
> On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     What we really need for the quickstarts is something Bill has been
>     talking about for a long time.
>
>     It's a bundle of Keycloak and examples that just boots up and works.
>     Otherwise, the quickstarts are way too hard to get running. Nobody
>     wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
>     recently and I already know what's going on.  I hate to think
>     about what
>     someone new to Keycloak needs to go through just to see an example.
>
>     This doesn't have to mean that everything runs in the same WildFly
>     instance like the old demo dist.  The problem with that was that it
>     didn't show Keycloak set up as a stand-alone server.
>
>     What you need is a single bundle that lets you run Keycloak standalone
>     and a standalone app server.  I see a couple of ways to do it:
>     1) Use domain mode where you get a domain controller, Keycloak
>     instance,
>     and app server instance all in the same JVM.
>     2) Use two separate server configs and run in two JVM's.
>
>     I think #2 is the best.  The Keycloak instance runs on port 8180
>     and the
>     app server runs on 8080.  You only need one download of
>     WildFly/Keycloak, but you package it with two configs.  So you have:
>     /bin
>     /modules
>     /domain (don't actually need this one)
>     /standalone
>     /keycloak
>
>     To run Keycloak (preloaded with quickstart realm):
>      > standalone --server-config=keycloak
>     -Djboss.socket.binding.port-offset=100
>
>     To run app server (preloaded with quickstart apps):
>      > standalone
>
>
>
>     On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>     > Hmmm I'm not sure about that. That would be the completely
>     opposite of what
>     > we already do to any repository today. If people want the stable
>     release of
>     > the quickstarts they could just get 3.x or download the zip
>     files, nope?
>     >
>     > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
>     <sblanc at redhat.com <mailto:sblanc at redhat.com>> wrote:
>     >
>     >> We should also consider the opposite : master is the stable
>     released
>     >> version and a branch for development . I already had confused
>     people
>     >> downloading KC server and cloning the QuickStarts and expecting
>     it to work.
>     >> But tbh I do not have a string opinion on that.
>     >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira
>     <bruno at abstractj.org <mailto:bruno at abstractj.org>> a
>     >> ?crit :
>     >>
>     >>> While working today on the fix of some quickstarts. I'm
>     >>> considering to create a separated branch only for stable
>     versions of the
>     >>> quickstarts.
>     >>>
>     >>> In this way 'master' would be used only for development based
>     on the
>     >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>     >>> release on Maven central.
>     >>>
>     >>> Does it make any sense?
>     >>>
>     >>> --
>     >>>
>     >>> abstractj
>     >>>
>     >> _______________________________________________
>     >>> keycloak-dev mailing list
>     >>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From sthorger at redhat.com  Fri May 19 08:29:50 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 14:29:50 +0200
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
Message-ID: <CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>

I repeat - Quickstarts are to help people getting started securing their
own applications.

What you are proposing will not help for that. We don't support deploying
apps directly to Keycloak. It's an SSO solution after all. So it's just
part of it running Keycloak on a different port or host.

On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com> wrote:

> On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
>
> That's rather off topic. Quickstarts is one thing and a demo/example is
> another thing. Quickstarts is supposed to show you how to get started with
> securing your apps with Keycloak. What you are proposing is a nice option
> on just trying out Keycloak, but it doesn't really help users getting
> started properly with securing their apps.
>
> I disagree.  It would help tremendously.  Right now, to get started
> securing your apps with the help of quickstart you must:
> 1) Set up a Keycloak instance and understand that you need to run it on
> port 8180.
> 2) Set up a Wildfly instance on port 8080.
> 3) Find multiple json files that you need to import to Keycloak
> 3.5) If you can't figure out what to import, follow the instructions to do
> Keycloak config by hand.
> 4) Create keycloak.json files for each app and put them in the proper
> place.
> 5) Do mvn wildfly:deploy for each app you want to run
> 6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
> 7) Try modifications to the quickstart apps so you can get an ideas about
> how you will secure your own apps
> 8) Deploy your modifications
>
> What I propose is that we get rid of steps 1 through 6.  Quickstart
> doesn't help if you can't get to steps 7 and 8 "quickly".
>
>
>
> On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> What we really need for the quickstarts is something Bill has been
>> talking about for a long time.
>>
>> It's a bundle of Keycloak and examples that just boots up and works.
>> Otherwise, the quickstarts are way too hard to get running.  Nobody
>> wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
>> recently and I already know what's going on.  I hate to think about what
>> someone new to Keycloak needs to go through just to see an example.
>>
>> This doesn't have to mean that everything runs in the same WildFly
>> instance like the old demo dist.  The problem with that was that it
>> didn't show Keycloak set up as a stand-alone server.
>>
>> What you need is a single bundle that lets you run Keycloak standalone
>> and a standalone app server.  I see a couple of ways to do it:
>> 1) Use domain mode where you get a domain controller, Keycloak instance,
>> and app server instance all in the same JVM.
>> 2) Use two separate server configs and run in two JVM's.
>>
>> I think #2 is the best.  The Keycloak instance runs on port 8180 and the
>> app server runs on 8080.  You only need one download of
>> WildFly/Keycloak, but you package it with two configs.  So you have:
>> /bin
>> /modules
>> /domain (don't actually need this one)
>> /standalone
>> /keycloak
>>
>> To run Keycloak (preloaded with quickstart realm):
>>  > standalone --server-config=keycloak
>> -Djboss.socket.binding.port-offset=100
>>
>> To run app server (preloaded with quickstart apps):
>>  > standalone
>>
>>
>>
>> On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>> > Hmmm I'm not sure about that. That would be the completely opposite of
>> what
>> > we already do to any repository today. If people want the stable
>> release of
>> > the quickstarts they could just get 3.x or download the zip files, nope?
>> >
>> > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>> >
>> >> We should also consider the opposite : master is the stable released
>> >> version and a branch for development . I already had confused people
>> >> downloading KC server and cloning the QuickStarts and expecting it to
>> work.
>> >> But tbh I do not have a string opinion on that.
>> >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
>> >> ?crit :
>> >>
>> >>> While working today on the fix of some quickstarts. I'm
>> >>> considering to create a separated branch only for stable versions of
>> the
>> >>> quickstarts.
>> >>>
>> >>> In this way 'master' would be used only for development based on the
>> >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>> >>> release on Maven central.
>> >>>
>> >>> Does it make any sense?
>> >>>
>> >>> --
>> >>>
>> >>> abstractj
>> >>>
>> >> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From sthorger at redhat.com  Fri May 19 08:34:40 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 May 2017 14:34:40 +0200
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
	<CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
Message-ID: <CAJgngAeiZYDPdrd9ZL2m6dUWZT24XQM_GWNE-jTgiDSji5AjRw@mail.gmail.com>

That being said I agree the steps are cumbersome, so any improvements would
be good. Generating some sort of uber bundle is not the solution IMO.

On 19 May 2017 at 14:29, Stian Thorgersen <sthorger at redhat.com> wrote:

> I repeat - Quickstarts are to help people getting started securing their
> own applications.
>
> What you are proposing will not help for that. We don't support deploying
> apps directly to Keycloak. It's an SSO solution after all. So it's just
> part of it running Keycloak on a different port or host.
>
>
> On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
>>
>> That's rather off topic. Quickstarts is one thing and a demo/example is
>> another thing. Quickstarts is supposed to show you how to get started with
>> securing your apps with Keycloak. What you are proposing is a nice option
>> on just trying out Keycloak, but it doesn't really help users getting
>> started properly with securing their apps.
>>
>> I disagree.  It would help tremendously.  Right now, to get started
>> securing your apps with the help of quickstart you must:
>> 1) Set up a Keycloak instance and understand that you need to run it on
>> port 8180.
>> 2) Set up a Wildfly instance on port 8080.
>> 3) Find multiple json files that you need to import to Keycloak
>> 3.5) If you can't figure out what to import, follow the instructions to
>> do Keycloak config by hand.
>> 4) Create keycloak.json files for each app and put them in the proper
>> place.
>> 5) Do mvn wildfly:deploy for each app you want to run
>> 6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
>> 7) Try modifications to the quickstart apps so you can get an ideas about
>> how you will secure your own apps
>> 8) Deploy your modifications
>>
>> What I propose is that we get rid of steps 1 through 6.  Quickstart
>> doesn't help if you can't get to steps 7 and 8 "quickly".
>>
>>
>>
>> On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com> wrote:
>>
>>> What we really need for the quickstarts is something Bill has been
>>> talking about for a long time.
>>>
>>> It's a bundle of Keycloak and examples that just boots up and works.
>>> Otherwise, the quickstarts are way too hard to get running.  Nobody
>>> wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
>>> recently and I already know what's going on.  I hate to think about what
>>> someone new to Keycloak needs to go through just to see an example.
>>>
>>> This doesn't have to mean that everything runs in the same WildFly
>>> instance like the old demo dist.  The problem with that was that it
>>> didn't show Keycloak set up as a stand-alone server.
>>>
>>> What you need is a single bundle that lets you run Keycloak standalone
>>> and a standalone app server.  I see a couple of ways to do it:
>>> 1) Use domain mode where you get a domain controller, Keycloak instance,
>>> and app server instance all in the same JVM.
>>> 2) Use two separate server configs and run in two JVM's.
>>>
>>> I think #2 is the best.  The Keycloak instance runs on port 8180 and the
>>> app server runs on 8080.  You only need one download of
>>> WildFly/Keycloak, but you package it with two configs.  So you have:
>>> /bin
>>> /modules
>>> /domain (don't actually need this one)
>>> /standalone
>>> /keycloak
>>>
>>> To run Keycloak (preloaded with quickstart realm):
>>>  > standalone --server-config=keycloak
>>> -Djboss.socket.binding.port-offset=100
>>>
>>> To run app server (preloaded with quickstart apps):
>>>  > standalone
>>>
>>>
>>>
>>> On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>>> > Hmmm I'm not sure about that. That would be the completely opposite of
>>> what
>>> > we already do to any repository today. If people want the stable
>>> release of
>>> > the quickstarts they could just get 3.x or download the zip files,
>>> nope?
>>> >
>>> > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>> >
>>> >> We should also consider the opposite : master is the stable released
>>> >> version and a branch for development . I already had confused people
>>> >> downloading KC server and cloning the QuickStarts and expecting it to
>>> work.
>>> >> But tbh I do not have a string opinion on that.
>>> >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
>>> >> ?crit :
>>> >>
>>> >>> While working today on the fix of some quickstarts. I'm
>>> >>> considering to create a separated branch only for stable versions of
>>> the
>>> >>> quickstarts.
>>> >>>
>>> >>> In this way 'master' would be used only for development based on the
>>> >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>>> >>> release on Maven central.
>>> >>>
>>> >>> Does it make any sense?
>>> >>>
>>> >>> --
>>> >>>
>>> >>> abstractj
>>> >>>
>>> >> _______________________________________________
>>> >>> keycloak-dev mailing list
>>> >>> keycloak-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>>
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>

From ssilvert at redhat.com  Fri May 19 08:36:41 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 May 2017 08:36:41 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
	<CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
Message-ID: <4e69c786-bff5-fe2b-80cc-adc21f004ee6@redhat.com>

On 5/19/2017 8:29 AM, Stian Thorgersen wrote:
> I repeat - Quickstarts are to help people getting started securing 
> their own applications.
>
> What you are proposing will not help for that. We don't support 
> deploying apps directly to Keycloak. It's an SSO solution after all. 
> So it's just part of it running Keycloak on a different port or host.
You don't understand.  I'm not proposing that you deploy apps directly 
to Keycloak.

I'm proposing that we ship a "canned" Keycloak instance along with a 
"canned" WildFly instance.  Everything starts up and works immediately 
so you can get down to business right away.

>
> On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
>>     That's rather off topic. Quickstarts is one thing and a
>>     demo/example is another thing. Quickstarts is supposed to show
>>     you how to get started with securing your apps with Keycloak.
>>     What you are proposing is a nice option on just trying out
>>     Keycloak, but it doesn't really help users getting started
>>     properly with securing their apps.
>     I disagree.  It would help tremendously. Right now, to get started
>     securing your apps with the help of quickstart you must:
>     1) Set up a Keycloak instance and understand that you need to run
>     it on port 8180.
>     2) Set up a Wildfly instance on port 8080.
>     3) Find multiple json files that you need to import to Keycloak
>     3.5) If you can't figure out what to import, follow the
>     instructions to do Keycloak config by hand.
>     4) Create keycloak.json files for each app and put them in the
>     proper place.
>     5) Do mvn wildfly:deploy for each app you want to run
>     6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
>     7) Try modifications to the quickstart apps so you can get an
>     ideas about how you will secure your own apps
>     8) Deploy your modifications
>
>     What I propose is that we get rid of steps 1 through 6. 
>     Quickstart doesn't help if you can't get to steps 7 and 8 "quickly".
>
>
>>
>>     On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         What we really need for the quickstarts is something Bill has
>>         been
>>         talking about for a long time.
>>
>>         It's a bundle of Keycloak and examples that just boots up and
>>         works.
>>         Otherwise, the quickstarts are way too hard to get running. 
>>         Nobody
>>         wants to spend 2 or 3 hours on a "quickstart". That's what I
>>         had to do
>>         recently and I already know what's going on.  I hate to think
>>         about what
>>         someone new to Keycloak needs to go through just to see an
>>         example.
>>
>>         This doesn't have to mean that everything runs in the same
>>         WildFly
>>         instance like the old demo dist.  The problem with that was
>>         that it
>>         didn't show Keycloak set up as a stand-alone server.
>>
>>         What you need is a single bundle that lets you run Keycloak
>>         standalone
>>         and a standalone app server.  I see a couple of ways to do it:
>>         1) Use domain mode where you get a domain controller,
>>         Keycloak instance,
>>         and app server instance all in the same JVM.
>>         2) Use two separate server configs and run in two JVM's.
>>
>>         I think #2 is the best.  The Keycloak instance runs on port
>>         8180 and the
>>         app server runs on 8080.  You only need one download of
>>         WildFly/Keycloak, but you package it with two configs.  So
>>         you have:
>>         /bin
>>         /modules
>>         /domain (don't actually need this one)
>>         /standalone
>>         /keycloak
>>
>>         To run Keycloak (preloaded with quickstart realm):
>>          > standalone --server-config=keycloak
>>         -Djboss.socket.binding.port-offset=100
>>
>>         To run app server (preloaded with quickstart apps):
>>          > standalone
>>
>>
>>
>>         On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>>         > Hmmm I'm not sure about that. That would be the completely
>>         opposite of what
>>         > we already do to any repository today. If people want the
>>         stable release of
>>         > the quickstarts they could just get 3.x or download the zip
>>         files, nope?
>>         >
>>         > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
>>         <sblanc at redhat.com <mailto:sblanc at redhat.com>> wrote:
>>         >
>>         >> We should also consider the opposite : master is the
>>         stable released
>>         >> version and a branch for development . I already had
>>         confused people
>>         >> downloading KC server and cloning the QuickStarts and
>>         expecting it to work.
>>         >> But tbh I do not have a string opinion on that.
>>         >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira
>>         <bruno at abstractj.org <mailto:bruno at abstractj.org>> a
>>         >> ?crit :
>>         >>
>>         >>> While working today on the fix of some quickstarts. I'm
>>         >>> considering to create a separated branch only for stable
>>         versions of the
>>         >>> quickstarts.
>>         >>>
>>         >>> In this way 'master' would be used only for development
>>         based on the
>>         >>> latest bits from Keycloak repo. And 3.1.x, to the latest
>>         stable
>>         >>> release on Maven central.
>>         >>>
>>         >>> Does it make any sense?
>>         >>>
>>         >>> --
>>         >>>
>>         >>> abstractj
>>         >>>
>>         >> _______________________________________________
>>         >>> keycloak-dev mailing list
>>         >>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From bruno at abstractj.org  Fri May 19 08:37:40 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 19 May 2017 12:37:40 +0000
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAJgngAfP9Et-LRPjEZ=Mz_gBXz9uu0iUp7+hrDtY-QsOJ0UOtg@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAM5SUC6OvLHBYUeL_tda-rDhdLHQFm7OKqN1y6wpVf9vhYdKJw@mail.gmail.com>
	<CAJgngAfP9Et-LRPjEZ=Mz_gBXz9uu0iUp7+hrDtY-QsOJ0UOtg@mail.gmail.com>
Message-ID: <CAM5SUC6KPW2L0uWdFD52=T52UdhtiWBGOQZ1QkPtsu-bqkoz2w@mail.gmail.com>

Latest and master were created. The branches quickstarts-dev and kc-3.0.0
deleted.

So now we have:

- Latest: all the stuff stable and in sync with the latest release of
Keycloak server
- master: all the stuff based on the latest commits from Keycloak on master.

On Fri, May 19, 2017 at 4:03 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> The default branch regardless what it's called should be the branch users
> should use for the latest Keycloak release. The reasoning for that is that
> a user when trying the quickstarts should not have to do a clone then
> checkout another branch.
>
> We could either go with:
>
> 1. master (default branch) and dev
> 2. latest (default branch) and master
>
> My vote goes to option 2.
>
> On 19 May 2017 at 01:41, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> I truly feel that we are talking about completely different things.
>>
>> But you can add your considerations to this Jira:
>> https://issues.jboss.org/browse/KEYCLOAK-3577
>>
>> On Thu, May 18, 2017, 4:58 PM Stan Silvert <ssilvert at redhat.com> wrote:
>>
>> > What we really need for the quickstarts is something Bill has been
>> > talking about for a long time.
>> >
>> > It's a bundle of Keycloak and examples that just boots up and works.
>> > Otherwise, the quickstarts are way too hard to get running.  Nobody
>> > wants to spend 2 or 3 hours on a "quickstart". That's what I had to do
>> > recently and I already know what's going on.  I hate to think about what
>> > someone new to Keycloak needs to go through just to see an example.
>> >
>> > This doesn't have to mean that everything runs in the same WildFly
>> > instance like the old demo dist.  The problem with that was that it
>> > didn't show Keycloak set up as a stand-alone server.
>> >
>> > What you need is a single bundle that lets you run Keycloak standalone
>> > and a standalone app server.  I see a couple of ways to do it:
>> > 1) Use domain mode where you get a domain controller, Keycloak instance,
>> > and app server instance all in the same JVM.
>> > 2) Use two separate server configs and run in two JVM's.
>> >
>> > I think #2 is the best.  The Keycloak instance runs on port 8180 and the
>> > app server runs on 8080.  You only need one download of
>> > WildFly/Keycloak, but you package it with two configs.  So you have:
>> > /bin
>> > /modules
>> > /domain (don't actually need this one)
>> > /standalone
>> > /keycloak
>> >
>> > To run Keycloak (preloaded with quickstart realm):
>> >  > standalone --server-config=keycloak
>> > -Djboss.socket.binding.port-offset=100
>> >
>> > To run app server (preloaded with quickstart apps):
>> >  > standalone
>> >
>> >
>> >
>> > On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>> > > Hmmm I'm not sure about that. That would be the completely opposite of
>> > what
>> > > we already do to any repository today. If people want the stable
>> release
>> > of
>> > > the quickstarts they could just get 3.x or download the zip files,
>> nope?
>> > >
>> > > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc <sblanc at redhat.com>
>> > wrote:
>> > >
>> > >> We should also consider the opposite : master is the stable released
>> > >> version and a branch for development . I already had confused people
>> > >> downloading KC server and cloning the QuickStarts and expecting it to
>> > work.
>> > >> But tbh I do not have a string opinion on that.
>> > >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira <bruno at abstractj.org> a
>> > >> ?crit :
>> > >>
>> > >>> While working today on the fix of some quickstarts. I'm
>> > >>> considering to create a separated branch only for stable versions of
>> > the
>> > >>> quickstarts.
>> > >>>
>> > >>> In this way 'master' would be used only for development based on the
>> > >>> latest bits from Keycloak repo. And 3.1.x, to the latest stable
>> > >>> release on Maven central.
>> > >>>
>> > >>> Does it make any sense?
>> > >>>
>> > >>> --
>> > >>>
>> > >>> abstractj
>> > >>>
>> > >> _______________________________________________
>> > >>> keycloak-dev mailing list
>> > >>> keycloak-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>>
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From ssilvert at redhat.com  Fri May 19 08:42:39 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 May 2017 08:42:39 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAJgngAeiZYDPdrd9ZL2m6dUWZT24XQM_GWNE-jTgiDSji5AjRw@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
	<CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
	<CAJgngAeiZYDPdrd9ZL2m6dUWZT24XQM_GWNE-jTgiDSji5AjRw@mail.gmail.com>
Message-ID: <7fd4ea4e-d739-96aa-ba71-e73bd13f44f3@redhat.com>

On 5/19/2017 8:34 AM, Stian Thorgersen wrote:
> That being said I agree the steps are cumbersome, so any improvements 
> would be good. Generating some sort of uber bundle is not the solution 
> IMO.
You have to somehow get to the point that you can do steps 7 and 8. 
That's when the quickstarts begin to help you.

We can get them to 7 and 8 by building everything out for the user and 
letting them download it.

The alternative is to provide a maven build that will automatically do 
steps 1 through 6.

The point is that we should not make the user do steps 1 through 6 manually.
>
> On 19 May 2017 at 14:29, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     I repeat - Quickstarts are to help people getting started securing
>     their own applications.
>
>     What you are proposing will not help for that. We don't support
>     deploying apps directly to Keycloak. It's an SSO solution after
>     all. So it's just part of it running Keycloak on a different port
>     or host.
>
>
>     On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>> wrote:
>
>         On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
>>         That's rather off topic. Quickstarts is one thing and a
>>         demo/example is another thing. Quickstarts is supposed to
>>         show you how to get started with securing your apps with
>>         Keycloak. What you are proposing is a nice option on just
>>         trying out Keycloak, but it doesn't really help users getting
>>         started properly with securing their apps.
>         I disagree.  It would help tremendously.  Right now, to get
>         started securing your apps with the help of quickstart you must:
>         1) Set up a Keycloak instance and understand that you need to
>         run it on port 8180.
>         2) Set up a Wildfly instance on port 8080.
>         3) Find multiple json files that you need to import to Keycloak
>         3.5) If you can't figure out what to import, follow the
>         instructions to do Keycloak config by hand.
>         4) Create keycloak.json files for each app and put them in the
>         proper place.
>         5) Do mvn wildfly:deploy for each app you want to run
>         6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
>         7) Try modifications to the quickstart apps so you can get an
>         ideas about how you will secure your own apps
>         8) Deploy your modifications
>
>         What I propose is that we get rid of steps 1 through 6. 
>         Quickstart doesn't help if you can't get to steps 7 and 8
>         "quickly".
>
>
>>
>>         On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com
>>         <mailto:ssilvert at redhat.com>> wrote:
>>
>>             What we really need for the quickstarts is something Bill
>>             has been
>>             talking about for a long time.
>>
>>             It's a bundle of Keycloak and examples that just boots up
>>             and works.
>>             Otherwise, the quickstarts are way too hard to get
>>             running. Nobody
>>             wants to spend 2 or 3 hours on a "quickstart". That's
>>             what I had to do
>>             recently and I already know what's going on.  I hate to
>>             think about what
>>             someone new to Keycloak needs to go through just to see
>>             an example.
>>
>>             This doesn't have to mean that everything runs in the
>>             same WildFly
>>             instance like the old demo dist.  The problem with that
>>             was that it
>>             didn't show Keycloak set up as a stand-alone server.
>>
>>             What you need is a single bundle that lets you run
>>             Keycloak standalone
>>             and a standalone app server.  I see a couple of ways to
>>             do it:
>>             1) Use domain mode where you get a domain controller,
>>             Keycloak instance,
>>             and app server instance all in the same JVM.
>>             2) Use two separate server configs and run in two JVM's.
>>
>>             I think #2 is the best.  The Keycloak instance runs on
>>             port 8180 and the
>>             app server runs on 8080.  You only need one download of
>>             WildFly/Keycloak, but you package it with two configs. 
>>             So you have:
>>             /bin
>>             /modules
>>             /domain (don't actually need this one)
>>             /standalone
>>             /keycloak
>>
>>             To run Keycloak (preloaded with quickstart realm):
>>              > standalone --server-config=keycloak
>>             -Djboss.socket.binding.port-offset=100
>>
>>             To run app server (preloaded with quickstart apps):
>>              > standalone
>>
>>
>>
>>             On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>>             > Hmmm I'm not sure about that. That would be the
>>             completely opposite of what
>>             > we already do to any repository today. If people want
>>             the stable release of
>>             > the quickstarts they could just get 3.x or download the
>>             zip files, nope?
>>             >
>>             > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
>>             <sblanc at redhat.com <mailto:sblanc at redhat.com>> wrote:
>>             >
>>             >> We should also consider the opposite : master is the
>>             stable released
>>             >> version and a branch for development . I already had
>>             confused people
>>             >> downloading KC server and cloning the QuickStarts and
>>             expecting it to work.
>>             >> But tbh I do not have a string opinion on that.
>>             >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira
>>             <bruno at abstractj.org <mailto:bruno at abstractj.org>> a
>>             >> ?crit :
>>             >>
>>             >>> While working today on the fix of some quickstarts. I'm
>>             >>> considering to create a separated branch only for
>>             stable versions of the
>>             >>> quickstarts.
>>             >>>
>>             >>> In this way 'master' would be used only for
>>             development based on the
>>             >>> latest bits from Keycloak repo. And 3.1.x, to the
>>             latest stable
>>             >>> release on Maven central.
>>             >>>
>>             >>> Does it make any sense?
>>             >>>
>>             >>> --
>>             >>>
>>             >>> abstractj
>>             >>>
>>             >> _______________________________________________
>>             >>> keycloak-dev mailing list
>>             >>> keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at 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 at lists.jboss.org
>>             <mailto:keycloak-dev at 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 at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>
>


From ssilvert at redhat.com  Fri May 19 08:47:31 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 May 2017 08:47:31 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
	<CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
Message-ID: <c5fa8e21-3f68-202a-ac7e-5838815b5b12@redhat.com>

On 5/19/2017 8:29 AM, Stian Thorgersen wrote:
> I repeat - Quickstarts are to help people getting started securing 
> their own applications.
>
> What you are proposing will not help for that. We don't support 
> deploying apps directly to Keycloak. It's an SSO solution after all. 
> So it's just part of it running Keycloak on a different port or host.
Also, I don't think I explained very well how this works.  There are two 
completely different servers that just happen to share the same /modules 
directory:

/modules
/standalone
/keycloak

>
> On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
>>     That's rather off topic. Quickstarts is one thing and a
>>     demo/example is another thing. Quickstarts is supposed to show
>>     you how to get started with securing your apps with Keycloak.
>>     What you are proposing is a nice option on just trying out
>>     Keycloak, but it doesn't really help users getting started
>>     properly with securing their apps.
>     I disagree.  It would help tremendously. Right now, to get started
>     securing your apps with the help of quickstart you must:
>     1) Set up a Keycloak instance and understand that you need to run
>     it on port 8180.
>     2) Set up a Wildfly instance on port 8080.
>     3) Find multiple json files that you need to import to Keycloak
>     3.5) If you can't figure out what to import, follow the
>     instructions to do Keycloak config by hand.
>     4) Create keycloak.json files for each app and put them in the
>     proper place.
>     5) Do mvn wildfly:deploy for each app you want to run
>     6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
>     7) Try modifications to the quickstart apps so you can get an
>     ideas about how you will secure your own apps
>     8) Deploy your modifications
>
>     What I propose is that we get rid of steps 1 through 6. 
>     Quickstart doesn't help if you can't get to steps 7 and 8 "quickly".
>
>
>>
>>     On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         What we really need for the quickstarts is something Bill has
>>         been
>>         talking about for a long time.
>>
>>         It's a bundle of Keycloak and examples that just boots up and
>>         works.
>>         Otherwise, the quickstarts are way too hard to get running. 
>>         Nobody
>>         wants to spend 2 or 3 hours on a "quickstart". That's what I
>>         had to do
>>         recently and I already know what's going on.  I hate to think
>>         about what
>>         someone new to Keycloak needs to go through just to see an
>>         example.
>>
>>         This doesn't have to mean that everything runs in the same
>>         WildFly
>>         instance like the old demo dist.  The problem with that was
>>         that it
>>         didn't show Keycloak set up as a stand-alone server.
>>
>>         What you need is a single bundle that lets you run Keycloak
>>         standalone
>>         and a standalone app server.  I see a couple of ways to do it:
>>         1) Use domain mode where you get a domain controller,
>>         Keycloak instance,
>>         and app server instance all in the same JVM.
>>         2) Use two separate server configs and run in two JVM's.
>>
>>         I think #2 is the best.  The Keycloak instance runs on port
>>         8180 and the
>>         app server runs on 8080.  You only need one download of
>>         WildFly/Keycloak, but you package it with two configs.  So
>>         you have:
>>         /bin
>>         /modules
>>         /domain (don't actually need this one)
>>         /standalone
>>         /keycloak
>>
>>         To run Keycloak (preloaded with quickstart realm):
>>          > standalone --server-config=keycloak
>>         -Djboss.socket.binding.port-offset=100
>>
>>         To run app server (preloaded with quickstart apps):
>>          > standalone
>>
>>
>>
>>         On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>>         > Hmmm I'm not sure about that. That would be the completely
>>         opposite of what
>>         > we already do to any repository today. If people want the
>>         stable release of
>>         > the quickstarts they could just get 3.x or download the zip
>>         files, nope?
>>         >
>>         > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
>>         <sblanc at redhat.com <mailto:sblanc at redhat.com>> wrote:
>>         >
>>         >> We should also consider the opposite : master is the
>>         stable released
>>         >> version and a branch for development . I already had
>>         confused people
>>         >> downloading KC server and cloning the QuickStarts and
>>         expecting it to work.
>>         >> But tbh I do not have a string opinion on that.
>>         >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira
>>         <bruno at abstractj.org <mailto:bruno at abstractj.org>> a
>>         >> ?crit :
>>         >>
>>         >>> While working today on the fix of some quickstarts. I'm
>>         >>> considering to create a separated branch only for stable
>>         versions of the
>>         >>> quickstarts.
>>         >>>
>>         >>> In this way 'master' would be used only for development
>>         based on the
>>         >>> latest bits from Keycloak repo. And 3.1.x, to the latest
>>         stable
>>         >>> release on Maven central.
>>         >>>
>>         >>> Does it make any sense?
>>         >>>
>>         >>> --
>>         >>>
>>         >>> abstractj
>>         >>>
>>         >> _______________________________________________
>>         >>> keycloak-dev mailing list
>>         >>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From bruno at abstractj.org  Fri May 19 09:01:17 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 19 May 2017 13:01:17 +0000
Subject: [keycloak-dev] Adapter's blueprint
In-Reply-To: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
References: <CAMZCGg9a=STE1vRDU-zUJ4f=w5=NOi4KFDAQ8ykFBH2HSsT8-w@mail.gmail.com>
Message-ID: <CAM5SUC5v+x3=s+8zMQNSsZtMYPs816FM-OZn2e8hLG=TpFwrPA@mail.gmail.com>

Captured here: https://issues.jboss.org/browse/KEYCLOAK-4943

On Tue, May 9, 2017 at 1:32 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi !
>
> I've started this sheet [1] that attempt to list all the features and
> checks that a Keycloak adapter should support + a support matrix for our
> existing adapters.
>
> Feel free to add any missing feature, it's a really early version started a
> few hours ago,
>
> Sebi
> [1]
>
> https://docs.google.com/a/redhat.com/spreadsheets/d/13muhHORqIF11UeNbZIbbBzlh3FCef5BwKj2G2exLbYM/edit?usp=sharing
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Fri May 19 09:01:50 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 19 May 2017 10:01:50 -0300
Subject: [keycloak-dev] Authorization with Springboot adapter
In-Reply-To: <CAJrcDBdU2B1o9=HXv9-oRUz2fi3VoMSDS7ZUJr0KeGopQYbq0Q@mail.gmail.com>
References: <SY3PR01MB082772F9A0C751CDD4D8B4B0AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<SY3PR01MB08277428E0AB524C2E5B15B2AFE40@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBer9qOWdX96SdK+Kh82Wg5dxbR__xr=-YFYbGfYZ74oBQ@mail.gmail.com>
	<CAJrcDBfnD-0Rn79hLkwqqxXqjJ3xGy+nDx2ykwxH24htZEBuUQ@mail.gmail.com>
	<CAJrcDBcChdB1pimX6qV714AFzfKigAmDwYEtK4vmuKpqA6B0Kg@mail.gmail.com>
	<SY3PR01MB0827A7BC808199ADB777DF20AFE50@SY3PR01MB0827.ausprd01.prod.outlook.com>
	<CAJrcDBdU2B1o9=HXv9-oRUz2fi3VoMSDS7ZUJr0KeGopQYbq0Q@mail.gmail.com>
Message-ID: <CAJrcDBdtY0yrj5t1BkvjrjdfBTXMApYyRvWQGzOWLrYHCYZAWg@mail.gmail.com>

I've created https://issues.jboss.org/browse/KEYCLOAK-4942 after talking
with Sebastien about some issues I'm facing when trying to use a
keycloak.json file with Spring Boot Adapter.

Fell free to watch that issue for updates.

On Fri, May 19, 2017 at 8:01 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> I'm not sure. But I will check if that is possible. If so, will update
> that quickstart to use keycloak.json instead.
>
> I'm also thinking about a another quickstart to demonstrate how to protect
> APIs in Spring Boot. The one I have is pretty much related with protecting
> web applications, but we probably need another one to also demonstrate
> API/service security.
>
> On Thu, May 18, 2017 at 10:19 PM, Crafton Williams <
> crafton.williams at qut.edu.au> wrote:
>
>> Hi Pedro:
>>
>>
>>
>> This is a huge help, thanks!
>>
>>
>>
>> A few questions though...is this is the only way to implement Authz with
>> keyclaok and springboot? Is it possible to use the
>> keycloak-spring-boot-adapter along with keycloak.json configured as a
>> policy enforcer? I found it to be a very nice way of separating the
>> security concern from the code itself.
>>
>>
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Crafton
>>
>>
>>
>>
>>
>> *From: *Pedro Igor Silva <psilva at redhat.com>
>> *Sent: *Friday, 19 May 2017 9:33 AM
>> *To: *Crafton Williams <crafton.williams at qut.edu.au>
>> *Cc: *keycloak-dev at lists.jboss.org
>> *Subject: *Re: [keycloak-dev] Authorization with Springboot adapter
>>
>>
>>
>> I've sent a PR [1] with a quickstart for Spring Boot. Will work with some
>> more examples covering specific features of Keycloak Authorization
>> Services.
>>
>>
>>
>> Please let me know what you think about it. It is basically a Spring Boot
>> Web application protected with simple fine-grained permissions.
>>
>>
>>
>> [1] https://github.com/keycloak/keycloak-quickstarts/pull/26
>>
>>
>>
>> Regards.
>> Pedro Igor
>>
>>
>>
>>
>>
>> On Thu, May 18, 2017 at 9:35 AM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>> Btw, you are not the first one asking for more details about Spring boot
>> integration. That is why I want to review this ....
>>
>>
>>
>> On Thu, May 18, 2017 at 9:34 AM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>> We are really missing examples and documentation to Spring Boot Adapter.
>> Will write an example/template and review docs.
>>
>>
>>
>> Can give you an answer right now because I've tested authz with spring
>> boot only a very few times. But you should not get this error at all.
>>
>>
>>
>> Will have something today.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, May 18, 2017 at 3:17 AM, Crafton Williams <
>> crafton.williams at qut.edu.au> wrote:
>>
>> Hi All:
>>
>> I?m trying to configure a basic springboot app using the springboot
>> keycloak adapter. Authentication works as expected but I?m a bit confused
>> as to how to configure the policy enforcer in yaml. The documentation shows
>> configuring the policy-enforcer as a json document however the springboot
>> config implies a only policy-enforcer-config. In any case, I did try the
>> json doc but it wasn?t picked up by the adapter.
>>
>> I?m using 3.0.0.Final and tried the following in my yaml file(omitted the
>> rest of the path info for brevity):
>>
>> Policy-enforcer-config:
>>   Enforcement-mode: ENFORCING
>>   paths:
>>
>>   *   name: blah
>>
>> The exception I got was:
>>
>> org.springframework.context.ApplicationContextException: Unable to start
>> embedded container; nested exception is org.springframework.beans.factory.BeanCreationException:
>> Error creating bean with name 'tomcatEmbeddedServletContainerFactory'
>> defined in class path resource [org/springframework/boot/auto
>> configure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]:
>> Initialization of bean failed; nested exception is
>> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
>> creating bean with name 'org.keycloak.adapters.springb
>> oot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed
>> through method 'setKeycloakSpringBootProperties' parameter 0; nested
>> exception is org.springframework.beans.factory.BeanCreationException:
>> Error creating bean with name 'keycloak-org.keycloak.adapter
>> s.springboot.KeycloakSpringBootProperties': Could not bind properties to
>> KeycloakSpringBootProperties (prefix=keycloak, ignoreInvalidFields=false,
>> ignoreUnknownFields=false, ignoreNestedProperties=false); nested exception
>> is org.springframework.beans.InvalidPropertyException: Invalid property
>> 'policyEnforcerConfig.paths[0]' of bean class
>> [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]: Illegal
>> attempt to get property 'paths' threw exception; nested exception is
>> java.lang.UnsupportedOperationException
>>
>> Is there an example project somewhere that can guide me in configuring
>> the policy enforcer for the springboot adapter?
>>
>> Cheers,
>>
>> Crafton
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

From bburke at redhat.com  Fri May 19 09:12:06 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 09:12:06 -0400
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
Message-ID: <7e6d04ee-a3fa-bf22-3321-07659c9c30f9@redhat.com>

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri May 19 09:21:28 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 09:21:28 -0400
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
Message-ID: <4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>

This issue comes up in:

* code to token

* refresh token

* backchannel logout

* access token validation (bearer token authentication)

* Authorization and RPT

* Token exchange

Any others?

We need to get on OIDC lists and discuss these types of issues so that 
they can get standardized.

Other thoughts:

* What if you talk to the node directly by providing a URL claim in the 
token or code? The issue with that is that since we derive a lot of 
things from the hostname of the request, we will need the ability to 
override this.


On 5/16/17 4:19 AM, Marek Posolda wrote:
> I was thinking about possibilities how to solve the issue with sticky
> sessions in backchannel requests. It seems that we need to support the
> scenarios, when backchannel requests won't be able to share the sticky
> session cookie with the browser. However in many cases it may be
> possible that backchannel requests can participate in the "sticky
> session", which will have great advantage for performance. Some thoughts:
>
> - OAuth code (the one used in code-to-token backchannel request) can be
> JWT signed by realm HMAC key. One of the claims in the code could be
> "route-id"
>
> - Refresh tokens will also contain "route-id" claim
>
> - Keycloak OIDC adapters will be able to read the "route-id" from the
> code and they will attach sticky session information to the single
> backchannel request. Hence the backchannel request will be able to
> participate in sticky session and will be properly routed by
> loadbalancer to the correct node. Same for requests using refresh token.
>
> - It seems we will need some flexibility how is the "sticky session"
> added to the request to support various loadbalancers (cookie,
> path-parameters etc). Maybe we need some SPI on adapter side? Or just
> some kind of expressions/tokens, which will help to configure how
> exactly will cookie/path parameter look like?
>
> - Keycloak.js adapter seems to be working already. Ajax requests are
> re-sending the browser cookies and they are available in backchannel
> endpoint on server-side. This is true even if AUTH_SESSION_ID cookie is
> httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not sure if
> this is different in other browsers/devices (cordova etc)?
>
> - For SAML backchannel requests (backchannel logout), we can add the
> same to our own SAML adapters though.
>
> - If people use 3rd party adapters, they won't have this. However we can
> also have support for some loadbalancers to route the requests directly
> based on the content of the route-id inside code (or refresh token). In
> many cases, customers will already have established loadbalancer in
> their deployments. However some others might be starting their
> deployment from the scratch and we can suggest them to use some of our
> preferred loadbalancers though.
>
> I've checked that if wildfly+mod_cluster is used as loadbalancer, we
> have the flexibility to inject custom undertow handler, which will be
> able to look into JWT and add the route info to the HttpServerExchange,
> from where mod_cluster will read it. Maybe we can investigate this
> possibility in the other popular loadbalancers (nginx etc) ?
>
> So in summary: Backchannel requests won't be able to participate in
> sticky session just if: 3rd party adapter is used AND customer can't use
> our preferred loadbalancer.
>
> WDYT?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mstrukel at redhat.com  Fri May 19 10:05:11 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 May 2017 16:05:11 +0200
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <c5fa8e21-3f68-202a-ac7e-5838815b5b12@redhat.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
	<CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
	<c5fa8e21-3f68-202a-ac7e-5838815b5b12@redhat.com>
Message-ID: <CA+1OW+g+41MwEDAiozHESG4PRsfuMrDrujLYYkTkpUCL=bMrtg@mail.gmail.com>

I believe nowadays the tech to use for such multiserver setups would be
Docker / OpenShift.

On May 19, 2017 14:50, "Stan Silvert" <ssilvert at redhat.com> wrote:

> On 5/19/2017 8:29 AM, Stian Thorgersen wrote:
> > I repeat - Quickstarts are to help people getting started securing
> > their own applications.
> >
> > What you are proposing will not help for that. We don't support
> > deploying apps directly to Keycloak. It's an SSO solution after all.
> > So it's just part of it running Keycloak on a different port or host.
> Also, I don't think I explained very well how this works.  There are two
> completely different servers that just happen to share the same /modules
> directory:
>
> /modules
> /standalone
> /keycloak
>
> >
> > On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com
> > <mailto:ssilvert at redhat.com>> wrote:
> >
> >     On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
> >>     That's rather off topic. Quickstarts is one thing and a
> >>     demo/example is another thing. Quickstarts is supposed to show
> >>     you how to get started with securing your apps with Keycloak.
> >>     What you are proposing is a nice option on just trying out
> >>     Keycloak, but it doesn't really help users getting started
> >>     properly with securing their apps.
> >     I disagree.  It would help tremendously. Right now, to get started
> >     securing your apps with the help of quickstart you must:
> >     1) Set up a Keycloak instance and understand that you need to run
> >     it on port 8180.
> >     2) Set up a Wildfly instance on port 8080.
> >     3) Find multiple json files that you need to import to Keycloak
> >     3.5) If you can't figure out what to import, follow the
> >     instructions to do Keycloak config by hand.
> >     4) Create keycloak.json files for each app and put them in the
> >     proper place.
> >     5) Do mvn wildfly:deploy for each app you want to run
> >     6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
> >     7) Try modifications to the quickstart apps so you can get an
> >     ideas about how you will secure your own apps
> >     8) Deploy your modifications
> >
> >     What I propose is that we get rid of steps 1 through 6.
> >     Quickstart doesn't help if you can't get to steps 7 and 8 "quickly".
> >
> >
> >>
> >>     On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com
> >>     <mailto:ssilvert at redhat.com>> wrote:
> >>
> >>         What we really need for the quickstarts is something Bill has
> >>         been
> >>         talking about for a long time.
> >>
> >>         It's a bundle of Keycloak and examples that just boots up and
> >>         works.
> >>         Otherwise, the quickstarts are way too hard to get running.
> >>         Nobody
> >>         wants to spend 2 or 3 hours on a "quickstart". That's what I
> >>         had to do
> >>         recently and I already know what's going on.  I hate to think
> >>         about what
> >>         someone new to Keycloak needs to go through just to see an
> >>         example.
> >>
> >>         This doesn't have to mean that everything runs in the same
> >>         WildFly
> >>         instance like the old demo dist.  The problem with that was
> >>         that it
> >>         didn't show Keycloak set up as a stand-alone server.
> >>
> >>         What you need is a single bundle that lets you run Keycloak
> >>         standalone
> >>         and a standalone app server.  I see a couple of ways to do it:
> >>         1) Use domain mode where you get a domain controller,
> >>         Keycloak instance,
> >>         and app server instance all in the same JVM.
> >>         2) Use two separate server configs and run in two JVM's.
> >>
> >>         I think #2 is the best.  The Keycloak instance runs on port
> >>         8180 and the
> >>         app server runs on 8080.  You only need one download of
> >>         WildFly/Keycloak, but you package it with two configs.  So
> >>         you have:
> >>         /bin
> >>         /modules
> >>         /domain (don't actually need this one)
> >>         /standalone
> >>         /keycloak
> >>
> >>         To run Keycloak (preloaded with quickstart realm):
> >>          > standalone --server-config=keycloak
> >>         -Djboss.socket.binding.port-offset=100
> >>
> >>         To run app server (preloaded with quickstart apps):
> >>          > standalone
> >>
> >>
> >>
> >>         On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
> >>         > Hmmm I'm not sure about that. That would be the completely
> >>         opposite of what
> >>         > we already do to any repository today. If people want the
> >>         stable release of
> >>         > the quickstarts they could just get 3.x or download the zip
> >>         files, nope?
> >>         >
> >>         > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
> >>         <sblanc at redhat.com <mailto:sblanc at redhat.com>> wrote:
> >>         >
> >>         >> We should also consider the opposite : master is the
> >>         stable released
> >>         >> version and a branch for development . I already had
> >>         confused people
> >>         >> downloading KC server and cloning the QuickStarts and
> >>         expecting it to work.
> >>         >> But tbh I do not have a string opinion on that.
> >>         >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira
> >>         <bruno at abstractj.org <mailto:bruno at abstractj.org>> a
> >>         >> ?crit :
> >>         >>
> >>         >>> While working today on the fix of some quickstarts. I'm
> >>         >>> considering to create a separated branch only for stable
> >>         versions of the
> >>         >>> quickstarts.
> >>         >>>
> >>         >>> In this way 'master' would be used only for development
> >>         based on the
> >>         >>> latest bits from Keycloak repo. And 3.1.x, to the latest
> >>         stable
> >>         >>> release on Maven central.
> >>         >>>
> >>         >>> Does it make any sense?
> >>         >>>
> >>         >>> --
> >>         >>>
> >>         >>> abstractj
> >>         >>>
> >>         >> _______________________________________________
> >>         >>> keycloak-dev mailing list
> >>         >>> keycloak-dev at lists.jboss.org
> >>         <mailto:keycloak-dev at 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 at lists.jboss.org
> >>         <mailto:keycloak-dev at 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 at lists.jboss.org
> >>         <mailto:keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Fri May 19 10:19:13 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 10:19:13 -0400
Subject: [keycloak-dev] questions on Marek/Hynek presentation
Message-ID: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>

* Won't the regular case be that the load balancer generates the 
affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite 
popular and they have both options.

* @ 18:25 in bluejeans session, The "You are already logged in" screen.  
What happens when the use clicks "proceed"?  Does the SAML or OIDC 
request continue as normal? Or are you calculating the URI on the 
application to redirect to, if so, why?

On Action Tokens:


* What is the relationship between the RequiredAction SPI and 
ActionTokenHandler SPI?  Does every RequiredAction have to have a 
corresponding ActionTokenHandler?

* Why would a app developer need to implement an ActionTokenHandler?  
Wouldn't it be better for the Required Action SPI to provide the 
appropriate metadata so that the handler could be implemented by us?  
i.e. isOneTimeToken, email-template, etc, etc.  I guess what I'm saying 
is that action tokens should be incorporated into the RequiredAction SPI.

* Related to above.  Required actions should be able to specify an 
"admin console template" and "login template".  These would be the 
freemarker template to use to create the email that is sent to the 
user.  "admin console" would be from an admin generating the action.  
"login" would be when user login initiates the action email.

* On the Admin Console "Credential Reset" section.  Required Action 
emails (now Action tokens) aren't necessarily "Credential Resets".  
Verify email is not a credential reset. etc. This need to be renamed and 
maybe put in another tab?

* We will need a way to offload action processing to another external 
service.  keycloak exists to mark that the action was completed, but all 
the processing for the action happens in an external application.  A lot 
of people have existing applications they want to integrate with that 
perform action processing.  Just something to think about.  We need this 
for other areas of keycloak (i.e. registration).



From mposolda at redhat.com  Fri May 19 10:21:57 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 16:21:57 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <7e6d04ee-a3fa-bf22-3321-07659c9c30f9@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<7e6d04ee-a3fa-bf22-3321-07659c9c30f9@redhat.com>
Message-ID: <422fcff5-233b-fe91-d331-61380a76ce03@redhat.com>

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Fri May 19 10:29:07 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 16:29:07 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>
Message-ID: <f48b359b-64dd-b409-bb2e-055bba29751c@redhat.com>

On 19/05/17 15:21, Bill Burke wrote:
> This issue comes up in:
>
> * code to token
>
> * refresh token
>
> * backchannel logout
>
> * access token validation (bearer token authentication)
>
> * Authorization and RPT
>
> * Token exchange
>
> Any others?
>
> We need to get on OIDC lists and discuss these types of issues so that
> they can get standardized.
Good point. I can try to start discussion there.
>
> Other thoughts:
>
> * What if you talk to the node directly by providing a URL claim in the
> token or code? The issue with that is that since we derive a lot of
> things from the hostname of the request, we will need the ability to
> override this.
You mean to bypass loadbalancer entirely and let the application talk to 
the backend node directly?

Besides the hostname issue, there is another one, that backend node may 
not be directly available. Those are typically on private networks and 
it can be different private network that application is using. That was 
the case for example in RedHat IT environment.

BTV. We already had similar possibility in adapter to directly talk to 
backend node in backchannel requests. Instead of lookup the backend node 
URL from claim, we had the option in adapter configuration 
"auth-server-url-for-backend-requests" . But the option was removed due 
those issues like hostname, verifications of "iss" claim in tokens etc.

Marek
>
>
> On 5/16/17 4:19 AM, Marek Posolda wrote:
>> I was thinking about possibilities how to solve the issue with sticky
>> sessions in backchannel requests. It seems that we need to support the
>> scenarios, when backchannel requests won't be able to share the sticky
>> session cookie with the browser. However in many cases it may be
>> possible that backchannel requests can participate in the "sticky
>> session", which will have great advantage for performance. Some thoughts:
>>
>> - OAuth code (the one used in code-to-token backchannel request) can be
>> JWT signed by realm HMAC key. One of the claims in the code could be
>> "route-id"
>>
>> - Refresh tokens will also contain "route-id" claim
>>
>> - Keycloak OIDC adapters will be able to read the "route-id" from the
>> code and they will attach sticky session information to the single
>> backchannel request. Hence the backchannel request will be able to
>> participate in sticky session and will be properly routed by
>> loadbalancer to the correct node. Same for requests using refresh token.
>>
>> - It seems we will need some flexibility how is the "sticky session"
>> added to the request to support various loadbalancers (cookie,
>> path-parameters etc). Maybe we need some SPI on adapter side? Or just
>> some kind of expressions/tokens, which will help to configure how
>> exactly will cookie/path parameter look like?
>>
>> - Keycloak.js adapter seems to be working already. Ajax requests are
>> re-sending the browser cookies and they are available in backchannel
>> endpoint on server-side. This is true even if AUTH_SESSION_ID cookie is
>> httpOnly. I've tested with Firefox, Chrome, my mobile phone. Not sure if
>> this is different in other browsers/devices (cordova etc)?
>>
>> - For SAML backchannel requests (backchannel logout), we can add the
>> same to our own SAML adapters though.
>>
>> - If people use 3rd party adapters, they won't have this. However we can
>> also have support for some loadbalancers to route the requests directly
>> based on the content of the route-id inside code (or refresh token). In
>> many cases, customers will already have established loadbalancer in
>> their deployments. However some others might be starting their
>> deployment from the scratch and we can suggest them to use some of our
>> preferred loadbalancers though.
>>
>> I've checked that if wildfly+mod_cluster is used as loadbalancer, we
>> have the flexibility to inject custom undertow handler, which will be
>> able to look into JWT and add the route info to the HttpServerExchange,
>> from where mod_cluster will read it. Maybe we can investigate this
>> possibility in the other popular loadbalancers (nginx etc) ?
>>
>> So in summary: Backchannel requests won't be able to participate in
>> sticky session just if: 3rd party adapter is used AND customer can't use
>> our preferred loadbalancer.
>>
>> WDYT?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bburke at redhat.com  Fri May 19 10:31:47 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 10:31:47 -0400
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <f48b359b-64dd-b409-bb2e-055bba29751c@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>
	<f48b359b-64dd-b409-bb2e-055bba29751c@redhat.com>
Message-ID: <ccd81a61-9a52-5b81-1564-4c61668a922d@redhat.com>



On 5/19/17 10:29 AM, Marek Posolda wrote:
> On 19/05/17 15:21, Bill Burke wrote:
>> This issue comes up in:
>>
>> * code to token
>>
>> * refresh token
>>
>> * backchannel logout
>>
>> * access token validation (bearer token authentication)
>>
>> * Authorization and RPT
>>
>> * Token exchange
>>
>> Any others?
>>
>> We need to get on OIDC lists and discuss these types of issues so that
>> they can get standardized.
> Good point. I can try to start discussion there.
>>
>> Other thoughts:
>>
>> * What if you talk to the node directly by providing a URL claim in the
>> token or code? The issue with that is that since we derive a lot of
>> things from the hostname of the request, we will need the ability to
>> override this.
> You mean to bypass loadbalancer entirely and let the application talk 
> to the backend node directly?
>
> Besides the hostname issue, there is another one, that backend node 
> may not be directly available. Those are typically on private networks 
> and it can be different private network that application is using. 
> That was the case for example in RedHat IT environment.
>
> BTV. We already had similar possibility in adapter to directly talk to 
> backend node in backchannel requests. Instead of lookup the backend 
> node URL from claim, we had the option in adapter configuration 
> "auth-server-url-for-backend-requests" . But the option was removed 
> due those issues like hostname, verifications of "iss" claim in tokens 
> etc.
>

Backchannel sticky session becomes quite difficult if you can't talk to 
node directly. Adapter will have to know to set a cookie that the 
loadbalancer can handle.  If the load balancer is using client IP to 
loadbalance, then you are SOL.

Bill

From mposolda at redhat.com  Fri May 19 10:57:10 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 16:57:10 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
Message-ID: <a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>

On 19/05/17 16:19, Bill Burke wrote:
> * Won't the regular case be that the load balancer generates the
> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
> popular and they have both options.
Yes, that's also what Sebastien Schuster from community mentioned in 
other thread. That's why I've added StickySessionEncoderProvider as SPI, 
so it's easily possible to disable Keycloak adding route to the cookie, 
or sticky request based on something different than cookie (eg. path 
parameter).

However having Keycloak itself to choose the route has one big 
performance advantage, that it can route to the node, who is owner of 
the entry in the infinispan distributed cache. This includes also 
support for rebalance (owner may change when new node joins/leaves 
cluster, then you change route automatically). This is what Wildfly is 
doing for Http sessions too.

We discussed the integration with KeyAffinityService [1], which helps 
with usecase when loadbalancer generates route to the cookie. It ensures 
that generated session ID will be local to current node. Hence 
loadbalancer can use request node as the route and session will be local 
to it. But this doesn't handle rebalance, so IMO preferred option is 
still to let Keycloak to append route.

There is also infinispan grouping API I want to look at.

[1] 
http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
> What happens when the use clicks "proceed"?  Does the SAML or OIDC
> request continue as normal? Or are you calculating the URI on the
> application to redirect to, if so, why?
No, this is just link to client base URI, and then new flow can be 
started from the application. ATM authenticationSession may be already 
removed as user logged already in different browser tab etc, so there is 
no flow to continue with.

Currently there is just userSession available and the client application 
used for "Back to application" is the last authenticated client in 
userSession. I am going to improve it and use "client_id" parameter in 
requests, so in case of expired session, already authentication session 
etc, you would always know the client from the "client_id" parameter. 
Details in the other ML thread "Provide a Link to go Back to The 
Application on a Timeout" .

Marek
>
> On Action Tokens:
>
>
> * What is the relationship between the RequiredAction SPI and
> ActionTokenHandler SPI?  Does every RequiredAction have to have a
> corresponding ActionTokenHandler?
>
> * Why would a app developer need to implement an ActionTokenHandler?
> Wouldn't it be better for the Required Action SPI to provide the
> appropriate metadata so that the handler could be implemented by us?
> i.e. isOneTimeToken, email-template, etc, etc.  I guess what I'm saying
> is that action tokens should be incorporated into the RequiredAction SPI.
>
> * Related to above.  Required actions should be able to specify an
> "admin console template" and "login template".  These would be the
> freemarker template to use to create the email that is sent to the
> user.  "admin console" would be from an admin generating the action.
> "login" would be when user login initiates the action email.
>
> * On the Admin Console "Credential Reset" section.  Required Action
> emails (now Action tokens) aren't necessarily "Credential Resets".
> Verify email is not a credential reset. etc. This need to be renamed and
> maybe put in another tab?
>
> * We will need a way to offload action processing to another external
> service.  keycloak exists to mark that the action was completed, but all
> the processing for the action happens in an external application.  A lot
> of people have existing applications they want to integrate with that
> perform action processing.  Just something to think about.  We need this
> for other areas of keycloak (i.e. registration).
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bburke at redhat.com  Fri May 19 10:58:50 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 10:58:50 -0400
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
Message-ID: <0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>



On 5/19/17 10:57 AM, Marek Posolda wrote:
> On 19/05/17 16:19, Bill Burke wrote:
>> * Won't the regular case be that the load balancer generates the
>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>> popular and they have both options.
> Yes, that's also what Sebastien Schuster from community mentioned in 
> other thread. That's why I've added StickySessionEncoderProvider as 
> SPI, so it's easily possible to disable Keycloak adding route to the 
> cookie, or sticky request based on something different than cookie 
> (eg. path parameter).
>
> However having Keycloak itself to choose the route has one big 
> performance advantage, that it can route to the node, who is owner of 
> the entry in the infinispan distributed cache. This includes also 
> support for rebalance (owner may change when new node joins/leaves 
> cluster, then you change route automatically). This is what Wildfly is 
> doing for Http sessions too.
>
> We discussed the integration with KeyAffinityService [1], which helps 
> with usecase when loadbalancer generates route to the cookie. It 
> ensures that generated session ID will be local to current node. Hence 
> loadbalancer can use request node as the route and session will be 
> local to it. But this doesn't handle rebalance, so IMO preferred 
> option is still to let Keycloak to append route.
>
> There is also infinispan grouping API I want to look at.
>
> [1] 
> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>> request continue as normal? Or are you calculating the URI on the
>> application to redirect to, if so, why?
> No, this is just link to client base URI, and then new flow can be 
> started from the application. ATM authenticationSession may be already 
> removed as user logged already in different browser tab etc, so there 
> is no flow to continue with.
>
> Currently there is just userSession available and the client 
> application used for "Back to application" is the last authenticated 
> client in userSession. I am going to improve it and use "client_id" 
> parameter in requests, so in case of expired session, already 
> authentication session etc, you would always know the client from the 
> "client_id" parameter. Details in the other ML thread "Provide a Link 
> to go Back to The Application on a Timeout" .
>

Why do you need this page?  Why can't you just proceed with the 
OIDC/SAML protocol?

Bill

From mposolda at redhat.com  Fri May 19 11:08:19 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 17:08:19 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <ccd81a61-9a52-5b81-1564-4c61668a922d@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>
	<f48b359b-64dd-b409-bb2e-055bba29751c@redhat.com>
	<ccd81a61-9a52-5b81-1564-4c61668a922d@redhat.com>
Message-ID: <d82e7714-9ed2-bbf2-a685-1c835e570fcc@redhat.com>

On 19/05/17 16:31, Bill Burke wrote:
>
>
> On 5/19/17 10:29 AM, Marek Posolda wrote:
>> On 19/05/17 15:21, Bill Burke wrote:
>>> This issue comes up in:
>>>
>>> * code to token
>>>
>>> * refresh token
>>>
>>> * backchannel logout
>>>
>>> * access token validation (bearer token authentication)
>>>
>>> * Authorization and RPT
>>>
>>> * Token exchange
>>>
>>> Any others?
>>>
>>> We need to get on OIDC lists and discuss these types of issues so that
>>> they can get standardized.
>> Good point. I can try to start discussion there.
>>>
>>> Other thoughts:
>>>
>>> * What if you talk to the node directly by providing a URL claim in the
>>> token or code? The issue with that is that since we derive a lot of
>>> things from the hostname of the request, we will need the ability to
>>> override this.
>> You mean to bypass loadbalancer entirely and let the application talk 
>> to the backend node directly?
>>
>> Besides the hostname issue, there is another one, that backend node 
>> may not be directly available. Those are typically on private 
>> networks and it can be different private network that application is 
>> using. That was the case for example in RedHat IT environment.
>>
>> BTV. We already had similar possibility in adapter to directly talk 
>> to backend node in backchannel requests. Instead of lookup the 
>> backend node URL from claim, we had the option in adapter 
>> configuration "auth-server-url-for-backend-requests" . But the option 
>> was removed due those issues like hostname, verifications of "iss" 
>> claim in tokens etc.
>>
>
> Backchannel sticky session becomes quite difficult if you can't talk 
> to node directly. Adapter will have to know to set a cookie that the 
> loadbalancer can handle.  If the load balancer is using client IP to 
> loadbalance, then you are SOL.
Yes, that's the pain with no easy solution. There is no standard for 
loadbalancers and we don't know if people use private networks for 
backend nodes or not etc :( Support for cookie in the adapter request is 
the option I would like to go, we agreed so far in different thread on 
ML. For loadbalancing on client IP not sure we can handle that. Maybe 
use "client-ip" as the claim in code or token and do some hacking around 
"X-" http headers in the adapter request to Keycloak?

Talking application to backend node directly has issues and AFAIK Stian 
don't like this option at all. Hostname issues, backend node not 
available to the app etc. Perhaps he can add more.

Marek

>
> Bill



From mposolda at redhat.com  Fri May 19 11:25:07 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 17:25:07 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
Message-ID: <737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>

On 19/05/17 16:58, Bill Burke wrote:
>
>
>
> On 5/19/17 10:57 AM, Marek Posolda wrote:
>> On 19/05/17 16:19, Bill Burke wrote:
>>> * Won't the regular case be that the load balancer generates the
>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>> popular and they have both options.
>> Yes, that's also what Sebastien Schuster from community mentioned in 
>> other thread. That's why I've added StickySessionEncoderProvider as 
>> SPI, so it's easily possible to disable Keycloak adding route to the 
>> cookie, or sticky request based on something different than cookie 
>> (eg. path parameter).
>>
>> However having Keycloak itself to choose the route has one big 
>> performance advantage, that it can route to the node, who is owner of 
>> the entry in the infinispan distributed cache. This includes also 
>> support for rebalance (owner may change when new node joins/leaves 
>> cluster, then you change route automatically). This is what Wildfly 
>> is doing for Http sessions too.
>>
>> We discussed the integration with KeyAffinityService [1], which helps 
>> with usecase when loadbalancer generates route to the cookie. It 
>> ensures that generated session ID will be local to current node. 
>> Hence loadbalancer can use request node as the route and session will 
>> be local to it. But this doesn't handle rebalance, so IMO preferred 
>> option is still to let Keycloak to append route.
>>
>> There is also infinispan grouping API I want to look at.
>>
>> [1] 
>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>> request continue as normal? Or are you calculating the URI on the
>>> application to redirect to, if so, why?
>> No, this is just link to client base URI, and then new flow can be 
>> started from the application. ATM authenticationSession may be 
>> already removed as user logged already in different browser tab etc, 
>> so there is no flow to continue with.
>>
>> Currently there is just userSession available and the client 
>> application used for "Back to application" is the last authenticated 
>> client in userSession. I am going to improve it and use "client_id" 
>> parameter in requests, so in case of expired session, already 
>> authentication session etc, you would always know the client from the 
>> "client_id" parameter. Details in the other ML thread "Provide a Link 
>> to go Back to The Application on a Timeout" .
>>
>
> Why do you need this page?  Why can't you just proceed with the 
> OIDC/SAML protocol?
You mean redirect automatically to the client, which will start new 
OIDC/SAML flow and then authenticate you automatically due to SSO?

Yes, in cases like our admin console, it will be better behaviour then 
showing "You are already logged in" . But that's just because client 
base URI, (or client redirect URI) are secured URLs and automatically 
redirects to Keycloak and starts the flow.

But in many applications, this is not the case. For example, you have 
single page JS application on "http://host/js-app", which is itself not 
secured URL. So after confirm the expired username/password form, you 
would redirect to the "http://host/js-app", but you won't be 
authenticated there. This looks like quite confusing behaviour for the 
user IMO.

Showing "You are already logged in" looks like good compromise. In many 
cases it is just additional splash screen, but at least it don't confuse 
users in case that client redirect URI are not secured URLs.

Marek
>
> Bill



From bburke at redhat.com  Fri May 19 11:28:31 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 11:28:31 -0400
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
	<737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
Message-ID: <62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>



On 5/19/17 11:25 AM, Marek Posolda wrote:
> On 19/05/17 16:58, Bill Burke wrote:
>>
>>
>>
>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>> On 19/05/17 16:19, Bill Burke wrote:
>>>> * Won't the regular case be that the load balancer generates the
>>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>>> popular and they have both options.
>>> Yes, that's also what Sebastien Schuster from community mentioned in 
>>> other thread. That's why I've added StickySessionEncoderProvider as 
>>> SPI, so it's easily possible to disable Keycloak adding route to the 
>>> cookie, or sticky request based on something different than cookie 
>>> (eg. path parameter).
>>>
>>> However having Keycloak itself to choose the route has one big 
>>> performance advantage, that it can route to the node, who is owner 
>>> of the entry in the infinispan distributed cache. This includes also 
>>> support for rebalance (owner may change when new node joins/leaves 
>>> cluster, then you change route automatically). This is what Wildfly 
>>> is doing for Http sessions too.
>>>
>>> We discussed the integration with KeyAffinityService [1], which 
>>> helps with usecase when loadbalancer generates route to the cookie. 
>>> It ensures that generated session ID will be local to current node. 
>>> Hence loadbalancer can use request node as the route and session 
>>> will be local to it. But this doesn't handle rebalance, so IMO 
>>> preferred option is still to let Keycloak to append route.
>>>
>>> There is also infinispan grouping API I want to look at.
>>>
>>> [1] 
>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>>> request continue as normal? Or are you calculating the URI on the
>>>> application to redirect to, if so, why?
>>> No, this is just link to client base URI, and then new flow can be 
>>> started from the application. ATM authenticationSession may be 
>>> already removed as user logged already in different browser tab etc, 
>>> so there is no flow to continue with.
>>>
>>> Currently there is just userSession available and the client 
>>> application used for "Back to application" is the last authenticated 
>>> client in userSession. I am going to improve it and use "client_id" 
>>> parameter in requests, so in case of expired session, already 
>>> authentication session etc, you would always know the client from 
>>> the "client_id" parameter. Details in the other ML thread "Provide a 
>>> Link to go Back to The Application on a Timeout" .
>>>
>>
>> Why do you need this page?  Why can't you just proceed with the 
>> OIDC/SAML protocol?
> You mean redirect automatically to the client, which will start new 
> OIDC/SAML flow and then authenticate you automatically due to SSO?
>
> Yes, in cases like our admin console, it will be better behaviour then 
> showing "You are already logged in" . But that's just because client 
> base URI, (or client redirect URI) are secured URLs and automatically 
> redirects to Keycloak and starts the flow.
>
> But in many applications, this is not the case. For example, you have 
> single page JS application on "http://host/js-app", which is itself 
> not secured URL. So after confirm the expired username/password form, 
> you would redirect to the "http://host/js-app", but you won't be 
> authenticated there. This looks like quite confusing behaviour for the 
> user IMO.
>
> Showing "You are already logged in" looks like good compromise. In 
> many cases it is just additional splash screen, but at least it don't 
> confuse users in case that client redirect URI are not secured URLs.
>
Not following.  Maybe i need to review the presentation again as maybe 
I'm confused when the "already logged in" screen is shown.

Bill

From mposolda at redhat.com  Fri May 19 11:36:26 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 17:36:26 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
	<737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
	<62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>
Message-ID: <3c6c6484-7329-f73c-b4e2-0d27d7692729@redhat.com>

On 19/05/17 17:28, Bill Burke wrote:
>
>
>
> On 5/19/17 11:25 AM, Marek Posolda wrote:
>> On 19/05/17 16:58, Bill Burke wrote:
>>>
>>>
>>>
>>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>>> On 19/05/17 16:19, Bill Burke wrote:
>>>>> * Won't the regular case be that the load balancer generates the
>>>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>>>> popular and they have both options.
>>>> Yes, that's also what Sebastien Schuster from community mentioned 
>>>> in other thread. That's why I've added StickySessionEncoderProvider 
>>>> as SPI, so it's easily possible to disable Keycloak adding route to 
>>>> the cookie, or sticky request based on something different than 
>>>> cookie (eg. path parameter).
>>>>
>>>> However having Keycloak itself to choose the route has one big 
>>>> performance advantage, that it can route to the node, who is owner 
>>>> of the entry in the infinispan distributed cache. This includes 
>>>> also support for rebalance (owner may change when new node 
>>>> joins/leaves cluster, then you change route automatically). This is 
>>>> what Wildfly is doing for Http sessions too.
>>>>
>>>> We discussed the integration with KeyAffinityService [1], which 
>>>> helps with usecase when loadbalancer generates route to the cookie. 
>>>> It ensures that generated session ID will be local to current node. 
>>>> Hence loadbalancer can use request node as the route and session 
>>>> will be local to it. But this doesn't handle rebalance, so IMO 
>>>> preferred option is still to let Keycloak to append route.
>>>>
>>>> There is also infinispan grouping API I want to look at.
>>>>
>>>> [1] 
>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>>>> request continue as normal? Or are you calculating the URI on the
>>>>> application to redirect to, if so, why?
>>>> No, this is just link to client base URI, and then new flow can be 
>>>> started from the application. ATM authenticationSession may be 
>>>> already removed as user logged already in different browser tab 
>>>> etc, so there is no flow to continue with.
>>>>
>>>> Currently there is just userSession available and the client 
>>>> application used for "Back to application" is the last 
>>>> authenticated client in userSession. I am going to improve it and 
>>>> use "client_id" parameter in requests, so in case of expired 
>>>> session, already authentication session etc, you would always know 
>>>> the client from the "client_id" parameter. Details in the other ML 
>>>> thread "Provide a Link to go Back to The Application on a Timeout" .
>>>>
>>>
>>> Why do you need this page?  Why can't you just proceed with the 
>>> OIDC/SAML protocol?
>> You mean redirect automatically to the client, which will start new 
>> OIDC/SAML flow and then authenticate you automatically due to SSO?
>>
>> Yes, in cases like our admin console, it will be better behaviour 
>> then showing "You are already logged in" . But that's just because 
>> client base URI, (or client redirect URI) are secured URLs and 
>> automatically redirects to Keycloak and starts the flow.
>>
>> But in many applications, this is not the case. For example, you have 
>> single page JS application on "http://host/js-app", which is itself 
>> not secured URL. So after confirm the expired username/password form, 
>> you would redirect to the "http://host/js-app", but you won't be 
>> authenticated there. This looks like quite confusing behaviour for 
>> the user IMO.
>>
>> Showing "You are already logged in" looks like good compromise. In 
>> many cases it is just additional splash screen, but at least it don't 
>> confuse users in case that client redirect URI are not secured URLs.
>>
> Not following.  Maybe i need to review the presentation again as maybe 
> I'm confused when the "already logged in" screen is shown.
Easy to reproduce:
- Go to "http://localhost:8181/auth/admin" in browser tab 1
- Open tab 2 and go again to "http://localhost:8181/auth/admin" here
- Finish login as admin/admin in tab 2. You are logged in admin console
- Go back to tab 1 and try to login as admin/admin again. Now it's 
displayed "You are already logged in" .

- When you continue and click on "Back to application" you are 
automatically logged in in admin console. In case of our admin console, 
it will be better to not show the screen as the client URL 
"http://localhost:8181/auth/admin/master/console/index.html" is secured 
and automatically redirects to Keycloak and starts new flow.

However in other application, which don't have this behaviour (eg. the 
"js-console" example from our examples distribution), then automatically 
redirect to "http://localhost:8181/js-console" will just show you the 
application page, but you won't be authenticated at all, as new flow for 
SSO login won't start. This is what looks like confusing behaviour for 
users IMO.

Marek

>
> Bill



From bburke at redhat.com  Fri May 19 11:37:55 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 11:37:55 -0400
Subject: [keycloak-dev] Don't import * please!
Message-ID: <77a3de77-f04a-6077-4058-700419218334@redhat.com>

Please make your IDE import the full classname.  This is not allowed:

import java.uti.*;

All imports must be fully qualified.  A number of people are making this 
mistake lately.

Thanks,

Bill


From bburke at redhat.com  Fri May 19 11:40:06 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 May 2017 11:40:06 -0400
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <3c6c6484-7329-f73c-b4e2-0d27d7692729@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
	<737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
	<62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>
	<3c6c6484-7329-f73c-b4e2-0d27d7692729@redhat.com>
Message-ID: <d805ff8d-fddc-abb9-cc8e-1afb44eacd09@redhat.com>



On 5/19/17 11:36 AM, Marek Posolda wrote:
> On 19/05/17 17:28, Bill Burke wrote:
>>
>>
>>
>> On 5/19/17 11:25 AM, Marek Posolda wrote:
>>> On 19/05/17 16:58, Bill Burke wrote:
>>>>
>>>>
>>>>
>>>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>>>> On 19/05/17 16:19, Bill Burke wrote:
>>>>>> * Won't the regular case be that the load balancer generates the
>>>>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>>>>> popular and they have both options.
>>>>> Yes, that's also what Sebastien Schuster from community mentioned 
>>>>> in other thread. That's why I've added 
>>>>> StickySessionEncoderProvider as SPI, so it's easily possible to 
>>>>> disable Keycloak adding route to the cookie, or sticky request 
>>>>> based on something different than cookie (eg. path parameter).
>>>>>
>>>>> However having Keycloak itself to choose the route has one big 
>>>>> performance advantage, that it can route to the node, who is owner 
>>>>> of the entry in the infinispan distributed cache. This includes 
>>>>> also support for rebalance (owner may change when new node 
>>>>> joins/leaves cluster, then you change route automatically). This 
>>>>> is what Wildfly is doing for Http sessions too.
>>>>>
>>>>> We discussed the integration with KeyAffinityService [1], which 
>>>>> helps with usecase when loadbalancer generates route to the 
>>>>> cookie. It ensures that generated session ID will be local to 
>>>>> current node. Hence loadbalancer can use request node as the route 
>>>>> and session will be local to it. But this doesn't handle 
>>>>> rebalance, so IMO preferred option is still to let Keycloak to 
>>>>> append route.
>>>>>
>>>>> There is also infinispan grouping API I want to look at.
>>>>>
>>>>> [1] 
>>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>>>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>>>>> request continue as normal? Or are you calculating the URI on the
>>>>>> application to redirect to, if so, why?
>>>>> No, this is just link to client base URI, and then new flow can be 
>>>>> started from the application. ATM authenticationSession may be 
>>>>> already removed as user logged already in different browser tab 
>>>>> etc, so there is no flow to continue with.
>>>>>
>>>>> Currently there is just userSession available and the client 
>>>>> application used for "Back to application" is the last 
>>>>> authenticated client in userSession. I am going to improve it and 
>>>>> use "client_id" parameter in requests, so in case of expired 
>>>>> session, already authentication session etc, you would always know 
>>>>> the client from the "client_id" parameter. Details in the other ML 
>>>>> thread "Provide a Link to go Back to The Application on a Timeout" .
>>>>>
>>>>
>>>> Why do you need this page?  Why can't you just proceed with the 
>>>> OIDC/SAML protocol?
>>> You mean redirect automatically to the client, which will start new 
>>> OIDC/SAML flow and then authenticate you automatically due to SSO?
>>>
>>> Yes, in cases like our admin console, it will be better behaviour 
>>> then showing "You are already logged in" . But that's just because 
>>> client base URI, (or client redirect URI) are secured URLs and 
>>> automatically redirects to Keycloak and starts the flow.
>>>
>>> But in many applications, this is not the case. For example, you 
>>> have single page JS application on "http://host/js-app", which is 
>>> itself not secured URL. So after confirm the expired 
>>> username/password form, you would redirect to the 
>>> "http://host/js-app", but you won't be authenticated there. This 
>>> looks like quite confusing behaviour for the user IMO.
>>>
>>> Showing "You are already logged in" looks like good compromise. In 
>>> many cases it is just additional splash screen, but at least it 
>>> don't confuse users in case that client redirect URI are not secured 
>>> URLs.
>>>
>> Not following.  Maybe i need to review the presentation again as 
>> maybe I'm confused when the "already logged in" screen is shown.
> Easy to reproduce:
> - Go to "http://localhost:8181/auth/admin" in browser tab 1
> - Open tab 2 and go again to "http://localhost:8181/auth/admin" here
> - Finish login as admin/admin in tab 2. You are logged in admin console
> - Go back to tab 1 and try to login as admin/admin again. Now it's 
> displayed "You are already logged in" .
>
Why does this happen?  Why can't Keycloak just finish the OIDC 
protocol?  Is it because you don't want to ignore the username/password 
screen?

Bill

From mposolda at redhat.com  Fri May 19 11:53:49 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 17:53:49 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <d805ff8d-fddc-abb9-cc8e-1afb44eacd09@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
	<737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
	<62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>
	<3c6c6484-7329-f73c-b4e2-0d27d7692729@redhat.com>
	<d805ff8d-fddc-abb9-cc8e-1afb44eacd09@redhat.com>
Message-ID: <f737658d-8ae4-e688-d481-796db67d0283@redhat.com>

On 19/05/17 17:40, Bill Burke wrote:
>
>
>
> On 5/19/17 11:36 AM, Marek Posolda wrote:
>> On 19/05/17 17:28, Bill Burke wrote:
>>>
>>>
>>>
>>> On 5/19/17 11:25 AM, Marek Posolda wrote:
>>>> On 19/05/17 16:58, Bill Burke wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>>>>> On 19/05/17 16:19, Bill Burke wrote:
>>>>>>> * Won't the regular case be that the load balancer generates the
>>>>>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>>>>>> popular and they have both options.
>>>>>> Yes, that's also what Sebastien Schuster from community mentioned 
>>>>>> in other thread. That's why I've added 
>>>>>> StickySessionEncoderProvider as SPI, so it's easily possible to 
>>>>>> disable Keycloak adding route to the cookie, or sticky request 
>>>>>> based on something different than cookie (eg. path parameter).
>>>>>>
>>>>>> However having Keycloak itself to choose the route has one big 
>>>>>> performance advantage, that it can route to the node, who is 
>>>>>> owner of the entry in the infinispan distributed cache. This 
>>>>>> includes also support for rebalance (owner may change when new 
>>>>>> node joins/leaves cluster, then you change route automatically). 
>>>>>> This is what Wildfly is doing for Http sessions too.
>>>>>>
>>>>>> We discussed the integration with KeyAffinityService [1], which 
>>>>>> helps with usecase when loadbalancer generates route to the 
>>>>>> cookie. It ensures that generated session ID will be local to 
>>>>>> current node. Hence loadbalancer can use request node as the 
>>>>>> route and session will be local to it. But this doesn't handle 
>>>>>> rebalance, so IMO preferred option is still to let Keycloak to 
>>>>>> append route.
>>>>>>
>>>>>> There is also infinispan grouping API I want to look at.
>>>>>>
>>>>>> [1] 
>>>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>>>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>>>>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>>>>>> request continue as normal? Or are you calculating the URI on the
>>>>>>> application to redirect to, if so, why?
>>>>>> No, this is just link to client base URI, and then new flow can 
>>>>>> be started from the application. ATM authenticationSession may be 
>>>>>> already removed as user logged already in different browser tab 
>>>>>> etc, so there is no flow to continue with.
>>>>>>
>>>>>> Currently there is just userSession available and the client 
>>>>>> application used for "Back to application" is the last 
>>>>>> authenticated client in userSession. I am going to improve it and 
>>>>>> use "client_id" parameter in requests, so in case of expired 
>>>>>> session, already authentication session etc, you would always 
>>>>>> know the client from the "client_id" parameter. Details in the 
>>>>>> other ML thread "Provide a Link to go Back to The Application on 
>>>>>> a Timeout" .
>>>>>>
>>>>>
>>>>> Why do you need this page?  Why can't you just proceed with the 
>>>>> OIDC/SAML protocol?
>>>> You mean redirect automatically to the client, which will start new 
>>>> OIDC/SAML flow and then authenticate you automatically due to SSO?
>>>>
>>>> Yes, in cases like our admin console, it will be better behaviour 
>>>> then showing "You are already logged in" . But that's just because 
>>>> client base URI, (or client redirect URI) are secured URLs and 
>>>> automatically redirects to Keycloak and starts the flow.
>>>>
>>>> But in many applications, this is not the case. For example, you 
>>>> have single page JS application on "http://host/js-app", which is 
>>>> itself not secured URL. So after confirm the expired 
>>>> username/password form, you would redirect to the 
>>>> "http://host/js-app", but you won't be authenticated there. This 
>>>> looks like quite confusing behaviour for the user IMO.
>>>>
>>>> Showing "You are already logged in" looks like good compromise. In 
>>>> many cases it is just additional splash screen, but at least it 
>>>> don't confuse users in case that client redirect URI are not 
>>>> secured URLs.
>>>>
>>> Not following.  Maybe i need to review the presentation again as 
>>> maybe I'm confused when the "already logged in" screen is shown.
>> Easy to reproduce:
>> - Go to "http://localhost:8181/auth/admin" in browser tab 1
>> - Open tab 2 and go again to "http://localhost:8181/auth/admin" here
>> - Finish login as admin/admin in tab 2. You are logged in admin console
>> - Go back to tab 1 and try to login as admin/admin again. Now it's 
>> displayed "You are already logged in" .
>>
> Why does this happen?  Why can't Keycloak just finish the OIDC 
> protocol?  Is it because you don't want to ignore the 
> username/password screen?
The authenticationSession doesn't exists. It was already logged-in. Now 
we have single authenticationSession in the browser as it's tracked with 
the cookie. Support for more authentication sessions within browser can 
be done, but will be quite tricky with tracking session by the cookie 
and not sure it worth the effort for the corner cases like this?

Previous behaviour had more clientSessions in different browser tabs. So 
login in 2 tabs was possible, but after login in tab2, it created 
another userSession and overwrite the previous userSession including 
cookies etc. This had other issues like mentioned in this JIRA 
https://issues.jboss.org/browse/KEYCLOAK-4097

Marek
>
> Bill



From ssilvert at redhat.com  Fri May 19 12:55:29 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 May 2017 12:55:29 -0400
Subject: [keycloak-dev] Branches for the quickstarts
In-Reply-To: <CA+1OW+g+41MwEDAiozHESG4PRsfuMrDrujLYYkTkpUCL=bMrtg@mail.gmail.com>
References: <20170518165723.GA21137@abstractj.org>
	<CAMZCGg8X-G7e9aqyc=pfM6iB9mdpFaEUBoF8MdvrU8v6sPSwfg@mail.gmail.com>
	<CAM5SUC6ntzxj3qmRUKeRUsEnbvBvnzQNwK6eJ1jg6rgqXQLZHA@mail.gmail.com>
	<ecab954f-a2ed-1d38-3c50-93369da31fb4@redhat.com>
	<CAJgngAckuDSec6O46jb_TP+LuuBAV2BpDMr4Snxdew01+_Mj3Q@mail.gmail.com>
	<7e9627ee-20ac-c851-dfdd-c4d9580add84@redhat.com>
	<CAJgngAcKKKji4o0kCKp-kVD5VuMFQ-oibnW5-TW_Xvw4Dsk1FA@mail.gmail.com>
	<c5fa8e21-3f68-202a-ac7e-5838815b5b12@redhat.com>
	<CA+1OW+g+41MwEDAiozHESG4PRsfuMrDrujLYYkTkpUCL=bMrtg@mail.gmail.com>
Message-ID: <3b5a3575-38bb-90f9-096e-8ca9407a5500@redhat.com>

On 5/19/2017 10:05 AM, Marko Strukelj wrote:
> I believe nowadays the tech to use for such multiserver setups would 
> be Docker / OpenShift.
That's good.  I like the OpenShift idea especially.

Then, quickstart just becomes:
1) Spin up a pre-configured QuickStart instance of Keycloak on OpenShift
2) Spin up a pre-configured QuickStart instance of WildFly on OpenShift
3) Download the QuickStart app projects
4) Make your changes to QuickStart apps and upload to OpenShift

>
> On May 19, 2017 14:50, "Stan Silvert" <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 5/19/2017 8:29 AM, Stian Thorgersen wrote:
>     > I repeat - Quickstarts are to help people getting started securing
>     > their own applications.
>     >
>     > What you are proposing will not help for that. We don't support
>     > deploying apps directly to Keycloak. It's an SSO solution after all.
>     > So it's just part of it running Keycloak on a different port or
>     host.
>     Also, I don't think I explained very well how this works. There
>     are two
>     completely different servers that just happen to share the same
>     /modules
>     directory:
>
>     /modules
>     /standalone
>     /keycloak
>
>     >
>     > On 19 May 2017 at 14:15, Stan Silvert <ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>
>     > <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>> wrote:
>     >
>     >     On 5/19/2017 3:06 AM, Stian Thorgersen wrote:
>     >>     That's rather off topic. Quickstarts is one thing and a
>     >>     demo/example is another thing. Quickstarts is supposed to show
>     >>     you how to get started with securing your apps with Keycloak.
>     >>     What you are proposing is a nice option on just trying out
>     >>     Keycloak, but it doesn't really help users getting started
>     >>     properly with securing their apps.
>     >     I disagree.  It would help tremendously. Right now, to get
>     started
>     >     securing your apps with the help of quickstart you must:
>     >     1) Set up a Keycloak instance and understand that you need
>     to run
>     >     it on port 8180.
>     >     2) Set up a Wildfly instance on port 8080.
>     >     3) Find multiple json files that you need to import to Keycloak
>     >     3.5) If you can't figure out what to import, follow the
>     >     instructions to do Keycloak config by hand.
>     >     4) Create keycloak.json files for each app and put them in the
>     >     proper place.
>     >     5) Do mvn wildfly:deploy for each app you want to run
>     >     6) FIGURE OUT WHAT YOU DID WRONG IN STEPS 1-5
>     >     7) Try modifications to the quickstart apps so you can get an
>     >     ideas about how you will secure your own apps
>     >     8) Deploy your modifications
>     >
>     >     What I propose is that we get rid of steps 1 through 6.
>     >     Quickstart doesn't help if you can't get to steps 7 and 8
>     "quickly".
>     >
>     >
>     >>
>     >>     On 18 May 2017 at 20:59, Stan Silvert <ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>
>     >>     <mailto:ssilvert at redhat.com <mailto:ssilvert at redhat.com>>>
>     wrote:
>     >>
>     >>         What we really need for the quickstarts is something
>     Bill has
>     >>         been
>     >>         talking about for a long time.
>     >>
>     >>         It's a bundle of Keycloak and examples that just boots
>     up and
>     >>         works.
>     >>         Otherwise, the quickstarts are way too hard to get running.
>     >>         Nobody
>     >>         wants to spend 2 or 3 hours on a "quickstart". That's
>     what I
>     >>         had to do
>     >>         recently and I already know what's going on.  I hate to
>     think
>     >>         about what
>     >>         someone new to Keycloak needs to go through just to see an
>     >>         example.
>     >>
>     >>         This doesn't have to mean that everything runs in the same
>     >>         WildFly
>     >>         instance like the old demo dist.  The problem with that was
>     >>         that it
>     >>         didn't show Keycloak set up as a stand-alone server.
>     >>
>     >>         What you need is a single bundle that lets you run Keycloak
>     >>         standalone
>     >>         and a standalone app server.  I see a couple of ways to
>     do it:
>     >>         1) Use domain mode where you get a domain controller,
>     >>         Keycloak instance,
>     >>         and app server instance all in the same JVM.
>     >>         2) Use two separate server configs and run in two JVM's.
>     >>
>     >>         I think #2 is the best.  The Keycloak instance runs on port
>     >>         8180 and the
>     >>         app server runs on 8080.  You only need one download of
>     >>         WildFly/Keycloak, but you package it with two configs.  So
>     >>         you have:
>     >>         /bin
>     >>         /modules
>     >>         /domain (don't actually need this one)
>     >>         /standalone
>     >>         /keycloak
>     >>
>     >>         To run Keycloak (preloaded with quickstart realm):
>     >>          > standalone --server-config=keycloak
>     >>         -Djboss.socket.binding.port-offset=100
>     >>
>     >>         To run app server (preloaded with quickstart apps):
>     >>          > standalone
>     >>
>     >>
>     >>
>     >>         On 5/18/2017 1:59 PM, Bruno Oliveira wrote:
>     >>         > Hmmm I'm not sure about that. That would be the
>     completely
>     >>         opposite of what
>     >>         > we already do to any repository today. If people want the
>     >>         stable release of
>     >>         > the quickstarts they could just get 3.x or download
>     the zip
>     >>         files, nope?
>     >>         >
>     >>         > On Thu, May 18, 2017 at 2:15 PM Sebastien Blanc
>     >>         <sblanc at redhat.com <mailto:sblanc at redhat.com>
>     <mailto:sblanc at redhat.com <mailto:sblanc at redhat.com>>> wrote:
>     >>         >
>     >>         >> We should also consider the opposite : master is the
>     >>         stable released
>     >>         >> version and a branch for development . I already had
>     >>         confused people
>     >>         >> downloading KC server and cloning the QuickStarts and
>     >>         expecting it to work.
>     >>         >> But tbh I do not have a string opinion on that.
>     >>         >> Le jeu. 18 mai 2017 ? 18:57, Bruno Oliveira
>     >>         <bruno at abstractj.org <mailto:bruno at abstractj.org>
>     <mailto:bruno at abstractj.org <mailto:bruno at abstractj.org>>> a
>     >>         >> ?crit :
>     >>         >>
>     >>         >>> While working today on the fix of some quickstarts. I'm
>     >>         >>> considering to create a separated branch only for
>     stable
>     >>         versions of the
>     >>         >>> quickstarts.
>     >>         >>>
>     >>         >>> In this way 'master' would be used only for development
>     >>         based on the
>     >>         >>> latest bits from Keycloak repo. And 3.1.x, to the
>     latest
>     >>         stable
>     >>         >>> release on Maven central.
>     >>         >>>
>     >>         >>> Does it make any sense?
>     >>         >>>
>     >>         >>> --
>     >>         >>>
>     >>         >>> abstractj
>     >>         >>>
>     >>         >> _______________________________________________
>     >>         >>> keycloak-dev mailing list
>     >>         >>> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>         <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >>         >>>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >>         >>>
>     >>         > _______________________________________________
>     >>         > keycloak-dev mailing list
>     >>         > keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>         <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >>         > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >>
>     >>         _______________________________________________
>     >>         keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >>         <mailto:keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>     >>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>>
>     >>
>     >>
>     >
>     >
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>


From mposolda at redhat.com  Fri May 19 13:20:54 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 19:20:54 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <f737658d-8ae4-e688-d481-796db67d0283@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
	<737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
	<62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>
	<3c6c6484-7329-f73c-b4e2-0d27d7692729@redhat.com>
	<d805ff8d-fddc-abb9-cc8e-1afb44eacd09@redhat.com>
	<f737658d-8ae4-e688-d481-796db67d0283@redhat.com>
Message-ID: <f29cd39d-b6ee-f660-6796-44ff27685fea@redhat.com>

On 19/05/17 17:53, Marek Posolda wrote:
> On 19/05/17 17:40, Bill Burke wrote:
>>
>>
>> On 5/19/17 11:36 AM, Marek Posolda wrote:
>>> On 19/05/17 17:28, Bill Burke wrote:
>>>>
>>>>
>>>> On 5/19/17 11:25 AM, Marek Posolda wrote:
>>>>> On 19/05/17 16:58, Bill Burke wrote:
>>>>>>
>>>>>>
>>>>>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>>>>>> On 19/05/17 16:19, Bill Burke wrote:
>>>>>>>> * Won't the regular case be that the load balancer generates the
>>>>>>>> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
>>>>>>>> popular and they have both options.
>>>>>>> Yes, that's also what Sebastien Schuster from community mentioned
>>>>>>> in other thread. That's why I've added
>>>>>>> StickySessionEncoderProvider as SPI, so it's easily possible to
>>>>>>> disable Keycloak adding route to the cookie, or sticky request
>>>>>>> based on something different than cookie (eg. path parameter).
>>>>>>>
>>>>>>> However having Keycloak itself to choose the route has one big
>>>>>>> performance advantage, that it can route to the node, who is
>>>>>>> owner of the entry in the infinispan distributed cache. This
>>>>>>> includes also support for rebalance (owner may change when new
>>>>>>> node joins/leaves cluster, then you change route automatically).
>>>>>>> This is what Wildfly is doing for Http sessions too.
>>>>>>>
>>>>>>> We discussed the integration with KeyAffinityService [1], which
>>>>>>> helps with usecase when loadbalancer generates route to the
>>>>>>> cookie. It ensures that generated session ID will be local to
>>>>>>> current node. Hence loadbalancer can use request node as the
>>>>>>> route and session will be local to it. But this doesn't handle
>>>>>>> rebalance, so IMO preferred option is still to let Keycloak to
>>>>>>> append route.
>>>>>>>
>>>>>>> There is also infinispan grouping API I want to look at.
>>>>>>>
>>>>>>> [1]
>>>>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService
>>>>>>>> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
>>>>>>>> What happens when the use clicks "proceed"?  Does the SAML or OIDC
>>>>>>>> request continue as normal? Or are you calculating the URI on the
>>>>>>>> application to redirect to, if so, why?
>>>>>>> No, this is just link to client base URI, and then new flow can
>>>>>>> be started from the application. ATM authenticationSession may be
>>>>>>> already removed as user logged already in different browser tab
>>>>>>> etc, so there is no flow to continue with.
>>>>>>>
>>>>>>> Currently there is just userSession available and the client
>>>>>>> application used for "Back to application" is the last
>>>>>>> authenticated client in userSession. I am going to improve it and
>>>>>>> use "client_id" parameter in requests, so in case of expired
>>>>>>> session, already authentication session etc, you would always
>>>>>>> know the client from the "client_id" parameter. Details in the
>>>>>>> other ML thread "Provide a Link to go Back to The Application on
>>>>>>> a Timeout" .
>>>>>>>
>>>>>> Why do you need this page?  Why can't you just proceed with the
>>>>>> OIDC/SAML protocol?
>>>>> You mean redirect automatically to the client, which will start new
>>>>> OIDC/SAML flow and then authenticate you automatically due to SSO?
>>>>>
>>>>> Yes, in cases like our admin console, it will be better behaviour
>>>>> then showing "You are already logged in" . But that's just because
>>>>> client base URI, (or client redirect URI) are secured URLs and
>>>>> automatically redirects to Keycloak and starts the flow.
>>>>>
>>>>> But in many applications, this is not the case. For example, you
>>>>> have single page JS application on "http://host/js-app", which is
>>>>> itself not secured URL. So after confirm the expired
>>>>> username/password form, you would redirect to the
>>>>> "http://host/js-app", but you won't be authenticated there. This
>>>>> looks like quite confusing behaviour for the user IMO.
>>>>>
>>>>> Showing "You are already logged in" looks like good compromise. In
>>>>> many cases it is just additional splash screen, but at least it
>>>>> don't confuse users in case that client redirect URI are not
>>>>> secured URLs.
>>>>>
>>>> Not following.  Maybe i need to review the presentation again as
>>>> maybe I'm confused when the "already logged in" screen is shown.
>>> Easy to reproduce:
>>> - Go to "http://localhost:8181/auth/admin" in browser tab 1
>>> - Open tab 2 and go again to "http://localhost:8181/auth/admin" here
>>> - Finish login as admin/admin in tab 2. You are logged in admin console
>>> - Go back to tab 1 and try to login as admin/admin again. Now it's
>>> displayed "You are already logged in" .
>>>
>> Why does this happen?  Why can't Keycloak just finish the OIDC
>> protocol?  Is it because you don't want to ignore the
>> username/password screen?
> The authenticationSession doesn't exists. It was already logged-in. Now
> we have single authenticationSession in the browser as it's tracked with
> the cookie. Support for more authentication sessions within browser can
> be done, but will be quite tricky with tracking session by the cookie
> and not sure it worth the effort for the corner cases like this?
Should I go for something like this? We can have more "client-contexts" 
in single authentication session. Each client-context is per browser 
tab. The state of authenticators, executions etc is shared, but 
client-context is unique per browser tab. So will need to reference 
client_context with the query parameter, so authentication session can 
find correct context based on this parameter. Also KC_RESTART cookie can 
be improved to support for multiple clients, so in every browser tab you 
will be able to restart correct authentication session.

This will be another few days of work, but should be fine. I can work on 
it together with KEYCLOAK-4016 (adding client_id parameter).

WDYT?
Marek
>
> Previous behaviour had more clientSessions in different browser tabs. So
> login in 2 tabs was possible, but after login in tab2, it created
> another userSession and overwrite the previous userSession including
> cookies etc. This had other issues like mentioned in this JIRA
> https://issues.jboss.org/browse/KEYCLOAK-4097
>
> Marek
>> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Fri May 19 13:22:58 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 May 2017 19:22:58 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <f29cd39d-b6ee-f660-6796-44ff27685fea@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
	<a55f07f7-a1e8-d707-c9d6-939cb2299514@redhat.com>
	<0ce29a60-481f-7210-1501-51bab7e05cd4@redhat.com>
	<737a2781-dadb-ab45-832c-aea95f597cd6@redhat.com>
	<62ab99fc-60a5-0226-8964-6fc99ae95bfc@redhat.com>
	<3c6c6484-7329-f73c-b4e2-0d27d7692729@redhat.com>
	<d805ff8d-fddc-abb9-cc8e-1afb44eacd09@redhat.com>
	<f737658d-8ae4-e688-d481-796db67d0283@redhat.com>
	<f29cd39d-b6ee-f660-6796-44ff27685fea@redhat.com>
Message-ID: <84bd233a-8c70-b89d-2fb0-27819c7fbc1e@redhat.com>

On 19/05/17 19:20, Marek Posolda wrote:
> On 19/05/17 17:53, Marek Posolda wrote:
>> On 19/05/17 17:40, Bill Burke wrote:
>>>
>>>
>>> On 5/19/17 11:36 AM, Marek Posolda wrote:
>>>> On 19/05/17 17:28, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 5/19/17 11:25 AM, Marek Posolda wrote:
>>>>>> On 19/05/17 16:58, Bill Burke wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 5/19/17 10:57 AM, Marek Posolda wrote:
>>>>>>>> On 19/05/17 16:19, Bill Burke wrote:
>>>>>>>>> * Won't the regular case be that the load balancer generates the
>>>>>>>>> affinity cookie or doesn't have a cookie at all? HA-Proxy is 
>>>>>>>>> quite
>>>>>>>>> popular and they have both options.
>>>>>>>> Yes, that's also what Sebastien Schuster from community mentioned
>>>>>>>> in other thread. That's why I've added
>>>>>>>> StickySessionEncoderProvider as SPI, so it's easily possible to
>>>>>>>> disable Keycloak adding route to the cookie, or sticky request
>>>>>>>> based on something different than cookie (eg. path parameter).
>>>>>>>>
>>>>>>>> However having Keycloak itself to choose the route has one big
>>>>>>>> performance advantage, that it can route to the node, who is
>>>>>>>> owner of the entry in the infinispan distributed cache. This
>>>>>>>> includes also support for rebalance (owner may change when new
>>>>>>>> node joins/leaves cluster, then you change route automatically).
>>>>>>>> This is what Wildfly is doing for Http sessions too.
>>>>>>>>
>>>>>>>> We discussed the integration with KeyAffinityService [1], which
>>>>>>>> helps with usecase when loadbalancer generates route to the
>>>>>>>> cookie. It ensures that generated session ID will be local to
>>>>>>>> current node. Hence loadbalancer can use request node as the
>>>>>>>> route and session will be local to it. But this doesn't handle
>>>>>>>> rebalance, so IMO preferred option is still to let Keycloak to
>>>>>>>> append route.
>>>>>>>>
>>>>>>>> There is also infinispan grouping API I want to look at.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> http://infinispan.org/docs/stable/user_guide/user_guide.html#KeyAffinityService 
>>>>>>>>
>>>>>>>>> * @ 18:25 in bluejeans session, The "You are already logged 
>>>>>>>>> in" screen.
>>>>>>>>> What happens when the use clicks "proceed"?  Does the SAML or 
>>>>>>>>> OIDC
>>>>>>>>> request continue as normal? Or are you calculating the URI on the
>>>>>>>>> application to redirect to, if so, why?
>>>>>>>> No, this is just link to client base URI, and then new flow can
>>>>>>>> be started from the application. ATM authenticationSession may be
>>>>>>>> already removed as user logged already in different browser tab
>>>>>>>> etc, so there is no flow to continue with.
>>>>>>>>
>>>>>>>> Currently there is just userSession available and the client
>>>>>>>> application used for "Back to application" is the last
>>>>>>>> authenticated client in userSession. I am going to improve it and
>>>>>>>> use "client_id" parameter in requests, so in case of expired
>>>>>>>> session, already authentication session etc, you would always
>>>>>>>> know the client from the "client_id" parameter. Details in the
>>>>>>>> other ML thread "Provide a Link to go Back to The Application on
>>>>>>>> a Timeout" .
>>>>>>>>
>>>>>>> Why do you need this page?  Why can't you just proceed with the
>>>>>>> OIDC/SAML protocol?
>>>>>> You mean redirect automatically to the client, which will start new
>>>>>> OIDC/SAML flow and then authenticate you automatically due to SSO?
>>>>>>
>>>>>> Yes, in cases like our admin console, it will be better behaviour
>>>>>> then showing "You are already logged in" . But that's just because
>>>>>> client base URI, (or client redirect URI) are secured URLs and
>>>>>> automatically redirects to Keycloak and starts the flow.
>>>>>>
>>>>>> But in many applications, this is not the case. For example, you
>>>>>> have single page JS application on "http://host/js-app", which is
>>>>>> itself not secured URL. So after confirm the expired
>>>>>> username/password form, you would redirect to the
>>>>>> "http://host/js-app", but you won't be authenticated there. This
>>>>>> looks like quite confusing behaviour for the user IMO.
>>>>>>
>>>>>> Showing "You are already logged in" looks like good compromise. In
>>>>>> many cases it is just additional splash screen, but at least it
>>>>>> don't confuse users in case that client redirect URI are not
>>>>>> secured URLs.
>>>>>>
>>>>> Not following.  Maybe i need to review the presentation again as
>>>>> maybe I'm confused when the "already logged in" screen is shown.
>>>> Easy to reproduce:
>>>> - Go to "http://localhost:8181/auth/admin" in browser tab 1
>>>> - Open tab 2 and go again to "http://localhost:8181/auth/admin" here
>>>> - Finish login as admin/admin in tab 2. You are logged in admin 
>>>> console
>>>> - Go back to tab 1 and try to login as admin/admin again. Now it's
>>>> displayed "You are already logged in" .
>>>>
>>> Why does this happen?  Why can't Keycloak just finish the OIDC
>>> protocol?  Is it because you don't want to ignore the
>>> username/password screen?
>> The authenticationSession doesn't exists. It was already logged-in. Now
>> we have single authenticationSession in the browser as it's tracked with
>> the cookie. Support for more authentication sessions within browser can
>> be done, but will be quite tricky with tracking session by the cookie
>> and not sure it worth the effort for the corner cases like this?
> Should I go for something like this? We can have more 
> "client-contexts" in single authentication session. Each 
> client-context is per browser tab. The state of authenticators, 
> executions etc is shared, but client-context is unique per browser 
> tab. So will need to reference client_context with the query 
> parameter, so authentication session can find correct context based on 
> this parameter. Also KC_RESTART cookie can be improved to support for 
> multiple clients, so in every browser tab you will be able to restart 
> correct authentication session.
I meant "restart correct client-context", so you will be authenticated 
to correct client with correct "state" parameter etc.


>
> This will be another few days of work, but should be fine. I can work 
> on it together with KEYCLOAK-4016 (adding client_id parameter).
>
> WDYT?
> Marek
>>
>> Previous behaviour had more clientSessions in different browser tabs. So
>> login in 2 tabs was possible, but after login in tab2, it created
>> another userSession and overwrite the previous userSession including
>> cookies etc. This had other issues like mentioned in this JIRA
>> https://issues.jboss.org/browse/KEYCLOAK-4097
>>
>> Marek
>>> Bill
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From ivan at akvo.org  Fri May 19 13:49:21 2017
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Fri, 19 May 2017 19:49:21 +0200
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
Message-ID: <2a52d42f-fecf-5033-d22a-10ebb4401f6f@akvo.org>

Hi,

On 05/19/2017 05:37 PM, Bill Burke wrote:
> All imports must be fully qualified.  A number of people are making this 
> mistake lately.

Just as a comment, this is a default setting in IntelliJ IDEA, after 5
classes of the same package, IntelliJ switches to package.*
You need to manually switch the configuration.

My five cents,

-- 
Iv?n


From bruno at abstractj.org  Fri May 19 14:07:32 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 19 May 2017 18:07:32 +0000
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <2a52d42f-fecf-5033-d22a-10ebb4401f6f@akvo.org>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
	<2a52d42f-fecf-5033-d22a-10ebb4401f6f@akvo.org>
Message-ID: <CAM5SUC40kJ+2OAY7HQ-chfP3OKksXcOyV_xTJKA=4C=yPynwqA@mail.gmail.com>

You can just change it to something like this:
http://i.imgur.com/yCi2mV2.png

On Fri, May 19, 2017 at 2:57 PM Iv?n Perdomo <ivan at akvo.org> wrote:

> Hi,
>
> On 05/19/2017 05:37 PM, Bill Burke wrote:
> > All imports must be fully qualified.  A number of people are making this
> > mistake lately.
>
> Just as a comment, this is a default setting in IntelliJ IDEA, after 5
> classes of the same package, IntelliJ switches to package.*
> You need to manually switch the configuration.
>
> My five cents,
>
> --
> Iv?n
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From hfernand at redhat.com  Sat May 20 08:23:33 2017
From: hfernand at redhat.com (Hector Fernandez)
Date: Sat, 20 May 2017 12:23:33 +0000
Subject: [keycloak-dev] healthchek API endpoint for environments like
	kubernetes
Message-ID: <CAHxsJpEp_PGiLhJUgfyZOvGuwiaCmgw7oK-pac3P903+Hehvfg@mail.gmail.com>

Hi guys,

We have a keycloak cluster setup in Openshift on which our healthchecks
point to the endpoint `auth/version`. It would be nice if you provide an
endpoint in your API that could tell us more info about healthiness or
readiness of Keycloak (especially in a cluster mode).

Do you have any similar endpoint?
Otherwise, it could be a nice feature for envs such as Kubernetes
-- 
*<hector/>*
-- 
*<hector/>*

From thomas.darimont at googlemail.com  Sat May 20 09:38:59 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 20 May 2017 15:38:59 +0200
Subject: [keycloak-dev] healthchek API endpoint for environments like
	kubernetes
In-Reply-To: <CAHxsJpEp_PGiLhJUgfyZOvGuwiaCmgw7oK-pac3P903+Hehvfg@mail.gmail.com>
References: <CAHxsJpEp_PGiLhJUgfyZOvGuwiaCmgw7oK-pac3P903+Hehvfg@mail.gmail.com>
Message-ID: <CAK-7U1j1n8TYOyLOgzRbPcpQzfFBbmnLEgFH2P228XNaEOo+KA@mail.gmail.com>

Hello Hector,

there is already an issue for that in JIRA, see:
https://issues.jboss.org/browse/KEYCLOAK-1578
I played a bit with a new health endpoint SPI:
https://github.com/thomasdarimont/keycloak-health-checks

Cheers,
Thomas

2017-05-20 14:23 GMT+02:00 Hector Fernandez <hfernand at redhat.com>:

> Hi guys,
>
> We have a keycloak cluster setup in Openshift on which our healthchecks
> point to the endpoint `auth/version`. It would be nice if you provide an
> endpoint in your API that could tell us more info about healthiness or
> readiness of Keycloak (especially in a cluster mode).
>
> Do you have any similar endpoint?
> Otherwise, it could be a nice feature for envs such as Kubernetes
> --
> *<hector/>*
> --
> *<hector/>*
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From srossillo at smartling.com  Sun May 21 14:34:48 2017
From: srossillo at smartling.com (Scott Rossillo)
Date: Sun, 21 May 2017 18:34:48 +0000
Subject: [keycloak-dev] healthchek API endpoint for environments like
	kubernetes
In-Reply-To: <CAK-7U1j1n8TYOyLOgzRbPcpQzfFBbmnLEgFH2P228XNaEOo+KA@mail.gmail.com>
References: <CAHxsJpEp_PGiLhJUgfyZOvGuwiaCmgw7oK-pac3P903+Hehvfg@mail.gmail.com>
	<CAK-7U1j1n8TYOyLOgzRbPcpQzfFBbmnLEgFH2P228XNaEOo+KA@mail.gmail.com>
Message-ID: <CALAqdu-=2YS2Qbk=ay+QanFiVZLNwZqT5ZwayZNmkJqoXty2zQ@mail.gmail.com>

+1 for something like this but for older deployments I figured the OIDC
.wellknown endpoint was a decent indicator of availability.

However, deploys to Kuberbetes and AWS ECS still seem to get a bit wonky
for a minute or two while Infinispan establishes a new cluster state.
On Sat, May 20, 2017 at 9:44 AM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello Hector,
>
> there is already an issue for that in JIRA, see:
> https://issues.jboss.org/browse/KEYCLOAK-1578
> I played a bit with a new health endpoint SPI:
> https://github.com/thomasdarimont/keycloak-health-checks
>
> Cheers,
> Thomas
>
> 2017-05-20 14:23 GMT+02:00 Hector Fernandez <hfernand at redhat.com>:
>
> > Hi guys,
> >
> > We have a keycloak cluster setup in Openshift on which our healthchecks
> > point to the endpoint `auth/version`. It would be nice if you provide an
> > endpoint in your API that could tell us more info about healthiness or
> > readiness of Keycloak (especially in a cluster mode).
> >
> > Do you have any similar endpoint?
> > Otherwise, it could be a nice feature for envs such as Kubernetes
> > --
> > *<hector/>*
> > --
> > *<hector/>*
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May 22 02:20:28 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 May 2017 08:20:28 +0200
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
Message-ID: <CAJgngAfudZMeqqePDaYDutKtriJLbYTx04r867jbktNYQ1dWGA@mail.gmail.com>

Why is this a problem?

On 19 May 2017 at 17:37, Bill Burke <bburke at redhat.com> wrote:

> Please make your IDE import the full classname.  This is not allowed:
>
> import java.uti.*;
>
> All imports must be fully qualified.  A number of people are making this
> mistake lately.
>
> Thanks,
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Mon May 22 02:55:58 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 22 May 2017 08:55:58 +0200
Subject: [keycloak-dev] questions on Marek/Hynek presentation
In-Reply-To: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
References: <94317690-e296-9aab-854d-459a5ae2abd7@redhat.com>
Message-ID: <3800f40b-02aa-eb32-b6b4-54e88a4bf164@redhat.com>

On 05/19/2017 04:19 PM, Bill Burke wrote:
> * Won't the regular case be that the load balancer generates the
> affinity cookie or doesn't have a cookie at all?  HA-Proxy is quite
> popular and they have both options.
> 
> * @ 18:25 in bluejeans session, The "You are already logged in" screen.
> What happens when the use clicks "proceed"?  Does the SAML or OIDC
> request continue as normal? Or are you calculating the URI on the
> application to redirect to, if so, why?
> 
> On Action Tokens:
> 
> 
> * What is the relationship between the RequiredAction SPI and
> ActionTokenHandler SPI?  Does every RequiredAction have to have a
> corresponding ActionTokenHandler?

Action token can (not necessarily must) create an authentication session and among other request execution of particular required actions. Example of such an action token handler is ExecuteActionsActionTokenHandler [1]. Ad the second question - no, required action is a different layer of execution than action token (see below).

> * Why would a app developer need to implement an ActionTokenHandler?
> Wouldn't it be better for the Required Action SPI to provide the
> appropriate metadata so that the handler could be implemented by us?
> i.e. isOneTimeToken, email-template, etc, etc.  I guess what I'm saying
> is that action tokens should be incorporated into the RequiredAction SPI.

Ordinarily not. When only execution of required actions is required, a developer would use ExecuteActionsActionToken [2]. However to initialize a run of a particular flow like in reset credentials, an action token would be the right tool rather than required action. So what I think is that the two - action tokens and required actions - are two complementary layers and should not be merged.  
> * Related to above.  Required actions should be able to specify an
> "admin console template" and "login template".  These would be the
> freemarker template to use to create the email that is sent to the
> user.  "admin console" would be from an admin generating the action.
> "login" would be when user login initiates the action email.

That makes sense and is related to required actions only, not to action tokens.

> * On the Admin Console "Credential Reset" section.  Required Action
> emails (now Action tokens) aren't necessarily "Credential Resets".
> Verify email is not a credential reset. etc. This need to be renamed and
> maybe put in another tab?

+1. I've added https://issues.jboss.org/browse/KEYCLOAK-4948

> * We will need a way to offload action processing to another external
> service.  keycloak exists to mark that the action was completed, but all
> the processing for the action happens in an external application.  A lot
> of people have existing applications they want to integrate with that
> perform action processing.  Just something to think about.  We need this
> for other areas of keycloak (i.e. registration).
That would be possible with action tokens + required action: I can imagine one way of implementing this as an single-use action token (ExecuteActionsActionToken [2] again) that would run a required action (say ExternalRequiredAction). ExternalRequiredAction checks for presence of a potentially signed query parameter (say externalExecutionStatus).
* If the externalExecutionStatus is not set, the required action handler redirects to the respective application
* If the externalExecutionStatus is set and valid, the required action handler states context.success().
In this, the ExternalRequiredAction behaves similarly to e.g. VerifyEmail [3]. The application has to redirect back to the same action token link with added externalExecutionStatus parameter to ensure that the action token expires. The link can be generated before redirecting to the app in ExternalRequiredAction and passed to the application.

There are certainly more sophisticated solutions to this than this one above but I hope it illustrates the idea how the action tokens and required action can interact.

--Hynek

[1] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/actiontoken/execactions/ExecuteActionsActionTokenHandler.java
[2] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/actiontoken/execactions/ExecuteActionsActionToken.java
[3] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/authentication/requiredactions/VerifyEmail.java

From sthorger at redhat.com  Mon May 22 03:15:03 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 May 2017 09:15:03 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <d82e7714-9ed2-bbf2-a685-1c835e570fcc@redhat.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>
	<f48b359b-64dd-b409-bb2e-055bba29751c@redhat.com>
	<ccd81a61-9a52-5b81-1564-4c61668a922d@redhat.com>
	<d82e7714-9ed2-bbf2-a685-1c835e570fcc@redhat.com>
Message-ID: <CAJgngAcmVviTVmA9+o2hhk2q_edDPZ3waU9KxN+PPjuPdKKGxw@mail.gmail.com>

An application can only access a backend node directly if it's within the
same subnet. At that point it's not a big problem in either case as local
traffic can easily be configured to talk to nodes within the DC.

Some pluggable way of setting headers/cookies or something that allows load
balancer to stick the requests is probably the best we can do. Not even
sure that'll even work between DCs as I believe that can be handled at the
DNS level. One option that could work is to have smart proxies/routers.
These would be replicated within DCs and have some way of proxying requests
to the correct node. That'd work for third party apps and other things
where you can get the client to set any special headers etc.

I second Bills suggestion of raising this on the OIDC mailing lists. Marek
could you do that?

On 19 May 2017 at 17:08, Marek Posolda <mposolda at redhat.com> wrote:

> On 19/05/17 16:31, Bill Burke wrote:
> >
> >
> > On 5/19/17 10:29 AM, Marek Posolda wrote:
> >> On 19/05/17 15:21, Bill Burke wrote:
> >>> This issue comes up in:
> >>>
> >>> * code to token
> >>>
> >>> * refresh token
> >>>
> >>> * backchannel logout
> >>>
> >>> * access token validation (bearer token authentication)
> >>>
> >>> * Authorization and RPT
> >>>
> >>> * Token exchange
> >>>
> >>> Any others?
> >>>
> >>> We need to get on OIDC lists and discuss these types of issues so that
> >>> they can get standardized.
> >> Good point. I can try to start discussion there.
> >>>
> >>> Other thoughts:
> >>>
> >>> * What if you talk to the node directly by providing a URL claim in the
> >>> token or code? The issue with that is that since we derive a lot of
> >>> things from the hostname of the request, we will need the ability to
> >>> override this.
> >> You mean to bypass loadbalancer entirely and let the application talk
> >> to the backend node directly?
> >>
> >> Besides the hostname issue, there is another one, that backend node
> >> may not be directly available. Those are typically on private
> >> networks and it can be different private network that application is
> >> using. That was the case for example in RedHat IT environment.
> >>
> >> BTV. We already had similar possibility in adapter to directly talk
> >> to backend node in backchannel requests. Instead of lookup the
> >> backend node URL from claim, we had the option in adapter
> >> configuration "auth-server-url-for-backend-requests" . But the option
> >> was removed due those issues like hostname, verifications of "iss"
> >> claim in tokens etc.
> >>
> >
> > Backchannel sticky session becomes quite difficult if you can't talk
> > to node directly. Adapter will have to know to set a cookie that the
> > loadbalancer can handle.  If the load balancer is using client IP to
> > loadbalance, then you are SOL.
> Yes, that's the pain with no easy solution. There is no standard for
> loadbalancers and we don't know if people use private networks for
> backend nodes or not etc :( Support for cookie in the adapter request is
> the option I would like to go, we agreed so far in different thread on
> ML. For loadbalancing on client IP not sure we can handle that. Maybe
> use "client-ip" as the claim in code or token and do some hacking around
> "X-" http headers in the adapter request to Keycloak?
>
> Talking application to backend node directly has issues and AFAIK Stian
> don't like this option at all. Hostname issues, backend node not
> available to the app etc. Perhaps he can add more.
>
> Marek
>
> >
> > Bill
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May 22 03:30:36 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 May 2017 09:30:36 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
Message-ID: <CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>

On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:

> Followup on some previous emails I sent this week around sticky sessions
> and OIDC backchannel requests.
>
> In shortcut, it would be ideal if we can achieve that backchannel
> requests (code-to-token, refresh token, logouts etc) can participate in
> same sticky session like the browser request. It may be possible in some
> cases (our adapters, some loadbalancers, see previous email I sent this
> week) but not everytime. And looks we would need to support the case
> when it's not possible.
>
> I can start with code-to-token request as it's slightly more complicated
> then the others due to the reasons:
>
> 1) code must be single-use per OAuth2 / OIDC specification
>
> 2) userSession may not yet be available. In case that we use ASYNC
> channel for communication between datacenters for transfer userSession
> (which I think should be the default due to performance reasons), then
> this example flow can happen:
> - user successfully authenticated and userSession was created on DC1.
> - code-to-token request is sent by the adapter to DC2. Note that this
> request is usually sent very quickly after userSession is created.
> - DC2 didn't yet received the message from DC1 about the new
> userSession. So this userSession not yet available here.
>
> Questions:
> 1) Could we remove a need from code-to-token endpoint to lookup
> userSession? I see this as an option as long as code itself is JWT
> signed with realm HMAC key encapsulating some info about user,
> session_state etc. Among other things, this would require some
> refactoring of protocolMappers (as userSession won't be available when
> tokens are generated). But isn't it bad for security to have some claims
> directly to the code? It is query parameter, which may end visible in
> browser history. IMO this is not big issue, but not 100% sure..
>

Wouldn't the code also become rather big?

I reckon protocol mappers should be refactored regardless though. The
details should be in the code and token not in the user session.


>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May 22 03:46:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 May 2017 09:46:35 +0200
Subject: [keycloak-dev] German translation review
Message-ID: <CAJgngAdzj1GbUHJEwsWfLBPwq1HZwHgmYkLG+BkfNLDxoSepAA@mail.gmail.com>

Can someone review https://github.com/keycloak/keycloak/pull/4164 please?

From thomas.darimont at googlemail.com  Mon May 22 04:24:35 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 22 May 2017 10:24:35 +0200
Subject: [keycloak-dev] German translation review
In-Reply-To: <CAJgngAdzj1GbUHJEwsWfLBPwq1HZwHgmYkLG+BkfNLDxoSepAA@mail.gmail.com>
References: <CAJgngAdzj1GbUHJEwsWfLBPwq1HZwHgmYkLG+BkfNLDxoSepAA@mail.gmail.com>
Message-ID: <CAK-7U1i4k3otCaMXALLA_VmT849v1dUqkS9sZ9XWV-ojrnvGgA@mail.gmail.com>

LGTM.

Cheers,
Thomas

2017-05-22 9:46 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> Can someone review https://github.com/keycloak/keycloak/pull/4164 please?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May 22 04:34:49 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 May 2017 10:34:49 +0200
Subject: [keycloak-dev] German translation review
In-Reply-To: <CAK-7U1i4k3otCaMXALLA_VmT849v1dUqkS9sZ9XWV-ojrnvGgA@mail.gmail.com>
References: <CAJgngAdzj1GbUHJEwsWfLBPwq1HZwHgmYkLG+BkfNLDxoSepAA@mail.gmail.com>
	<CAK-7U1i4k3otCaMXALLA_VmT849v1dUqkS9sZ9XWV-ojrnvGgA@mail.gmail.com>
Message-ID: <CAJgngAd-Q0a00J+Tpo-22uYSNw+b5H+=Qr59vy25WOqVs-EJUw@mail.gmail.com>

Thanks

On 22 May 2017 at 10:24, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> LGTM.
>
> Cheers,
> Thomas
>
> 2017-05-22 9:46 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Can someone review https://github.com/keycloak/keycloak/pull/4164 please?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bburke at redhat.com  Mon May 22 09:16:00 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 May 2017 09:16:00 -0400
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
Message-ID: <09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>



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

For protocol mappers, the reason why the user session need to be 
available is that some component might be storing temporary information 
within the session that needs to be mapped to the token.  Any example is 
a broker login that doesn't want or need to import into database, but 
instead stores in in the session.  Doesn't kerberos store stuff in the 
session that can be mapped to the token?  Finally, eventually we will 
want import-less brokering where the user is created within the session 
and destroyed with the session so we dont' have to hit the DB and import.

>
>> 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

From sthorger at redhat.com  Mon May 22 13:29:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 May 2017 19:29:43 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
Message-ID: <CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>

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

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

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


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

From Sebastian.Schuster at bosch-si.com  Tue May 23 02:32:49 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 23 May 2017 06:32:49 +0000
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
Message-ID: <c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>

I would like to argue against 1). Putting token content into the authcode kind of changes the flow to be more like the implicit flow.
OIDC/OAuth2 offers the code flow especially to protect information in the tokens. Some claims could be sensitive and/or personal information
and I think they should not be in the code. Furthermore, enforcing the single use of codes becomes even harder if they can be exchanged
to tokens without looking up state first. Relaxing the one-time requirement is clearly against the spec and one should at least try hard to
fulfill it IMHO. 

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Montag, 22. Mai 2017 19:30
> To: Bill Burke <bburke at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> 
> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
> 
> >
> >
> > On 5/22/17 3:30 AM, Stian Thorgersen wrote:
> > > On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
> > >
> > >> Followup on some previous emails I sent this week around sticky
> > >> sessions and OIDC backchannel requests.
> > >>
> > >> In shortcut, it would be ideal if we can achieve that backchannel
> > >> requests (code-to-token, refresh token, logouts etc) can
> > >> participate in same sticky session like the browser request. It may
> > >> be possible in some cases (our adapters, some loadbalancers, see
> > >> previous email I sent this
> > >> week) but not everytime. And looks we would need to support the
> > >> case when it's not possible.
> > >>
> > >> I can start with code-to-token request as it's slightly more
> > >> complicated then the others due to the reasons:
> > >>
> > >> 1) code must be single-use per OAuth2 / OIDC specification
> > >>
> > >> 2) userSession may not yet be available. In case that we use ASYNC
> > >> channel for communication between datacenters for transfer
> > >> userSession (which I think should be the default due to performance
> > >> reasons), then this example flow can happen:
> > >> - user successfully authenticated and userSession was created on DC1.
> > >> - code-to-token request is sent by the adapter to DC2. Note that
> > >> this request is usually sent very quickly after userSession is created.
> > >> - DC2 didn't yet received the message from DC1 about the new
> > >> userSession. So this userSession not yet available here.
> > >>
> > >> Questions:
> > >> 1) Could we remove a need from code-to-token endpoint to lookup
> > >> userSession? I see this as an option as long as code itself is JWT
> > >> signed with realm HMAC key encapsulating some info about user,
> > >> session_state etc. Among other things, this would require some
> > >> refactoring of protocolMappers (as userSession won't be available
> > >> when tokens are generated). But isn't it bad for security to have
> > >> some claims directly to the code? It is query parameter, which may
> > >> end visible in browser history. IMO this is not big issue, but not 100% sure..
> > >>
> > > Wouldn't the code also become rather big?
> > >
> > > I reckon protocol mappers should be refactored regardless though.
> > > The details should be in the code and token not in the user session.
> >
> > For protocol mappers, the reason why the user session need to be
> > available is that some component might be storing temporary
> > information within the session that needs to be mapped to the token.
> > Any example is a broker login that doesn't want or need to import into
> > database, but instead stores in in the session.  Doesn't kerberos
> > store stuff in the session that can be mapped to the token?  Finally,
> > eventually we will want import-less brokering where the user is
> > created within the session and destroyed with the session so we dont' have to hit
> the DB and import.
> >
> 
> True, so we basically will need to make sure the user session exists and is
> persisted. I reckon on-demand replication if technically possible the best option.
> 
> 
> >
> > >
> > >> 2) Another option is let the code-to-token endpoint wait until
> > >> userSession is available. Then we would need support for
> > >> asynchronous requests? I can see blocking undertow workers in
> > >> waiting (something based on java.util.concurrent.Future) can be an
> > >> issue and potential for DoS? Still even with asynchronous, the request times
> can be quite long.
> > >>
> > > I like this option. Could we combine this with on demand replication?
> > With
> > > a configurable timeout this would be nifty IMO.
> >
> >
> >
> > >
> > >
> > >> 3) Can we encourage people to use sticky sessions at least for
> > >> code-to-token endpoint? We can add the route directly to the code
> > >> itself, so the URL will look like:
> > >> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
> > >> seem
> > to
> > >> support sticky session based on URL part. But there is also
> > >> response_mode=form_post when the code won't be available in the URI.
> > >
> > > May work for some, but I doubt it'll work for everyone.
> >
> > imo, this is something that should be added to the spec.  That the
> > code contains the callback URI.
> >
> > >
> > >
> > >> 4) Is it ok to have option to relax on code one-time use? Otherwise
> > >> in cross-DC and without sticky session, the every code exchange may
> > >> require SYNC request to another DCs to doublecheck code was not used
> already.
> > >> Not good for performance..
> > >>
> > > Maybe this is OK. Confidential apps needs credentials and then
> > > there's Proof Key for Code Exchange for public clients. Although the
> > latter
> > > may be another issue in cross-DC?
> > >
> > >
> > >> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> > >> Marek
> >
> > I think 1 and 4 will hobble us for future things we want to do.
> >
> > Bill
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Tue May 23 03:56:38 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 09:56:38 +0200
Subject: [keycloak-dev] Provide a Link to go Back to The Application on
 a Timeout
In-Reply-To: <CAJgngAfB2tkGyUXjnjCDegJMeNobbZTVYGVsrjy8u9DJEBasAw@mail.gmail.com>
References: <1407b445-a1bd-59ec-de72-8d689aeb712e@redhat.com>
	<CAJgngAfB2tkGyUXjnjCDegJMeNobbZTVYGVsrjy8u9DJEBasAw@mail.gmail.com>
Message-ID: <94ee3ab5-0d8b-29a6-37dd-49abcce3abbe@redhat.com>

On 19/05/17 09:19, Stian Thorgersen wrote:
> I don't like option 3. It's rather unlikely that's the app folks 
> actually want to go to in this case.
>
> I don't think option 1 is a full solution either. KC_RESTART cookie 
> may be missing as you say, but it could also be overwritten by another 
> client login.
>
> Can't we do option 2 in the code that redirects to the next step in 
> the flow? That way it's always there. We should also add to action 
> tokens so an invalid action token page can also display a link back to 
> the app.
Ok, so I've used the option 2 and added the "client_id" parameter to the 
links. Now error page should always contain "Back to application" link 
even if cookies are expired etc. Action tokens, brokering etc are 
covered too.

Marek
>
> On 17 May 2017 at 11:36, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     We have the issue that after session timeout, the page "An error
>     occurred, please login again through your application." can be shown.
>     This is even worse when there is no link to go back to the application
>     as users might be confused what to do. Details in
>     https://issues.jboss.org/browse/KEYCLOAK-4016
>     <https://issues.jboss.org/browse/KEYCLOAK-4016> .
>
>     This is already handled in many cases as when authentication
>     session is
>     expired, it is always restarted from the KC_RESTART cookie.
>
>     However there are still cases when this error is shown, which is when
>     the restart from the cookie failed. This can happen when browser
>     history
>     (including cookies) was cleared or when user restarted the browser (as
>     the KC_RESTART cookie is not persistent).
>
>     Some possibilities to solve:
>     1) Make the KC_RESTART cookie persistent. That will handle browser
>     restart, however it won't handle the case when browser history is
>     deleted
>
>     2) Add client-id to every link as Stefan Baust suggested. Then we can
>     add the link to client base uri on the page. This is more work
>     with the
>     possibility of error-prone if we miss to add the client-id to some
>     link.
>     Also we will be able to provide the link just if client has "base-uri"
>     configured.
>
>     3) Add the link to the account management application page. After
>     successful login will be shown list of applications in account
>     management and user can click to his favourite application. Message
>     would need to be changed to something like "An error occurred, please
>     login again through your application or go to the <link>list of
>     applications<link> and select your application after login."
>
>     My preference is 3, 2, 1. WDYT? Any other ideas?
>
>     Thanks,
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mposolda at redhat.com  Tue May 23 04:34:41 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 10:34:41 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
Message-ID: <d5499a3d-ef4d-b387-0766-00020c6e3f60@redhat.com>

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

From mposolda at redhat.com  Tue May 23 04:41:19 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 10:41:19 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
Message-ID: <3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>

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


From mposolda at redhat.com  Tue May 23 05:16:13 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 11:16:13 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
Message-ID: <99984039-6d48-1826-3c19-357beddc691b@redhat.com>

On 22/05/17 09:30, Stian Thorgersen wrote:
>
>
> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Followup on some previous emails I sent this week around sticky
>     sessions
>     and OIDC backchannel requests.
>
>     In shortcut, it would be ideal if we can achieve that backchannel
>     requests (code-to-token, refresh token, logouts etc) can
>     participate in
>     same sticky session like the browser request. It may be possible
>     in some
>     cases (our adapters, some loadbalancers, see previous email I sent
>     this
>     week) but not everytime. And looks we would need to support the case
>     when it's not possible.
>
>     I can start with code-to-token request as it's slightly more
>     complicated
>     then the others due to the reasons:
>
>     1) code must be single-use per OAuth2 / OIDC specification
>
>     2) userSession may not yet be available. In case that we use ASYNC
>     channel for communication between datacenters for transfer userSession
>     (which I think should be the default due to performance reasons), then
>     this example flow can happen:
>     - user successfully authenticated and userSession was created on DC1.
>     - code-to-token request is sent by the adapter to DC2. Note that this
>     request is usually sent very quickly after userSession is created.
>     - DC2 didn't yet received the message from DC1 about the new
>     userSession. So this userSession not yet available here.
>
>     Questions:
>     1) Could we remove a need from code-to-token endpoint to lookup
>     userSession? I see this as an option as long as code itself is JWT
>     signed with realm HMAC key encapsulating some info about user,
>     session_state etc. Among other things, this would require some
>     refactoring of protocolMappers (as userSession won't be available when
>     tokens are generated). But isn't it bad for security to have some
>     claims
>     directly to the code? It is query parameter, which may end visible in
>     browser history. IMO this is not big issue, but not 100% sure..
>
>
> Wouldn't the code also become rather big?
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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mposolda at redhat.com  Tue May 23 05:26:22 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 11:26:22 +0200
Subject: [keycloak-dev] Sticky sessions in backchannel requests
In-Reply-To: <CAJgngAcmVviTVmA9+o2hhk2q_edDPZ3waU9KxN+PPjuPdKKGxw@mail.gmail.com>
References: <b8ea6002-5149-21f9-3d02-ad86137e8193@redhat.com>
	<4f2bcaf6-6fe3-d76f-7e45-e91395636073@redhat.com>
	<f48b359b-64dd-b409-bb2e-055bba29751c@redhat.com>
	<ccd81a61-9a52-5b81-1564-4c61668a922d@redhat.com>
	<d82e7714-9ed2-bbf2-a685-1c835e570fcc@redhat.com>
	<CAJgngAcmVviTVmA9+o2hhk2q_edDPZ3waU9KxN+PPjuPdKKGxw@mail.gmail.com>
Message-ID: <3ba5e62d-4280-7a2a-40e4-216ce619471d@redhat.com>

On 22/05/17 09:15, Stian Thorgersen wrote:
> An application can only access a backend node directly if it's within 
> the same subnet. At that point it's not a big problem in either case 
> as local traffic can easily be configured to talk to nodes within the DC.
>
> Some pluggable way of setting headers/cookies or something that allows 
> load balancer to stick the requests is probably the best we can do. 
> Not even sure that'll even work between DCs as I believe that can be 
> handled at the DNS level. One option that could work is to have smart 
> proxies/routers. These would be replicated within DCs and have some 
> way of proxying requests to the correct node. That'd work for third 
> party apps and other things where you can get the client to set any 
> special headers etc.
>
> I second Bills suggestion of raising this on the OIDC mailing lists. 
> Marek could you do that?
Yes, will try to look into it this week.

Marek
>
> On 19 May 2017 at 17:08, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 19/05/17 16:31, Bill Burke wrote:
>     >
>     >
>     > On 5/19/17 10:29 AM, Marek Posolda wrote:
>     >> On 19/05/17 15:21, Bill Burke wrote:
>     >>> This issue comes up in:
>     >>>
>     >>> * code to token
>     >>>
>     >>> * refresh token
>     >>>
>     >>> * backchannel logout
>     >>>
>     >>> * access token validation (bearer token authentication)
>     >>>
>     >>> * Authorization and RPT
>     >>>
>     >>> * Token exchange
>     >>>
>     >>> Any others?
>     >>>
>     >>> We need to get on OIDC lists and discuss these types of issues
>     so that
>     >>> they can get standardized.
>     >> Good point. I can try to start discussion there.
>     >>>
>     >>> Other thoughts:
>     >>>
>     >>> * What if you talk to the node directly by providing a URL
>     claim in the
>     >>> token or code? The issue with that is that since we derive a
>     lot of
>     >>> things from the hostname of the request, we will need the
>     ability to
>     >>> override this.
>     >> You mean to bypass loadbalancer entirely and let the
>     application talk
>     >> to the backend node directly?
>     >>
>     >> Besides the hostname issue, there is another one, that backend node
>     >> may not be directly available. Those are typically on private
>     >> networks and it can be different private network that
>     application is
>     >> using. That was the case for example in RedHat IT environment.
>     >>
>     >> BTV. We already had similar possibility in adapter to directly talk
>     >> to backend node in backchannel requests. Instead of lookup the
>     >> backend node URL from claim, we had the option in adapter
>     >> configuration "auth-server-url-for-backend-requests" . But the
>     option
>     >> was removed due those issues like hostname, verifications of "iss"
>     >> claim in tokens etc.
>     >>
>     >
>     > Backchannel sticky session becomes quite difficult if you can't talk
>     > to node directly. Adapter will have to know to set a cookie that the
>     > loadbalancer can handle.  If the load balancer is using client IP to
>     > loadbalance, then you are SOL.
>     Yes, that's the pain with no easy solution. There is no standard for
>     loadbalancers and we don't know if people use private networks for
>     backend nodes or not etc :( Support for cookie in the adapter
>     request is
>     the option I would like to go, we agreed so far in different thread on
>     ML. For loadbalancing on client IP not sure we can handle that. Maybe
>     use "client-ip" as the claim in code or token and do some hacking
>     around
>     "X-" http headers in the adapter request to Keycloak?
>
>     Talking application to backend node directly has issues and AFAIK
>     Stian
>     don't like this option at all. Hostname issues, backend node not
>     available to the app etc. Perhaps he can add more.
>
>     Marek
>
>     >
>     > Bill
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From Sebastian.Schuster at bosch-si.com  Tue May 23 06:29:19 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 23 May 2017 10:29:19 +0000
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
Message-ID: <0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>

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 at bosch-si.com

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




> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> bounces at lists.jboss.org] On Behalf Of Marek Posolda
> Sent: Dienstag, 23. Mai 2017 10:41
> To: Bill Burke <bburke at redhat.com>; keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Tue May 23 07:56:28 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 13:56:28 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
Message-ID: <64f0552c-61f6-9276-9c49-c351a3423bf8@redhat.com>

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 at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>> bounces at lists.jboss.org] On Behalf Of Marek Posolda
>> Sent: Dienstag, 23. Mai 2017 10:41
>> To: Bill Burke <bburke at redhat.com>; keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Tue May 23 08:54:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 May 2017 14:54:43 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <99984039-6d48-1826-3c19-357beddc691b@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<99984039-6d48-1826-3c19-357beddc691b@redhat.com>
Message-ID: <CAJgngAd39QKRCVsJXUwGaFw6_o675jKfR=19s++vyhavyA7njA@mail.gmail.com>

On 23 May 2017 at 11:16, Marek Posolda <mposolda at redhat.com> wrote:

> On 22/05/17 09:30, Stian Thorgersen wrote:
>
>
>
> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Followup on some previous emails I sent this week around sticky sessions
>> and OIDC backchannel requests.
>>
>> In shortcut, it would be ideal if we can achieve that backchannel
>> requests (code-to-token, refresh token, logouts etc) can participate in
>> same sticky session like the browser request. It may be possible in some
>> cases (our adapters, some loadbalancers, see previous email I sent this
>> week) but not everytime. And looks we would need to support the case
>> when it's not possible.
>>
>> I can start with code-to-token request as it's slightly more complicated
>> then the others due to the reasons:
>>
>> 1) code must be single-use per OAuth2 / OIDC specification
>>
>> 2) userSession may not yet be available. In case that we use ASYNC
>> channel for communication between datacenters for transfer userSession
>> (which I think should be the default due to performance reasons), then
>> this example flow can happen:
>> - user successfully authenticated and userSession was created on DC1.
>> - code-to-token request is sent by the adapter to DC2. Note that this
>> request is usually sent very quickly after userSession is created.
>> - DC2 didn't yet received the message from DC1 about the new
>> userSession. So this userSession not yet available here.
>>
>> Questions:
>> 1) Could we remove a need from code-to-token endpoint to lookup
>> userSession? I see this as an option as long as code itself is JWT
>> signed with realm HMAC key encapsulating some info about user,
>> session_state etc. Among other things, this would require some
>> refactoring of protocolMappers (as userSession won't be available when
>> tokens are generated). But isn't it bad for security to have some claims
>> directly to the code? It is query parameter, which may end visible in
>> browser history. IMO this is not big issue, but not 100% sure..
>>
>
> Wouldn't the code also become rather big?
>
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From sthorger at redhat.com  Tue May 23 08:55:52 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 May 2017 14:55:52 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
Message-ID: <CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>

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 at 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 at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> > -----Original Message-----
> > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> > bounces at lists.jboss.org] On Behalf Of Marek Posolda
> > Sent: Dienstag, 23. Mai 2017 10:41
> > To: Bill Burke <bburke at redhat.com>; keycloak-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Tue May 23 09:11:07 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 May 2017 09:11:07 -0400
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
Message-ID: <ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>

No reason the code couldn't be "smarter" though.  Something simple and 
signed that has balancing/routing information in it.


On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
> I would like to argue against 1). Putting token content into the authcode kind of changes the flow to be more like the implicit flow.
> OIDC/OAuth2 offers the code flow especially to protect information in the tokens. Some claims could be sensitive and/or personal information
> and I think they should not be in the code. Furthermore, enforcing the single use of codes becomes even harder if they can be exchanged
> to tokens without looking up state first. Relaxing the one-time requirement is clearly against the spec and one should at least try hard to
> fulfill it IMHO.
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>> Sent: Montag, 22. Mai 2017 19:30
>> To: Bill Burke <bburke at redhat.com>
>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>
>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>
>>>
>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>
>>>>> Followup on some previous emails I sent this week around sticky
>>>>> sessions and OIDC backchannel requests.
>>>>>
>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>> participate in same sticky session like the browser request. It may
>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>> previous email I sent this
>>>>> week) but not everytime. And looks we would need to support the
>>>>> case when it's not possible.
>>>>>
>>>>> I can start with code-to-token request as it's slightly more
>>>>> complicated then the others due to the reasons:
>>>>>
>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>
>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>> channel for communication between datacenters for transfer
>>>>> userSession (which I think should be the default due to performance
>>>>> reasons), then this example flow can happen:
>>>>> - user successfully authenticated and userSession was created on DC1.
>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>> this request is usually sent very quickly after userSession is created.
>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>> userSession. So this userSession not yet available here.
>>>>>
>>>>> Questions:
>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>> session_state etc. Among other things, this would require some
>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>> when tokens are generated). But isn't it bad for security to have
>>>>> some claims directly to the code? It is query parameter, which may
>>>>> end visible in browser history. IMO this is not big issue, but not 100% sure..
>>>>>
>>>> Wouldn't the code also become rather big?
>>>>
>>>> I reckon protocol mappers should be refactored regardless though.
>>>> The details should be in the code and token not in the user session.
>>> For protocol mappers, the reason why the user session need to be
>>> available is that some component might be storing temporary
>>> information within the session that needs to be mapped to the token.
>>> Any example is a broker login that doesn't want or need to import into
>>> database, but instead stores in in the session.  Doesn't kerberos
>>> store stuff in the session that can be mapped to the token?  Finally,
>>> eventually we will want import-less brokering where the user is
>>> created within the session and destroyed with the session so we dont' have to hit
>> the DB and import.
>> True, so we basically will need to make sure the user session exists and is
>> persisted. I reckon on-demand replication if technically possible the best option.
>>
>>
>>>>> 2) Another option is let the code-to-token endpoint wait until
>>>>> userSession is available. Then we would need support for
>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>> issue and potential for DoS? Still even with asynchronous, the request times
>> can be quite long.
>>>> I like this option. Could we combine this with on demand replication?
>>> With
>>>> a configurable timeout this would be nifty IMO.
>>>
>>>
>>>>
>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>> itself, so the URL will look like:
>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>> seem
>>> to
>>>>> support sticky session based on URL part. But there is also
>>>>> response_mode=form_post when the code won't be available in the URI.
>>>> May work for some, but I doubt it'll work for everyone.
>>> imo, this is something that should be added to the spec.  That the
>>> code contains the callback URI.
>>>
>>>>
>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>> require SYNC request to another DCs to doublecheck code was not used
>> already.
>>>>> Not good for performance..
>>>>>
>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>> there's Proof Key for Code Exchange for public clients. Although the
>>> latter
>>>> may be another issue in cross-DC?
>>>>
>>>>
>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>> Marek
>>> I think 1 and 4 will hobble us for future things we want to do.
>>>
>>> Bill
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From Sebastian.Schuster at bosch-si.com  Tue May 23 09:36:46 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Tue, 23 May 2017 13:36:46 +0000
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
Message-ID: <a0f13f3d2ffc4c2dbfcc74e5340e3e10@FE-MBX1028.de.bosch.com>

As long as it is not user claims or other sensitive stuff, I am fine. Is the idea then to perform a redirect to another DC (with a DC-specific DNS name, not sure redirects on token endpoint are covered by the spec) or to have the load balancer of one DC forward directly to another DC (also not sure this is a common approach)? 

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Dienstag, 23. Mai 2017 15:11
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> stian at redhat.com
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> 
> No reason the code couldn't be "smarter" though.  Something simple and signed
> that has balancing/routing information in it.
> 
> 
> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
> > I would like to argue against 1). Putting token content into the authcode kind of
> changes the flow to be more like the implicit flow.
> > OIDC/OAuth2 offers the code flow especially to protect information in the
> tokens. Some claims could be sensitive and/or personal information
> > and I think they should not be in the code. Furthermore, enforcing the single use
> of codes becomes even harder if they can be exchanged
> > to tokens without looking up state first. Relaxing the one-time requirement is
> clearly against the spec and one should at least try hard to
> > fulfill it IMHO.
> >
> > Best regards,
> > Sebastian
> >
> > Mit freundlichen Gr??en / Best regards
> >
> >   Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin |
> GERMANY | www.bosch-si.com
> > Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-
> si.com
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> > Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> >> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
> >> Sent: Montag, 22. Mai 2017 19:30
> >> To: Bill Burke <bburke at redhat.com>
> >> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >>
> >> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
> >>
> >>>
> >>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
> >>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
> >>>>
> >>>>> Followup on some previous emails I sent this week around sticky
> >>>>> sessions and OIDC backchannel requests.
> >>>>>
> >>>>> In shortcut, it would be ideal if we can achieve that backchannel
> >>>>> requests (code-to-token, refresh token, logouts etc) can
> >>>>> participate in same sticky session like the browser request. It may
> >>>>> be possible in some cases (our adapters, some loadbalancers, see
> >>>>> previous email I sent this
> >>>>> week) but not everytime. And looks we would need to support the
> >>>>> case when it's not possible.
> >>>>>
> >>>>> I can start with code-to-token request as it's slightly more
> >>>>> complicated then the others due to the reasons:
> >>>>>
> >>>>> 1) code must be single-use per OAuth2 / OIDC specification
> >>>>>
> >>>>> 2) userSession may not yet be available. In case that we use ASYNC
> >>>>> channel for communication between datacenters for transfer
> >>>>> userSession (which I think should be the default due to performance
> >>>>> reasons), then this example flow can happen:
> >>>>> - user successfully authenticated and userSession was created on DC1.
> >>>>> - code-to-token request is sent by the adapter to DC2. Note that
> >>>>> this request is usually sent very quickly after userSession is created.
> >>>>> - DC2 didn't yet received the message from DC1 about the new
> >>>>> userSession. So this userSession not yet available here.
> >>>>>
> >>>>> Questions:
> >>>>> 1) Could we remove a need from code-to-token endpoint to lookup
> >>>>> userSession? I see this as an option as long as code itself is JWT
> >>>>> signed with realm HMAC key encapsulating some info about user,
> >>>>> session_state etc. Among other things, this would require some
> >>>>> refactoring of protocolMappers (as userSession won't be available
> >>>>> when tokens are generated). But isn't it bad for security to have
> >>>>> some claims directly to the code? It is query parameter, which may
> >>>>> end visible in browser history. IMO this is not big issue, but not 100% sure..
> >>>>>
> >>>> Wouldn't the code also become rather big?
> >>>>
> >>>> I reckon protocol mappers should be refactored regardless though.
> >>>> The details should be in the code and token not in the user session.
> >>> For protocol mappers, the reason why the user session need to be
> >>> available is that some component might be storing temporary
> >>> information within the session that needs to be mapped to the token.
> >>> Any example is a broker login that doesn't want or need to import into
> >>> database, but instead stores in in the session.  Doesn't kerberos
> >>> store stuff in the session that can be mapped to the token?  Finally,
> >>> eventually we will want import-less brokering where the user is
> >>> created within the session and destroyed with the session so we dont' have to
> hit
> >> the DB and import.
> >> True, so we basically will need to make sure the user session exists and is
> >> persisted. I reckon on-demand replication if technically possible the best
> option.
> >>
> >>
> >>>>> 2) Another option is let the code-to-token endpoint wait until
> >>>>> userSession is available. Then we would need support for
> >>>>> asynchronous requests? I can see blocking undertow workers in
> >>>>> waiting (something based on java.util.concurrent.Future) can be an
> >>>>> issue and potential for DoS? Still even with asynchronous, the request
> times
> >> can be quite long.
> >>>> I like this option. Could we combine this with on demand replication?
> >>> With
> >>>> a configurable timeout this would be nifty IMO.
> >>>
> >>>
> >>>>
> >>>>> 3) Can we encourage people to use sticky sessions at least for
> >>>>> code-to-token endpoint? We can add the route directly to the code
> >>>>> itself, so the URL will look like:
> >>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
> >>>>> seem
> >>> to
> >>>>> support sticky session based on URL part. But there is also
> >>>>> response_mode=form_post when the code won't be available in the URI.
> >>>> May work for some, but I doubt it'll work for everyone.
> >>> imo, this is something that should be added to the spec.  That the
> >>> code contains the callback URI.
> >>>
> >>>>
> >>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
> >>>>> in cross-DC and without sticky session, the every code exchange may
> >>>>> require SYNC request to another DCs to doublecheck code was not used
> >> already.
> >>>>> Not good for performance..
> >>>>>
> >>>> Maybe this is OK. Confidential apps needs credentials and then
> >>>> there's Proof Key for Code Exchange for public clients. Although the
> >>> latter
> >>>> may be another issue in cross-DC?
> >>>>
> >>>>
> >>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> >>>>> Marek
> >>> I think 1 and 4 will hobble us for future things we want to do.
> >>>
> >>> Bill
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From martin.hardselius at gmail.com  Tue May 23 10:19:48 2017
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Tue, 23 May 2017 14:19:48 +0000
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <CAJgngAfudZMeqqePDaYDutKtriJLbYTx04r867jbktNYQ1dWGA@mail.gmail.com>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
	<CAJgngAfudZMeqqePDaYDutKtriJLbYTx04r867jbktNYQ1dWGA@mail.gmail.com>
Message-ID: <CAPJq0L_tfLUQ94Fc496T52apL56w2wpvPnXbxRCTxPNrY1fdGQ@mail.gmail.com>

It clutters your local namespace.
On Mon, 22 May 2017 at 08:21, Stian Thorgersen <sthorger at redhat.com> wrote:

> Why is this a problem?
>
> On 19 May 2017 at 17:37, Bill Burke <bburke at redhat.com> wrote:
>
> > Please make your IDE import the full classname.  This is not allowed:
> >
> > import java.uti.*;
> >
> > All imports must be fully qualified.  A number of people are making this
> > mistake lately.
> >
> > Thanks,
> >
> > Bill
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Tue May 23 10:37:42 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 May 2017 10:37:42 -0400
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <CAPJq0L_tfLUQ94Fc496T52apL56w2wpvPnXbxRCTxPNrY1fdGQ@mail.gmail.com>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
	<CAJgngAfudZMeqqePDaYDutKtriJLbYTx04r867jbktNYQ1dWGA@mail.gmail.com>
	<CAPJq0L_tfLUQ94Fc496T52apL56w2wpvPnXbxRCTxPNrY1fdGQ@mail.gmail.com>
Message-ID: <0b026121-8ed7-bce1-e251-1d1a62ac080b@redhat.com>

Another one is, requires you to import code into an IDE to find where 
classes are i.e. if you're browsing code through github.  I find it 
useful other times as well, that I just can't remember.

On 5/23/17 10:19 AM, Martin Hardselius wrote:
> It clutters your local namespace.
> On Mon, 22 May 2017 at 08:21, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     Why is this a problem?
>
>     On 19 May 2017 at 17:37, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>     > Please make your IDE import the full classname.  This is not
>     allowed:
>     >
>     > import java.uti.*;
>     >
>     > All imports must be fully qualified.  A number of people are
>     making this
>     > mistake lately.
>     >
>     > Thanks,
>     >
>     > Bill
>     >
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From bburke at redhat.com  Tue May 23 11:34:02 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 May 2017 11:34:02 -0400
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <a0f13f3d2ffc4c2dbfcc74e5340e3e10@FE-MBX1028.de.bosch.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
	<a0f13f3d2ffc4c2dbfcc74e5340e3e10@FE-MBX1028.de.bosch.com>
Message-ID: <e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>

What about redirection?  client makes code-to-token request and possibly 
gets a 302 and Location header back as response.  Is that better or 
worse than server-to-server request forwarding?


On 5/23/17 9:36 AM, Schuster Sebastian (INST/ESY1) wrote:
> As long as it is not user claims or other sensitive stuff, I am fine. Is the idea then to perform a redirect to another DC (with a DC-specific DNS name, not sure redirects on token endpoint are covered by the spec) or to have the load balancer of one DC forward directly to another DC (also not sure this is a common approach)?
>
> Mit freundlichen Gr??en / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke at redhat.com]
>> Sent: Dienstag, 23. Mai 2017 15:11
>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>> stian at redhat.com
>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>
>> No reason the code couldn't be "smarter" though.  Something simple and signed
>> that has balancing/routing information in it.
>>
>>
>> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
>>> I would like to argue against 1). Putting token content into the authcode kind of
>> changes the flow to be more like the implicit flow.
>>> OIDC/OAuth2 offers the code flow especially to protect information in the
>> tokens. Some claims could be sensitive and/or personal information
>>> and I think they should not be in the code. Furthermore, enforcing the single use
>> of codes becomes even harder if they can be exchanged
>>> to tokens without looking up state first. Relaxing the one-time requirement is
>> clearly against the spec and one should at least try hard to
>>> fulfill it IMHO.
>>>
>>> Best regards,
>>> Sebastian
>>>
>>> Mit freundlichen Gr??en / Best regards
>>>
>>>    Sebastian Schuster
>>>
>>> Engineering and Support (INST/ESY1)
>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin |
>> GERMANY | www.bosch-si.com
>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-
>> si.com
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>>>> Sent: Montag, 22. Mai 2017 19:30
>>>> To: Bill Burke <bburke at redhat.com>
>>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>
>>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>>>
>>>>>>> Followup on some previous emails I sent this week around sticky
>>>>>>> sessions and OIDC backchannel requests.
>>>>>>>
>>>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>>>> participate in same sticky session like the browser request. It may
>>>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>>>> previous email I sent this
>>>>>>> week) but not everytime. And looks we would need to support the
>>>>>>> case when it's not possible.
>>>>>>>
>>>>>>> I can start with code-to-token request as it's slightly more
>>>>>>> complicated then the others due to the reasons:
>>>>>>>
>>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>>>
>>>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>>>> channel for communication between datacenters for transfer
>>>>>>> userSession (which I think should be the default due to performance
>>>>>>> reasons), then this example flow can happen:
>>>>>>> - user successfully authenticated and userSession was created on DC1.
>>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>>>> this request is usually sent very quickly after userSession is created.
>>>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>>>> userSession. So this userSession not yet available here.
>>>>>>>
>>>>>>> Questions:
>>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>>>> session_state etc. Among other things, this would require some
>>>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>>>> when tokens are generated). But isn't it bad for security to have
>>>>>>> some claims directly to the code? It is query parameter, which may
>>>>>>> end visible in browser history. IMO this is not big issue, but not 100% sure..
>>>>>>>
>>>>>> Wouldn't the code also become rather big?
>>>>>>
>>>>>> I reckon protocol mappers should be refactored regardless though.
>>>>>> The details should be in the code and token not in the user session.
>>>>> For protocol mappers, the reason why the user session need to be
>>>>> available is that some component might be storing temporary
>>>>> information within the session that needs to be mapped to the token.
>>>>> Any example is a broker login that doesn't want or need to import into
>>>>> database, but instead stores in in the session.  Doesn't kerberos
>>>>> store stuff in the session that can be mapped to the token?  Finally,
>>>>> eventually we will want import-less brokering where the user is
>>>>> created within the session and destroyed with the session so we dont' have to
>> hit
>>>> the DB and import.
>>>> True, so we basically will need to make sure the user session exists and is
>>>> persisted. I reckon on-demand replication if technically possible the best
>> option.
>>>>
>>>>>>> 2) Another option is let the code-to-token endpoint wait until
>>>>>>> userSession is available. Then we would need support for
>>>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>>>> issue and potential for DoS? Still even with asynchronous, the request
>> times
>>>> can be quite long.
>>>>>> I like this option. Could we combine this with on demand replication?
>>>>> With
>>>>>> a configurable timeout this would be nifty IMO.
>>>>>
>>>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>>>> itself, so the URL will look like:
>>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>>>> seem
>>>>> to
>>>>>>> support sticky session based on URL part. But there is also
>>>>>>> response_mode=form_post when the code won't be available in the URI.
>>>>>> May work for some, but I doubt it'll work for everyone.
>>>>> imo, this is something that should be added to the spec.  That the
>>>>> code contains the callback URI.
>>>>>
>>>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>>>> require SYNC request to another DCs to doublecheck code was not used
>>>> already.
>>>>>>> Not good for performance..
>>>>>>>
>>>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>>>> there's Proof Key for Code Exchange for public clients. Although the
>>>>> latter
>>>>>> may be another issue in cross-DC?
>>>>>>
>>>>>>
>>>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>>>> Marek
>>>>> I think 1 and 4 will hobble us for future things we want to do.
>>>>>
>>>>> Bill
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Tue May 23 14:11:23 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 May 2017 20:11:23 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
	<a0f13f3d2ffc4c2dbfcc74e5340e3e10@FE-MBX1028.de.bosch.com>
	<e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>
Message-ID: <CAJgngAc1Gpw_WdpNh9+K6Cc7SsX2yoJL6eNcF6Anzb8xnXg7vg@mail.gmail.com>

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 at 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 at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke at redhat.com]
>>> Sent: Dienstag, 23. Mai 2017 15:11
>>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>>> stian at redhat.com
>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>
>>> No reason the code couldn't be "smarter" though.  Something simple and
>>> signed
>>> that has balancing/routing information in it.
>>>
>>>
>>> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
>>>
>>>> I would like to argue against 1). Putting token content into the
>>>> authcode kind of
>>>>
>>> changes the flow to be more like the implicit flow.
>>>
>>>> OIDC/OAuth2 offers the code flow especially to protect information in
>>>> the
>>>>
>>> tokens. Some claims could be sensitive and/or personal information
>>>
>>>> and I think they should not be in the code. Furthermore, enforcing the
>>>> single use
>>>>
>>> of codes becomes even harder if they can be exchanged
>>>
>>>> to tokens without looking up state first. Relaxing the one-time
>>>> requirement is
>>>>
>>> clearly against the spec and one should at least try hard to
>>>
>>>> fulfill it IMHO.
>>>>
>>>> Best regards,
>>>> Sebastian
>>>>
>>>> Mit freundlichen Gr??en / Best regards
>>>>
>>>>    Sebastian Schuster
>>>>
>>>> Engineering and Support (INST/ESY1)
>>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
>>>> Berlin |
>>>>
>>> GERMANY | www.bosch-si.com
>>>
>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
>>>> Sebastian.Schuster at bosch-
>>>>
>>> si.com
>>>
>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>>>>> Sent: Montag, 22. Mai 2017 19:30
>>>>> To: Bill Burke <bburke at redhat.com>
>>>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>>
>>>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>>>>
>>>>>>> Followup on some previous emails I sent this week around sticky
>>>>>>>> sessions and OIDC backchannel requests.
>>>>>>>>
>>>>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>>>>> participate in same sticky session like the browser request. It may
>>>>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>>>>> previous email I sent this
>>>>>>>> week) but not everytime. And looks we would need to support the
>>>>>>>> case when it's not possible.
>>>>>>>>
>>>>>>>> I can start with code-to-token request as it's slightly more
>>>>>>>> complicated then the others due to the reasons:
>>>>>>>>
>>>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>>>>
>>>>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>>>>> channel for communication between datacenters for transfer
>>>>>>>> userSession (which I think should be the default due to performance
>>>>>>>> reasons), then this example flow can happen:
>>>>>>>> - user successfully authenticated and userSession was created on
>>>>>>>> DC1.
>>>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>>>>> this request is usually sent very quickly after userSession is
>>>>>>>> created.
>>>>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>>>>> userSession. So this userSession not yet available here.
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>>>>> session_state etc. Among other things, this would require some
>>>>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>>>>> when tokens are generated). But isn't it bad for security to have
>>>>>>>> some claims directly to the code? It is query parameter, which may
>>>>>>>> end visible in browser history. IMO this is not big issue, but not
>>>>>>>> 100% sure..
>>>>>>>>
>>>>>>>> Wouldn't the code also become rather big?
>>>>>>>
>>>>>>> I reckon protocol mappers should be refactored regardless though.
>>>>>>> The details should be in the code and token not in the user session.
>>>>>>>
>>>>>> For protocol mappers, the reason why the user session need to be
>>>>>> available is that some component might be storing temporary
>>>>>> information within the session that needs to be mapped to the token.
>>>>>> Any example is a broker login that doesn't want or need to import into
>>>>>> database, but instead stores in in the session.  Doesn't kerberos
>>>>>> store stuff in the session that can be mapped to the token?  Finally,
>>>>>> eventually we will want import-less brokering where the user is
>>>>>> created within the session and destroyed with the session so we dont'
>>>>>> have to
>>>>>>
>>>>> hit
>>>
>>>> the DB and import.
>>>>> True, so we basically will need to make sure the user session exists
>>>>> and is
>>>>> persisted. I reckon on-demand replication if technically possible the
>>>>> best
>>>>>
>>>> option.
>>>
>>>>
>>>>> 2) Another option is let the code-to-token endpoint wait until
>>>>>>>> userSession is available. Then we would need support for
>>>>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>>>>> issue and potential for DoS? Still even with asynchronous, the
>>>>>>>> request
>>>>>>>>
>>>>>>> times
>>>
>>>> can be quite long.
>>>>>
>>>>>> I like this option. Could we combine this with on demand replication?
>>>>>>>
>>>>>> With
>>>>>>
>>>>>>> a configurable timeout this would be nifty IMO.
>>>>>>>
>>>>>>
>>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>>>>> itself, so the URL will look like:
>>>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>>>>> seem
>>>>>>>>
>>>>>>> to
>>>>>>
>>>>>>> support sticky session based on URL part. But there is also
>>>>>>>> response_mode=form_post when the code won't be available in the URI.
>>>>>>>>
>>>>>>> May work for some, but I doubt it'll work for everyone.
>>>>>>>
>>>>>> imo, this is something that should be added to the spec.  That the
>>>>>> code contains the callback URI.
>>>>>>
>>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>>>>> require SYNC request to another DCs to doublecheck code was not used
>>>>>>>>
>>>>>>> already.
>>>>>
>>>>>> Not good for performance..
>>>>>>>>
>>>>>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>>>>> there's Proof Key for Code Exchange for public clients. Although the
>>>>>>>
>>>>>> latter
>>>>>>
>>>>>>> may be another issue in cross-DC?
>>>>>>>
>>>>>>>
>>>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>>>>> Marek
>>>>>>>>
>>>>>>> I think 1 and 4 will hobble us for future things we want to do.
>>>>>>
>>>>>> Bill
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>

From sthorger at redhat.com  Tue May 23 14:11:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 May 2017 20:11:57 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
Message-ID: <CAJgngAfNisv5a7PpzrxLdDGo69PpXWYydxVC_SQ7bLF1JWoPSQ@mail.gmail.com>

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 at 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 at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>>> Sent: Montag, 22. Mai 2017 19:30
>>> To: Bill Burke <bburke at redhat.com>
>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>
>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>
>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>
>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>>
>>>>> Followup on some previous emails I sent this week around sticky
>>>>>> sessions and OIDC backchannel requests.
>>>>>>
>>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>>> participate in same sticky session like the browser request. It may
>>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>>> previous email I sent this
>>>>>> week) but not everytime. And looks we would need to support the
>>>>>> case when it's not possible.
>>>>>>
>>>>>> I can start with code-to-token request as it's slightly more
>>>>>> complicated then the others due to the reasons:
>>>>>>
>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>>
>>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>>> channel for communication between datacenters for transfer
>>>>>> userSession (which I think should be the default due to performance
>>>>>> reasons), then this example flow can happen:
>>>>>> - user successfully authenticated and userSession was created on DC1.
>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>>> this request is usually sent very quickly after userSession is
>>>>>> created.
>>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>>> userSession. So this userSession not yet available here.
>>>>>>
>>>>>> Questions:
>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>>> session_state etc. Among other things, this would require some
>>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>>> when tokens are generated). But isn't it bad for security to have
>>>>>> some claims directly to the code? It is query parameter, which may
>>>>>> end visible in browser history. IMO this is not big issue, but not
>>>>>> 100% sure..
>>>>>>
>>>>>> Wouldn't the code also become rather big?
>>>>>
>>>>> I reckon protocol mappers should be refactored regardless though.
>>>>> The details should be in the code and token not in the user session.
>>>>>
>>>> For protocol mappers, the reason why the user session need to be
>>>> available is that some component might be storing temporary
>>>> information within the session that needs to be mapped to the token.
>>>> Any example is a broker login that doesn't want or need to import into
>>>> database, but instead stores in in the session.  Doesn't kerberos
>>>> store stuff in the session that can be mapped to the token?  Finally,
>>>> eventually we will want import-less brokering where the user is
>>>> created within the session and destroyed with the session so we dont'
>>>> have to hit
>>>>
>>> the DB and import.
>>> True, so we basically will need to make sure the user session exists and
>>> is
>>> persisted. I reckon on-demand replication if technically possible the
>>> best option.
>>>
>>>
>>> 2) Another option is let the code-to-token endpoint wait until
>>>>>> userSession is available. Then we would need support for
>>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>>> issue and potential for DoS? Still even with asynchronous, the
>>>>>> request times
>>>>>>
>>>>> can be quite long.
>>>
>>>> I like this option. Could we combine this with on demand replication?
>>>>>
>>>> With
>>>>
>>>>> a configurable timeout this would be nifty IMO.
>>>>>
>>>>
>>>>
>>>>
>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>>> itself, so the URL will look like:
>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>>> seem
>>>>>>
>>>>> to
>>>>
>>>>> support sticky session based on URL part. But there is also
>>>>>> response_mode=form_post when the code won't be available in the URI.
>>>>>>
>>>>> May work for some, but I doubt it'll work for everyone.
>>>>>
>>>> imo, this is something that should be added to the spec.  That the
>>>> code contains the callback URI.
>>>>
>>>>
>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>>> require SYNC request to another DCs to doublecheck code was not used
>>>>>>
>>>>> already.
>>>
>>>> Not good for performance..
>>>>>>
>>>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>>> there's Proof Key for Code Exchange for public clients. Although the
>>>>>
>>>> latter
>>>>
>>>>> may be another issue in cross-DC?
>>>>>
>>>>>
>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>>> Marek
>>>>>>
>>>>> I think 1 and 4 will hobble us for future things we want to do.
>>>>
>>>> Bill
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

From mposolda at redhat.com  Tue May 23 15:43:47 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 21:43:47 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
Message-ID: <c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>

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 at bosch-si.com 
> <mailto:Sebastian.Schuster at 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 at bosch-si.com
>     <mailto:Sebastian.Schuster at bosch-si.com>
>
>     Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
>     148411 B
>     Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>     > -----Original Message-----
>     > From: keycloak-dev-bounces at lists.jboss.org
>     <mailto:keycloak-dev-bounces at lists.jboss.org>
>     [mailto:keycloak-dev- <mailto:keycloak-dev->
>     >bounces at lists.jboss.org <mailto:bounces at lists.jboss.org>] On
>     Behalf Of Marek Posolda
>     > Sent: Dienstag, 23. Mai 2017 10:41
>     > To: Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>>;
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mposolda at redhat.com  Tue May 23 16:05:10 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 May 2017 22:05:10 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
	<a0f13f3d2ffc4c2dbfcc74e5340e3e10@FE-MBX1028.de.bosch.com>
	<e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>
Message-ID: <d51ba141-f2b8-334a-a2f6-ac6f14d59dfd@redhat.com>

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 at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Bill Burke [mailto:bburke at redhat.com]
>>> Sent: Dienstag, 23. Mai 2017 15:11
>>> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
>>> stian at redhat.com
>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>
>>> No reason the code couldn't be "smarter" though.  Something simple and signed
>>> that has balancing/routing information in it.
>>>
>>>
>>> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
>>>> I would like to argue against 1). Putting token content into the authcode kind of
>>> changes the flow to be more like the implicit flow.
>>>> OIDC/OAuth2 offers the code flow especially to protect information in the
>>> tokens. Some claims could be sensitive and/or personal information
>>>> and I think they should not be in the code. Furthermore, enforcing the single use
>>> of codes becomes even harder if they can be exchanged
>>>> to tokens without looking up state first. Relaxing the one-time requirement is
>>> clearly against the spec and one should at least try hard to
>>>> fulfill it IMHO.
>>>>
>>>> Best regards,
>>>> Sebastian
>>>>
>>>> Mit freundlichen Gr??en / Best regards
>>>>
>>>>     Sebastian Schuster
>>>>
>>>> Engineering and Support (INST/ESY1)
>>>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785 Berlin |
>>> GERMANY | www.bosch-si.com
>>>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-
>>> si.com
>>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>>>>> Sent: Montag, 22. Mai 2017 19:30
>>>>> To: Bill Burke <bburke at redhat.com>
>>>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>>
>>>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>>>>
>>>>>>>> Followup on some previous emails I sent this week around sticky
>>>>>>>> sessions and OIDC backchannel requests.
>>>>>>>>
>>>>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>>>>> participate in same sticky session like the browser request. It may
>>>>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>>>>> previous email I sent this
>>>>>>>> week) but not everytime. And looks we would need to support the
>>>>>>>> case when it's not possible.
>>>>>>>>
>>>>>>>> I can start with code-to-token request as it's slightly more
>>>>>>>> complicated then the others due to the reasons:
>>>>>>>>
>>>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>>>>
>>>>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>>>>> channel for communication between datacenters for transfer
>>>>>>>> userSession (which I think should be the default due to performance
>>>>>>>> reasons), then this example flow can happen:
>>>>>>>> - user successfully authenticated and userSession was created on DC1.
>>>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>>>>> this request is usually sent very quickly after userSession is created.
>>>>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>>>>> userSession. So this userSession not yet available here.
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>>>>> session_state etc. Among other things, this would require some
>>>>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>>>>> when tokens are generated). But isn't it bad for security to have
>>>>>>>> some claims directly to the code? It is query parameter, which may
>>>>>>>> end visible in browser history. IMO this is not big issue, but not 100% sure..
>>>>>>>>
>>>>>>> Wouldn't the code also become rather big?
>>>>>>>
>>>>>>> I reckon protocol mappers should be refactored regardless though.
>>>>>>> The details should be in the code and token not in the user session.
>>>>>> For protocol mappers, the reason why the user session need to be
>>>>>> available is that some component might be storing temporary
>>>>>> information within the session that needs to be mapped to the token.
>>>>>> Any example is a broker login that doesn't want or need to import into
>>>>>> database, but instead stores in in the session.  Doesn't kerberos
>>>>>> store stuff in the session that can be mapped to the token?  Finally,
>>>>>> eventually we will want import-less brokering where the user is
>>>>>> created within the session and destroyed with the session so we dont' have to
>>> hit
>>>>> the DB and import.
>>>>> True, so we basically will need to make sure the user session exists and is
>>>>> persisted. I reckon on-demand replication if technically possible the best
>>> option.
>>>>>>>> 2) Another option is let the code-to-token endpoint wait until
>>>>>>>> userSession is available. Then we would need support for
>>>>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>>>>> issue and potential for DoS? Still even with asynchronous, the request
>>> times
>>>>> can be quite long.
>>>>>>> I like this option. Could we combine this with on demand replication?
>>>>>> With
>>>>>>> a configurable timeout this would be nifty IMO.
>>>>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>>>>> itself, so the URL will look like:
>>>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>>>>> seem
>>>>>> to
>>>>>>>> support sticky session based on URL part. But there is also
>>>>>>>> response_mode=form_post when the code won't be available in the URI.
>>>>>>> May work for some, but I doubt it'll work for everyone.
>>>>>> imo, this is something that should be added to the spec.  That the
>>>>>> code contains the callback URI.
>>>>>>
>>>>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>>>>> require SYNC request to another DCs to doublecheck code was not used
>>>>> already.
>>>>>>>> Not good for performance..
>>>>>>>>
>>>>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>>>>> there's Proof Key for Code Exchange for public clients. Although the
>>>>>> latter
>>>>>>> may be another issue in cross-DC?
>>>>>>>
>>>>>>>
>>>>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>>>>> Marek
>>>>>> I think 1 and 4 will hobble us for future things we want to do.
>>>>>>
>>>>>> Bill
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Wed May 24 00:23:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 May 2017 06:23:57 +0200
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <CAPJq0L_tfLUQ94Fc496T52apL56w2wpvPnXbxRCTxPNrY1fdGQ@mail.gmail.com>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
	<CAJgngAfudZMeqqePDaYDutKtriJLbYTx04r867jbktNYQ1dWGA@mail.gmail.com>
	<CAPJq0L_tfLUQ94Fc496T52apL56w2wpvPnXbxRCTxPNrY1fdGQ@mail.gmail.com>
Message-ID: <CAJgngAfvyq9u2OfkDW8-fT7ddwgFQnkJO=4mJk2O+pMNMasuwA@mail.gmail.com>

What do you mean?

On 23 May 2017 at 16:19, Martin Hardselius <martin.hardselius at gmail.com>
wrote:

> It clutters your local namespace.
> On Mon, 22 May 2017 at 08:21, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Why is this a problem?
>>
>> On 19 May 2017 at 17:37, Bill Burke <bburke at redhat.com> wrote:
>>
>> > Please make your IDE import the full classname.  This is not allowed:
>> >
>> > import java.uti.*;
>> >
>> > All imports must be fully qualified.  A number of people are making this
>> > mistake lately.
>> >
>> > Thanks,
>> >
>> > Bill
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Wed May 24 00:25:06 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 May 2017 06:25:06 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
Message-ID: <CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>

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 at 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 at 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 at bosch-si.com
>>
>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>> > bounces at lists.jboss.org] On Behalf Of Marek Posolda
>> > Sent: Dienstag, 23. Mai 2017 10:41
>> > To: Bill Burke <bburke at redhat.com>; keycloak-dev at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From Sebastian.Schuster at bosch-si.com  Wed May 24 02:38:23 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 24 May 2017 06:38:23 +0000
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
	<a0f13f3d2ffc4c2dbfcc74e5340e3e10@FE-MBX1028.de.bosch.com>
	<e601a6c3-ffe9-d939-29f4-3b58618ca73f@redhat.com>
Message-ID: <f599250c2abe492db22ca21bc5e1989d@FE-MBX1028.de.bosch.com>

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

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Dienstag, 23. Mai 2017 17:34
> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> stian at redhat.com
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> 
> What about redirection?  client makes code-to-token request and possibly gets a
> 302 and Location header back as response.  Is that better or worse than server-to-
> server request forwarding?
> 
> 
> On 5/23/17 9:36 AM, Schuster Sebastian (INST/ESY1) wrote:
> > As long as it is not user claims or other sensitive stuff, I am fine. Is the idea then
> to perform a redirect to another DC (with a DC-specific DNS name, not sure
> redirects on token endpoint are covered by the spec) or to have the load balancer
> of one DC forward directly to another DC (also not sure this is a common
> approach)?
> >
> > Mit freundlichen Gr??en / Best regards
> >
> >   Sebastian Schuster
> >
> > Engineering and Support (INST/ESY1)
> > Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
> > Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Fax +49
> > 30 726112-100 | Sebastian.Schuster at bosch-si.com
> >
> > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411
> > B
> > Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Bill Burke [mailto:bburke at redhat.com]
> >> Sent: Dienstag, 23. Mai 2017 15:11
> >> To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>;
> >> stian at redhat.com
> >> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >>
> >> No reason the code couldn't be "smarter" though.  Something simple
> >> and signed that has balancing/routing information in it.
> >>
> >>
> >> On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
> >>> I would like to argue against 1). Putting token content into the
> >>> authcode kind of
> >> changes the flow to be more like the implicit flow.
> >>> OIDC/OAuth2 offers the code flow especially to protect information
> >>> in the
> >> tokens. Some claims could be sensitive and/or personal information
> >>> and I think they should not be in the code. Furthermore, enforcing
> >>> the single use
> >> of codes becomes even harder if they can be exchanged
> >>> to tokens without looking up state first. Relaxing the one-time
> >>> requirement is
> >> clearly against the spec and one should at least try hard to
> >>> fulfill it IMHO.
> >>>
> >>> Best regards,
> >>> Sebastian
> >>>
> >>> Mit freundlichen Gr??en / Best regards
> >>>
> >>>    Sebastian Schuster
> >>>
> >>> Engineering and Support (INST/ESY1)
> >>> Bosch Software Innovations GmbH | Sch?neberger Ufer 89-91 | 10785
> >>> Berlin |
> >> GERMANY | www.bosch-si.com
> >>> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> >>> Sebastian.Schuster at bosch-
> >> si.com
> >>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB
> >>> 148411 B
> >>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> >>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
> >>>> Sent: Montag, 22. Mai 2017 19:30
> >>>> To: Bill Burke <bburke at redhat.com>
> >>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> >>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
> >>>>
> >>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
> >>>>
> >>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
> >>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com>
> wrote:
> >>>>>>
> >>>>>>> Followup on some previous emails I sent this week around sticky
> >>>>>>> sessions and OIDC backchannel requests.
> >>>>>>>
> >>>>>>> In shortcut, it would be ideal if we can achieve that
> >>>>>>> backchannel requests (code-to-token, refresh token, logouts etc)
> >>>>>>> can participate in same sticky session like the browser request.
> >>>>>>> It may be possible in some cases (our adapters, some
> >>>>>>> loadbalancers, see previous email I sent this
> >>>>>>> week) but not everytime. And looks we would need to support the
> >>>>>>> case when it's not possible.
> >>>>>>>
> >>>>>>> I can start with code-to-token request as it's slightly more
> >>>>>>> complicated then the others due to the reasons:
> >>>>>>>
> >>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
> >>>>>>>
> >>>>>>> 2) userSession may not yet be available. In case that we use
> >>>>>>> ASYNC channel for communication between datacenters for transfer
> >>>>>>> userSession (which I think should be the default due to
> >>>>>>> performance reasons), then this example flow can happen:
> >>>>>>> - user successfully authenticated and userSession was created on DC1.
> >>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
> >>>>>>> this request is usually sent very quickly after userSession is created.
> >>>>>>> - DC2 didn't yet received the message from DC1 about the new
> >>>>>>> userSession. So this userSession not yet available here.
> >>>>>>>
> >>>>>>> Questions:
> >>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
> >>>>>>> userSession? I see this as an option as long as code itself is
> >>>>>>> JWT signed with realm HMAC key encapsulating some info about
> >>>>>>> user, session_state etc. Among other things, this would require
> >>>>>>> some refactoring of protocolMappers (as userSession won't be
> >>>>>>> available when tokens are generated). But isn't it bad for
> >>>>>>> security to have some claims directly to the code? It is query
> >>>>>>> parameter, which may end visible in browser history. IMO this is not big
> issue, but not 100% sure..
> >>>>>>>
> >>>>>> Wouldn't the code also become rather big?
> >>>>>>
> >>>>>> I reckon protocol mappers should be refactored regardless though.
> >>>>>> The details should be in the code and token not in the user session.
> >>>>> For protocol mappers, the reason why the user session need to be
> >>>>> available is that some component might be storing temporary
> >>>>> information within the session that needs to be mapped to the token.
> >>>>> Any example is a broker login that doesn't want or need to import
> >>>>> into database, but instead stores in in the session.  Doesn't
> >>>>> kerberos store stuff in the session that can be mapped to the
> >>>>> token?  Finally, eventually we will want import-less brokering
> >>>>> where the user is created within the session and destroyed with
> >>>>> the session so we dont' have to
> >> hit
> >>>> the DB and import.
> >>>> True, so we basically will need to make sure the user session
> >>>> exists and is persisted. I reckon on-demand replication if
> >>>> technically possible the best
> >> option.
> >>>>
> >>>>>>> 2) Another option is let the code-to-token endpoint wait until
> >>>>>>> userSession is available. Then we would need support for
> >>>>>>> asynchronous requests? I can see blocking undertow workers in
> >>>>>>> waiting (something based on java.util.concurrent.Future) can be
> >>>>>>> an issue and potential for DoS? Still even with asynchronous,
> >>>>>>> the request
> >> times
> >>>> can be quite long.
> >>>>>> I like this option. Could we combine this with on demand replication?
> >>>>> With
> >>>>>> a configurable timeout this would be nifty IMO.
> >>>>>
> >>>>>>> 3) Can we encourage people to use sticky sessions at least for
> >>>>>>> code-to-token endpoint? We can add the route directly to the
> >>>>>>> code itself, so the URL will look like:
> >>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
> >>>>>>> seem
> >>>>> to
> >>>>>>> support sticky session based on URL part. But there is also
> >>>>>>> response_mode=form_post when the code won't be available in the URI.
> >>>>>> May work for some, but I doubt it'll work for everyone.
> >>>>> imo, this is something that should be added to the spec.  That the
> >>>>> code contains the callback URI.
> >>>>>
> >>>>>>> 4) Is it ok to have option to relax on code one-time use?
> >>>>>>> Otherwise in cross-DC and without sticky session, the every code
> >>>>>>> exchange may require SYNC request to another DCs to doublecheck
> >>>>>>> code was not used
> >>>> already.
> >>>>>>> Not good for performance..
> >>>>>>>
> >>>>>> Maybe this is OK. Confidential apps needs credentials and then
> >>>>>> there's Proof Key for Code Exchange for public clients. Although
> >>>>>> the
> >>>>> latter
> >>>>>> may be another issue in cross-DC?
> >>>>>>
> >>>>>>
> >>>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> >>>>>>> Marek
> >>>>> I think 1 and 4 will hobble us for future things we want to do.
> >>>>>
> >>>>> Bill
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From Sebastian.Schuster at bosch-si.com  Wed May 24 02:53:10 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 24 May 2017 06:53:10 +0000
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
	<CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
Message-ID: <6f757443e58c43b0b0748d13451cbe7e@FE-MBX1028.de.bosch.com>

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 at bosch-si.com<mailto:Sebastian.Schuster at 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 at redhat.com]
Sent: Mittwoch, 24. Mai 2017 06:25
To: Marek Posolda <mposolda at redhat.com>
Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>; Bill Burke <bburke at redhat.com>; keycloak-dev at 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 at redhat.com<mailto:mposolda at 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 at bosch-si.com<mailto:Sebastian.Schuster at 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 at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

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




> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org> [mailto:keycloak-dev-<mailto:keycloak-dev->
> bounces at lists.jboss.org<mailto:bounces at lists.jboss.org>] On Behalf Of Marek Posolda
> Sent: Dienstag, 23. Mai 2017 10:41
> To: Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>; keycloak-dev at lists.jboss.org<mailto:keycloak-dev at 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 at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev





From mposolda at redhat.com  Wed May 24 03:02:22 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 May 2017 09:02:22 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
	<CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
Message-ID: <ceebc50d-ac3f-adf3-9e9e-68957ef0b043@redhat.com>

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 at redhat.com 
> <mailto:mposolda at 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 at bosch-si.com
>>     <mailto:Sebastian.Schuster at 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 at bosch-si.com
>>         <mailto:Sebastian.Schuster at bosch-si.com>
>>
>>         Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg;
>>         HRB 148411 B
>>         Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>>         > -----Original Message-----
>>         > From: keycloak-dev-bounces at lists.jboss.org
>>         <mailto:keycloak-dev-bounces at lists.jboss.org>
>>         [mailto:keycloak-dev- <mailto:keycloak-dev->
>>         >bounces at lists.jboss.org <mailto:bounces at lists.jboss.org>] On
>>         Behalf Of Marek Posolda
>>         > Sent: Dienstag, 23. Mai 2017 10:41
>>         > To: Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>>; keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From mposolda at redhat.com  Wed May 24 03:06:15 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 May 2017 09:06:15 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAfNisv5a7PpzrxLdDGo69PpXWYydxVC_SQ7bLF1JWoPSQ@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<CAJgngAf5g1ESLDavUg=chJhyFEUZx1sYvb8hOexDQLe0z0jrVw@mail.gmail.com>
	<c2a11f2bf43947f5a2516d51fb17c7a3@FE-MBX1028.de.bosch.com>
	<ea322ffb-0aed-677b-ffea-c62033560083@redhat.com>
	<CAJgngAfNisv5a7PpzrxLdDGo69PpXWYydxVC_SQ7bLF1JWoPSQ@mail.gmail.com>
Message-ID: <a8bb4947-3f3a-e8cf-5f3f-aa2952fec40c@redhat.com>

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 at 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 at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>>>> Sent: Montag, 22. Mai 2017 19:30
>>>> To: Bill Burke <bburke at redhat.com>
>>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>>>
>>>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>
>>>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>>>
>>>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>>>
>>>>>> Followup on some previous emails I sent this week around sticky
>>>>>>> sessions and OIDC backchannel requests.
>>>>>>>
>>>>>>> In shortcut, it would be ideal if we can achieve that backchannel
>>>>>>> requests (code-to-token, refresh token, logouts etc) can
>>>>>>> participate in same sticky session like the browser request. It may
>>>>>>> be possible in some cases (our adapters, some loadbalancers, see
>>>>>>> previous email I sent this
>>>>>>> week) but not everytime. And looks we would need to support the
>>>>>>> case when it's not possible.
>>>>>>>
>>>>>>> I can start with code-to-token request as it's slightly more
>>>>>>> complicated then the others due to the reasons:
>>>>>>>
>>>>>>> 1) code must be single-use per OAuth2 / OIDC specification
>>>>>>>
>>>>>>> 2) userSession may not yet be available. In case that we use ASYNC
>>>>>>> channel for communication between datacenters for transfer
>>>>>>> userSession (which I think should be the default due to performance
>>>>>>> reasons), then this example flow can happen:
>>>>>>> - user successfully authenticated and userSession was created on DC1.
>>>>>>> - code-to-token request is sent by the adapter to DC2. Note that
>>>>>>> this request is usually sent very quickly after userSession is
>>>>>>> created.
>>>>>>> - DC2 didn't yet received the message from DC1 about the new
>>>>>>> userSession. So this userSession not yet available here.
>>>>>>>
>>>>>>> Questions:
>>>>>>> 1) Could we remove a need from code-to-token endpoint to lookup
>>>>>>> userSession? I see this as an option as long as code itself is JWT
>>>>>>> signed with realm HMAC key encapsulating some info about user,
>>>>>>> session_state etc. Among other things, this would require some
>>>>>>> refactoring of protocolMappers (as userSession won't be available
>>>>>>> when tokens are generated). But isn't it bad for security to have
>>>>>>> some claims directly to the code? It is query parameter, which may
>>>>>>> end visible in browser history. IMO this is not big issue, but not
>>>>>>> 100% sure..
>>>>>>>
>>>>>>> Wouldn't the code also become rather big?
>>>>>> I reckon protocol mappers should be refactored regardless though.
>>>>>> The details should be in the code and token not in the user session.
>>>>>>
>>>>> For protocol mappers, the reason why the user session need to be
>>>>> available is that some component might be storing temporary
>>>>> information within the session that needs to be mapped to the token.
>>>>> Any example is a broker login that doesn't want or need to import into
>>>>> database, but instead stores in in the session.  Doesn't kerberos
>>>>> store stuff in the session that can be mapped to the token?  Finally,
>>>>> eventually we will want import-less brokering where the user is
>>>>> created within the session and destroyed with the session so we dont'
>>>>> have to hit
>>>>>
>>>> the DB and import.
>>>> True, so we basically will need to make sure the user session exists and
>>>> is
>>>> persisted. I reckon on-demand replication if technically possible the
>>>> best option.
>>>>
>>>>
>>>> 2) Another option is let the code-to-token endpoint wait until
>>>>>>> userSession is available. Then we would need support for
>>>>>>> asynchronous requests? I can see blocking undertow workers in
>>>>>>> waiting (something based on java.util.concurrent.Future) can be an
>>>>>>> issue and potential for DoS? Still even with asynchronous, the
>>>>>>> request times
>>>>>>>
>>>>>> can be quite long.
>>>>> I like this option. Could we combine this with on demand replication?
>>>>> With
>>>>>
>>>>>> a configurable timeout this would be nifty IMO.
>>>>>>
>>>>>
>>>>>
>>>>>> 3) Can we encourage people to use sticky sessions at least for
>>>>>>> code-to-token endpoint? We can add the route directly to the code
>>>>>>> itself, so the URL will look like:
>>>>>>> http://apphost/app?code=123.node1&state=456 . Many loadbalancers
>>>>>>> seem
>>>>>>>
>>>>>> to
>>>>>> support sticky session based on URL part. But there is also
>>>>>>> response_mode=form_post when the code won't be available in the URI.
>>>>>>>
>>>>>> May work for some, but I doubt it'll work for everyone.
>>>>>>
>>>>> imo, this is something that should be added to the spec.  That the
>>>>> code contains the callback URI.
>>>>>
>>>>>
>>>>>> 4) Is it ok to have option to relax on code one-time use? Otherwise
>>>>>>> in cross-DC and without sticky session, the every code exchange may
>>>>>>> require SYNC request to another DCs to doublecheck code was not used
>>>>>>>
>>>>>> already.
>>>>> Not good for performance..
>>>>>>> Maybe this is OK. Confidential apps needs credentials and then
>>>>>> there's Proof Key for Code Exchange for public clients. Although the
>>>>>>
>>>>> latter
>>>>>
>>>>>> may be another issue in cross-DC?
>>>>>>
>>>>>>
>>>>>> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
>>>>>>> Marek
>>>>>>>
>>>>>> I think 1 and 4 will hobble us for future things we want to do.
>>>>> Bill
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bruno at abstractj.org  Wed May 24 05:11:49 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 24 May 2017 09:11:49 +0000
Subject: [keycloak-dev] Quickstarts dev flow
Message-ID: <CAM5SUC7fY+g9rpYA=xTgS_QXWNPFpdP9dCZtNXa_H3QJ7E_P_w@mail.gmail.com>

Ahoy, now that Travis is happy with the master branch from the
quickstarts[1]. I would like to confirm the flow for development.

I was thinking about merge to 'latest' the changes from master only after
the Keycloak release and we keep submitting PRs to master.

Does it make any sense?

[1] - https://travis-ci.org/keycloak/keycloak-quickstarts/builds/235530549

From jdennis at redhat.com  Wed May 24 08:31:43 2017
From: jdennis at redhat.com (John Dennis)
Date: Wed, 24 May 2017 08:31:43 -0400
Subject: [keycloak-dev] Don't import * please!
In-Reply-To: <CAJgngAfvyq9u2OfkDW8-fT7ddwgFQnkJO=4mJk2O+pMNMasuwA@mail.gmail.com>
References: <77a3de77-f04a-6077-4058-700419218334@redhat.com>
	<CAJgngAfudZMeqqePDaYDutKtriJLbYTx04r867jbktNYQ1dWGA@mail.gmail.com>
	<CAPJq0L_tfLUQ94Fc496T52apL56w2wpvPnXbxRCTxPNrY1fdGQ@mail.gmail.com>
	<CAJgngAfvyq9u2OfkDW8-fT7ddwgFQnkJO=4mJk2O+pMNMasuwA@mail.gmail.com>
Message-ID: <3c6fe789-8810-aaac-633f-e8bacf65e6ec@redhat.com>

The way I've heard this explained and it applies to other languages 
besides Java as well is that wildcard imports are inherently dangerous 
because you don't have explicit knowledge of how a symbol is being 
resolved. You are also exposed to the risk of symbol collision. The more 
you can reduce the opportunity for unexpected consequences the more 
robust your code will be. Explicit is better than implicit.

I used to be frustrated by the prohibition against wildcard imports but 
I now view it as a good thing.

On 05/24/2017 12:23 AM, Stian Thorgersen wrote:
> What do you mean?
> 
> On 23 May 2017 at 16:19, Martin Hardselius <martin.hardselius at gmail.com>
> wrote:
> 
>> It clutters your local namespace.
>> On Mon, 22 May 2017 at 08:21, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Why is this a problem?
>>>
>>> On 19 May 2017 at 17:37, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> Please make your IDE import the full classname.  This is not allowed:
>>>>
>>>> import java.uti.*;
>>>>
>>>> All imports must be fully qualified.  A number of people are making this
>>>> mistake lately.
>>>>
>>>> Thanks,
>>>>
>>>> Bill
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


-- 
John

From bburke at redhat.com  Wed May 24 09:04:53 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 24 May 2017 09:04:53 -0400
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
	<CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
Message-ID: <386720a5-3505-8330-943f-5295167419e9@redhat.com>

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 at redhat.com 
> <mailto:mposolda at 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 at bosch-si.com
>>     <mailto:Sebastian.Schuster at 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 at bosch-si.com
>>         <mailto:Sebastian.Schuster at bosch-si.com>
>>
>>         Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg;
>>         HRB 148411 B
>>         Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>
>>
>>
>>
>>         > -----Original Message-----
>>         > From: keycloak-dev-bounces at lists.jboss.org
>>         <mailto:keycloak-dev-bounces at lists.jboss.org>
>>         [mailto:keycloak-dev- <mailto:keycloak-dev->
>>         >bounces at lists.jboss.org <mailto:bounces at lists.jboss.org>] On
>>         Behalf Of Marek Posolda
>>         > Sent: Dienstag, 23. Mai 2017 10:41
>>         > To: Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>>; keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at 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 at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From sthorger at redhat.com  Wed May 24 09:38:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 May 2017 15:38:57 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <386720a5-3505-8330-943f-5295167419e9@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
	<CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
	<386720a5-3505-8330-943f-5295167419e9@redhat.com>
Message-ID: <CAJgngAcXe2ddTLh896Y3YmpjboFA4djwztHuPMgLe1HKVG3SjA@mail.gmail.com>

On 24 May 2017 at 15:04, Bill Burke <bburke at 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 at 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 at 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 at bosch-si.com
>>>
>>> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
>>> Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>>>
>>>
>>>
>>>
>>> > -----Original Message-----
>>> > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>>> > bounces at lists.jboss.org] On Behalf Of Marek Posolda
>>> > Sent: Dienstag, 23. Mai 2017 10:41
>>> > To: Bill Burke <bburke at redhat.com>; keycloak-dev at 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 at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>

From bburke at redhat.com  Wed May 24 10:30:23 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 24 May 2017 10:30:23 -0400
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <CAJgngAcXe2ddTLh896Y3YmpjboFA4djwztHuPMgLe1HKVG3SjA@mail.gmail.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
	<CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
	<386720a5-3505-8330-943f-5295167419e9@redhat.com>
	<CAJgngAcXe2ddTLh896Y3YmpjboFA4djwztHuPMgLe1HKVG3SjA@mail.gmail.com>
Message-ID: <4a5d5f72-2bb9-f0c4-1e7a-d39a4a4cf4cb@redhat.com>



On 5/24/17 9:38 AM, Stian Thorgersen wrote:
>
>
> On 24 May 2017 at 15:04, Bill Burke <bburke at redhat.com 
> <mailto:bburke at 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

From DLustig at carbonite.com  Wed May 24 11:58:43 2017
From: DLustig at carbonite.com (David Lustig)
Date: Wed, 24 May 2017 15:58:43 +0000
Subject: [keycloak-dev]
 AbstractUserAdapterFederatedStorage.setSingleAttribute(, ) causing deadlocks
Message-ID: <SN2PR0601MB09737439DDD9D789D9C3B5D1AAFE0@SN2PR0601MB0973.namprd06.prod.outlook.com>

Greetings,

I have developed a federated user storage authenticator for Keycloak.  Upon each login we set/update at least one federated attribute on the user using AbstractUserAdapterFederatedStorage.setSingleAttribute(String name, String value).  During load testing, though, Keycloak starts running into deadlock issues that look to be caused by this method.  The error logged is:

2017-05-24 05:15:01,376 WARN  [org.keycloak.services] (default task-7) KC-SERVICES0013: Failed authentication: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1700)
        at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:70)
        at org.keycloak.storage.jpa.JpaUserFederatedStorageProvider.deleteAttribute(JpaUserFederatedStorageProvider.java:112)
        at org.keycloak.storage.jpa.JpaUserFederatedStorageProvider.setSingleAttribute(JpaUserFederatedStorageProvider.java:129)
       at org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage.setSingleAttribute(AbstractUserAdapterFederatedStorage.java:341)
        ...
Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement
        at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123)
        at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
        at org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(BasicExecutor.java:91)
        at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:60)
        at org.hibernate.hql.internal.ast.exec.DeleteExecutor.execute(DeleteExecutor.java:111)
        at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:429)
        at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:374)
        at org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1348)
        at org.hibernate.internal.QueryImpl.executeUpdate(QueryImpl.java:102)
        at org.hibernate.jpa.internal.QueryImpl.internalExecuteUpdate(QueryImpl.java:405)
        at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:61)
        ... 65 more
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 111) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
        at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:217)
        at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1655)
        at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:440)
        at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:385)
        at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7505)
        at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2445)
        at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:191)
        at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:166)
        at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeUpdate(SQLServerPreparedStatement.java:328)
        at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
        ... 74 more

Eventually, none of the deadlocks are released and the JVM crashes due to an out-of-memory error.  Is deadlocking expected behavior?  Are there any programming practices that should be followed that would prevent setSingleAttribute(,) from deadlocking the system in all situations, including high usage?

Thanks for your help,

David Lustig
This message is the property of CARBONITE, INC. and may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone.  Instead, destroy it and notify me by reply e-mail

From sblanc at redhat.com  Wed May 24 12:01:59 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 24 May 2017 18:01:59 +0200
Subject: [keycloak-dev] Quickstarts dev flow
In-Reply-To: <CAM5SUC7fY+g9rpYA=xTgS_QXWNPFpdP9dCZtNXa_H3QJ7E_P_w@mail.gmail.com>
References: <CAM5SUC7fY+g9rpYA=xTgS_QXWNPFpdP9dCZtNXa_H3QJ7E_P_w@mail.gmail.com>
Message-ID: <CAMZCGg9z=TRdwiHOtfz+q6xp=t2F7bmKYeLMoCHEnDT_96RRKg@mail.gmail.com>

Works for me !


On Wed, May 24, 2017 at 11:11 AM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> Ahoy, now that Travis is happy with the master branch from the
> quickstarts[1]. I would like to confirm the flow for development.
>
> I was thinking about merge to 'latest' the changes from master only after
> the Keycloak release and we keep submitting PRs to master.
>
> Does it make any sense?
>
> [1] - https://travis-ci.org/keycloak/keycloak-quickstarts/builds/235530549
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Wed May 24 16:59:46 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 May 2017 22:59:46 +0200
Subject: [keycloak-dev] Cross-DC and codeToToken request
In-Reply-To: <4a5d5f72-2bb9-f0c4-1e7a-d39a4a4cf4cb@redhat.com>
References: <d8b31cd5-47b6-9f76-d181-3902a6013c5e@redhat.com>
	<CAJgngAeoBX-t0pgK9CEsjGfOQ3wpmYKw0exZdYP32gLvaUX7gQ@mail.gmail.com>
	<09f78f18-460e-1829-c83f-aaaf7279ff31@redhat.com>
	<3eb7c6de-f7d7-8760-41ab-d91a984bce13@redhat.com>
	<0c1bab4e43a5445fbabea06656879913@FE-MBX1028.de.bosch.com>
	<CAJgngAdwD=2RRDPm5aME2FZxuHUYv7ES3RDM7QaQc9X8R-x6xQ@mail.gmail.com>
	<c24b1fe2-284c-ea3c-c3fd-bb663cc645ab@redhat.com>
	<CAJgngAdBSLsEv4Eg=Oo5c8ZrtZkDtVK3Jsds7XyXW6dBUduJmA@mail.gmail.com>
	<386720a5-3505-8330-943f-5295167419e9@redhat.com>
	<CAJgngAcXe2ddTLh896Y3YmpjboFA4djwztHuPMgLe1HKVG3SjA@mail.gmail.com>
	<4a5d5f72-2bb9-f0c4-1e7a-d39a4a4cf4cb@redhat.com>
Message-ID: <67b7a7d5-0cb0-432d-a0cb-9dcef7710326@redhat.com>

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 at redhat.com 
>> <mailto:bburke at 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



From hmlnarik at redhat.com  Thu May 25 02:34:07 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 25 May 2017 08:34:07 +0200
Subject: [keycloak-dev]
 AbstractUserAdapterFederatedStorage.setSingleAttribute(, ) causing deadlocks
In-Reply-To: <SN2PR0601MB09737439DDD9D789D9C3B5D1AAFE0@SN2PR0601MB0973.namprd06.prod.outlook.com>
References: <SN2PR0601MB09737439DDD9D789D9C3B5D1AAFE0@SN2PR0601MB0973.namprd06.prod.outlook.com>
Message-ID: <CAMvXD=F3f7-YhUzVYYQrvSFpQp2OC09-8gyP1kHSaLtj-MQMsw@mail.gmail.com>

Please file a JIRA. Keycloak w/ MSSQL has some known issues with
deadlocks and these need to be investigated. If you can share some
more details on reproducing the issues (configuration of the load
testing), that would be great. Please link it to
https://issues.jboss.org/browse/KEYCLOAK-4966.

On Wed, May 24, 2017 at 5:58 PM, David Lustig <DLustig at carbonite.com> wrote:
> Greetings,
>
> I have developed a federated user storage authenticator for Keycloak.  Upon each login we set/update at least one federated attribute on the user using AbstractUserAdapterFederatedStorage.setSingleAttribute(String name, String value).  During load testing, though, Keycloak starts running into deadlock issues that look to be caused by this method.  The error logged is:
>
> 2017-05-24 05:15:01,376 WARN  [org.keycloak.services] (default task-7) KC-SERVICES0013: Failed authentication: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement
>         at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
>         at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
>         at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1700)
>         at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:70)
>         at org.keycloak.storage.jpa.JpaUserFederatedStorageProvider.deleteAttribute(JpaUserFederatedStorageProvider.java:112)
>         at org.keycloak.storage.jpa.JpaUserFederatedStorageProvider.setSingleAttribute(JpaUserFederatedStorageProvider.java:129)
>        at org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage.setSingleAttribute(AbstractUserAdapterFederatedStorage.java:341)
>         ...
> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement
>         at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123)
>         at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
>         at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
>         at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
>         at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
>         at org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(BasicExecutor.java:91)
>         at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:60)
>         at org.hibernate.hql.internal.ast.exec.DeleteExecutor.execute(DeleteExecutor.java:111)
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:429)
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:374)
>         at org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1348)
>         at org.hibernate.internal.QueryImpl.executeUpdate(QueryImpl.java:102)
>         at org.hibernate.jpa.internal.QueryImpl.internalExecuteUpdate(QueryImpl.java:405)
>         at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:61)
>         ... 65 more
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 111) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
>         at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:217)
>         at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1655)
>         at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:440)
>         at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:385)
>         at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7505)
>         at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2445)
>         at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:191)
>         at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:166)
>         at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeUpdate(SQLServerPreparedStatement.java:328)
>         at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
>         at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>         ... 74 more
>
> Eventually, none of the deadlocks are released and the JVM crashes due to an out-of-memory error.  Is deadlocking expected behavior?  Are there any programming practices that should be followed that would prevent setSingleAttribute(,) from deadlocking the system in all situations, including high usage?
>
> Thanks for your help,
>
> David Lustig
> This message is the property of CARBONITE, INC. and may contain confidential or privileged information.
> If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone.  Instead, destroy it and notify me by reply e-mail
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

--Hynek


From mposolda at redhat.com  Thu May 25 12:24:43 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 May 2017 18:24:43 +0200
Subject: [keycloak-dev] Change the binding name in ScriptBasedAuthenticator?
Message-ID: <e58b58d1-2128-e5e7-a05a-f2d08e62412a@redhat.com>

Hi Thomas and all,

In 3.2 we did some refactoring and authenticators are now using 
authenticationSession instead of ClientSession. I see if we should do 
something for the ScriptBasedAuthenticator as it;s still using 
"clientSession" as binding where it puts authentication session. I can 
see the possibilities:

1) Keep the binding name "clientSession" for backwards compatibility
2) Change the binding name. Probably to "authenticationSession" ? It 
would need to be documented in the migration guide.

My vote is to rather go with 2 as people will likely need to refactor 
their scripts anyway. Some method signatures are same for authentication 
session like was for client session, but not all. WDYT? Other idea?

Marek


From thomas.darimont at googlemail.com  Thu May 25 12:35:08 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 25 May 2017 18:35:08 +0200
Subject: [keycloak-dev] Change the binding name in
	ScriptBasedAuthenticator?
In-Reply-To: <e58b58d1-2128-e5e7-a05a-f2d08e62412a@redhat.com>
References: <e58b58d1-2128-e5e7-a05a-f2d08e62412a@redhat.com>
Message-ID: <CAK-7U1h8pQeTjBZk0itRb2rhsXqjieS--yK+2d4jnYWHGCsyAg@mail.gmail.com>

Hi,

I haven't had time to look into this yet.
If the authenticationSession is a replacement for Client Session then
I think Option 2 ist fine, as the name alignes with the actual binding.

Cheers,
Thomas


Am 25.05.2017 6:24 nachm. schrieb "Marek Posolda" <mposolda at redhat.com>:

Hi Thomas and all,

In 3.2 we did some refactoring and authenticators are now using
authenticationSession instead of ClientSession. I see if we should do
something for the ScriptBasedAuthenticator as it;s still using
"clientSession" as binding where it puts authentication session. I can see
the possibilities:

1) Keep the binding name "clientSession" for backwards compatibility
2) Change the binding name. Probably to "authenticationSession" ? It would
need to be documented in the migration guide.

My vote is to rather go with 2 as people will likely need to refactor their
scripts anyway. Some method signatures are same for authentication session
like was for client session, but not all. WDYT? Other idea?

Marek

From mposolda at redhat.com  Thu May 25 12:49:33 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 May 2017 18:49:33 +0200
Subject: [keycloak-dev] Change the binding name in
	ScriptBasedAuthenticator?
In-Reply-To: <CAK-7U1h8pQeTjBZk0itRb2rhsXqjieS--yK+2d4jnYWHGCsyAg@mail.gmail.com>
References: <e58b58d1-2128-e5e7-a05a-f2d08e62412a@redhat.com>
	<CAK-7U1h8pQeTjBZk0itRb2rhsXqjieS--yK+2d4jnYWHGCsyAg@mail.gmail.com>
Message-ID: <56483cf9-5e6c-4413-dc28-198d6b6f762a@redhat.com>

Cool, thanks for the confirm. I've created JIRA 
https://issues.jboss.org/browse/KEYCLOAK-4975 . Do you want to 
contribute it or should I look into it?

Thanks,
Marek

On 25/05/17 18:35, Thomas Darimont wrote:
> Hi,
>
> I haven't had time to look into this yet.
> If the authenticationSession is a replacement for Client Session then
> I think Option 2 ist fine, as the name alignes with the actual binding.
>
> Cheers,
> Thomas
>
>
> Am 25.05.2017 6:24 nachm. schrieb "Marek Posolda" <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>>:
>
>     Hi Thomas and all,
>
>     In 3.2 we did some refactoring and authenticators are now using
>     authenticationSession instead of ClientSession. I see if we should
>     do something for the ScriptBasedAuthenticator as it;s still using
>     "clientSession" as binding where it puts authentication session. I
>     can see the possibilities:
>
>     1) Keep the binding name "clientSession" for backwards compatibility
>     2) Change the binding name. Probably to "authenticationSession" ?
>     It would need to be documented in the migration guide.
>
>     My vote is to rather go with 2 as people will likely need to
>     refactor their scripts anyway. Some method signatures are same for
>     authentication session like was for client session, but not all.
>     WDYT? Other idea?
>
>     Marek
>
>


From bburke at redhat.com  Thu May 25 14:15:20 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 25 May 2017 14:15:20 -0400
Subject: [keycloak-dev] Admin API Authz was Re: [keycloak-user] Keycloak
 Performance with large number of realms
In-Reply-To: <CAOqetn_NHb8F=AUWzYB6sReK-TvjGm7=d6nCQ5NtBkmd_EbNqA@mail.gmail.com>
References: <CAOqetn9xz+nzWUJG3aoU3xUsU2bhKDmgcTVNbukuvtWsrua4tw@mail.gmail.com>
	<CAJgngAcS0ugMrcczcFj77SVn75KvQOg5J5fzwGEB7AcySGiMRQ@mail.gmail.com>
	<CAOqetn9sncF_UnUH7kWTgGHXg1qLU67Hhy11AVDQgGc6GDMv0w@mail.gmail.com>
	<CAOqetn--yF94cMB6N1rZG_Q1ny1QkFodZewmLzGwzZdeufSMeA@mail.gmail.com>
	<CAJgngAdGQA4rTwGzQbMb0JMFOy2JK=4N97g2rSP97wgmAAOafg@mail.gmail.com>
	<CAOqetn-WamO3nrD0fgsfY-wC0zkqCJ0T5TJaJZ53iqVA3+2tTw@mail.gmail.com>
	<CAJgngAe6oPNUMERP=bdGqU_iywSmjaVoGAAisUEtjHE0SZfnoQ@mail.gmail.com>
	<CAOqetn_NHb8F=AUWzYB6sReK-TvjGm7=d6nCQ5NtBkmd_EbNqA@mail.gmail.com>
Message-ID: <881802f4-9863-176c-7f3b-760a39aed4d6@redhat.com>

[keycloak-dev]  See below thread.

I think that this problem might be solved by the work I'm doing. I'm 
changing the admin console to not include roles in the token. The Admin 
REST API instead will see that the token was generated for the console 
client (by "aud" claim) and look up role mappings directly.  I have to 
do this anyways because with the new fine grain admin permissions, I 
don't want admins to have to change the scope of the admin console 
client every time a new fine grain permission policy is specified.


On 5/24/17 11:07 PM, John D. Ament wrote:
> Ok,so I think I have a fix working, but one question I have is whether the
> existing PR for performance fixes will be getting merged in to 3.2?  While
> its a different problem it touches a lot of the same areas so it will
> create some conflicts if either gets merged first.  LIkewise if I have a
> fix for this, would you consider it part of 3.2?
>
> It also seems to me that there's an inherent problem with how some of the
> authorizations are done via Keycloak.  Specifically, it seems that a client
> authenticated to master is getting the roles from all realms, which is
> really what is causing these problems.  So while I can fix queries, without
> a fix in that area this type of problem can keep popping up.
>
> On Wed, May 24, 2017 at 9:42 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> That's used by composite roles. It is probably invoked on all roles in the
>> realm. Could probably be fetched eagerly rather than lazy. Can you create a
>> JIRA please?
>>
>> On 24 May 2017 at 12:11, John D. Ament <john.d.ament at gmail.com> wrote:
>>
>>> Stian,
>>>
>>> No, I don't believe its in that PR.  This seems to be the table
>>> "CHILD_ROLE" which has a large number of queries being executed against
>>> it.  But I'm not sure which entity that maps to in your persistence.xml
>>> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml
>>>
>>> John
>>>
>>> On Wed, May 24, 2017 at 3:54 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Sure, please create a JIRA and link it to
>>>> https://issues.jboss.org/browse/KEYCLOAK-4593
>>>>
>>>> Does this PR help: https://github.com/keycloak/keycloak/pull/3561?
>>>>
>>>> On 23 May 2017 at 15:04, John D. Ament <john.d.ament at gmail.com> wrote:
>>>>
>>>>> Stian,
>>>>>
>>>>> We just got a report of a new issue, not sure if its related to the
>>>>> existing but I can create a ticket on your side if it makes sense.
>>>>>
>>>>> When accessing /auth/realms/master/protocol/openid-connect/token we are
>>>>> seeing 3k SQLs being executed of this format:
>>>>>
>>>>> select compositer0_.COMPOSITE as COMPOSIT1_16_0_,
>>>>> compositer0_.CHILD_ROLE as CHILD_RO2_16_0_, roleentity1_.ID as ID1_38_1_,
>>>>> roleentity1_.CLIENT as CLIENT8_38_1_, roleentity1_.CLIENT_REALM_CONSTRAINT
>>>>> as CLIENT_R2_38_1_, roleentity1_.CLIENT_ROLE as CLIENT_R3_38_1_,
>>>>> roleentity1_.DESCRIPTION as DESCRIPT4_38_1_, roleentity1_.NAME as
>>>>> NAME5_38_1_, roleentity1_.REALM as REALM9_38_1_, roleentity1_.REALM_ID as
>>>>> REALM_ID6_38_1_, roleentity1_.SCOPE_PARAM_REQUIRED as SCOPE_PA7_38_1_ from
>>>>> COMPOSITE_ROLE compositer0_ inner join KEYCLOAK_ROLE roleentity1_ on
>>>>> compositer0_.CHILD_ROLE=roleentity1_.ID where compositer0_.COMPOSITE=?
>>>>>
>>>>> On Wed, May 10, 2017 at 12:40 PM John D. Ament <john.d.ament at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Stian,
>>>>>>
>>>>>> Good news.  Glad to see these things get prioritized.  So far they
>>>>>> look like they're matching the problems I'm running into, specifically
>>>>>> around the whoami endpoint and overall number of SQLs (2800 queries in one
>>>>>> of my tests) and the total number of DB connections allocated within that
>>>>>> one request (3200+).
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On Wed, May 10, 2017 at 8:02 AM Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> There are a number of issues around having a large number of realms.
>>>>>>> We have a general issue open to support this:
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-4593
>>>>>>>
>>>>>>> We haven't prioritized this in the past, but that has changed and we
>>>>>>> would like to get this sorted out.
>>>>>>>
>>>>>>> There's a few more related PRs including the one you linked:
>>>>>>> https://github.com/keycloak/keycloak/pull/3557
>>>>>>> https://github.com/keycloak/keycloak/pull/3561
>>>>>>>
>>>>>>> On 10 May 2017 at 12:35, John D. Ament <john.d.ament at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After enabling Keycloak and starting work on a multi-tenant
>>>>>>>> application, it
>>>>>>>> was noted that the admin console started to get very slow in
>>>>>>>> keycloak.
>>>>>>>> After some searching around, it seemed like this was an already
>>>>>>>> reported
>>>>>>>> issue [1] and a fix underway [2].  I was wondering if this fix would
>>>>>>>> make
>>>>>>>> it into 3.2?
>>>>>>>>
>>>>>>>> If additional testing is needed, I'd be happy to help out.  Deleting
>>>>>>>> 161
>>>>>>>> realms with minimal clients and users took me 15 minutes via the
>>>>>>>> REST API.
>>>>>>>>
>>>>>>>> [1]: https://issues.jboss.org/browse/KEYCLOAK-4858
>>>>>>>> [2]: https://github.com/keycloak/keycloak/pull/4095
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From DLustig at carbonite.com  Thu May 25 14:48:23 2017
From: DLustig at carbonite.com (David Lustig)
Date: Thu, 25 May 2017 18:48:23 +0000
Subject: [keycloak-dev]
 AbstractUserAdapterFederatedStorage.setSingleAttribute(, ) causing deadlocks
In-Reply-To: <CAMvXD=F3f7-YhUzVYYQrvSFpQp2OC09-8gyP1kHSaLtj-MQMsw@mail.gmail.com>
References: <SN2PR0601MB09737439DDD9D789D9C3B5D1AAFE0@SN2PR0601MB0973.namprd06.prod.outlook.com>
	<CAMvXD=F3f7-YhUzVYYQrvSFpQp2OC09-8gyP1kHSaLtj-MQMsw@mail.gmail.com>
Message-ID: <DM2PR0601MB0971F759F9488FBAC6B27CB2AAFF0@DM2PR0601MB0971.namprd06.prod.outlook.com>

I have written https://issues.jboss.org/browse/KEYCLOAK-4976 to document this issue.  If you need any additional information, let me know.

David

From: Hynek Mlnarik [mailto:hmlnarik at redhat.com]
Sent: Thursday, May 25, 2017 2:34 AM
To: David Lustig <DLustig at carbonite.com>
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] AbstractUserAdapterFederatedStorage.setSingleAttribute(, ) causing deadlocks

Please file a JIRA. Keycloak w/ MSSQL has some known issues with
deadlocks and these need to be investigated. If you can share some
more details on reproducing the issues (configuration of the load
testing), that would be great. Please link it to
https://issues.jboss.org/browse/KEYCLOAK-4966<https://issues.jboss.org/browse/KEYCLOAK-4966>.

On Wed, May 24, 2017 at 5:58 PM, David Lustig <DLustig at carbonite.com<mailto:DLustig at carbonite.com>> wrote:
> Greetings,
>
> I have developed a federated user storage authenticator for Keycloak. Upon each login we set/update at least one federated attribute on the user using AbstractUserAdapterFederatedStorage.setSingleAttribute(String name, String value). During load testing, though, Keycloak starts running into deadlock issues that look to be caused by this method. The error logged is:
>
> 2017-05-24 05:15:01,376 WARN [org.keycloak.services<http://org.keycloak.services>] (default task-7) KC-SERVICES0013: Failed authentication: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1700)
> at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:70)
> at org.keycloak.storage.jpa.JpaUserFederatedStorageProvider.deleteAttribute(JpaUserFederatedStorageProvider.java:112)
> at org.keycloak.storage.jpa.JpaUserFederatedStorageProvider.setSingleAttribute(JpaUserFederatedStorageProvider.java:129)
> at org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage.setSingleAttribute(AbstractUserAdapterFederatedStorage.java:341)
> ...
> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement
> at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123)
> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
> at org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(BasicExecutor.java:91)
> at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:60)
> at org.hibernate.hql.internal.ast.exec.DeleteExecutor.execute(DeleteExecutor.java:111)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:429)
> at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:374)
> at org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1348)
> at org.hibernate.internal.QueryImpl.executeUpdate(QueryImpl.java:102)
> at org.hibernate.jpa.internal.QueryImpl.internalExecuteUpdate(QueryImpl.java:405)
> at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:61)
> ... 65 more
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Transaction (Process ID 111) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:217)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1655)
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(SQLServerPreparedStatement.java:440)
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(SQLServerPreparedStatement.java:385)
> at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7505)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2445)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:191)
> at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:166)
> at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeUpdate(SQLServerPreparedStatement.java:328)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
> ... 74 more
>
> Eventually, none of the deadlocks are released and the JVM crashes due to an out-of-memory error. Is deadlocking expected behavior? Are there any programming practices that should be followed that would prevent setSingleAttribute(,) from deadlocking the system in all situations, including high usage?
>
> Thanks for your help,
>
> David Lustig
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev<https://lists.jboss.org/mailman/listinfo/keycloak-dev>



--

--Hynek
This message is the property of CARBONITE, INC. and may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone.  Instead, destroy it and notify me by reply e-mail

From bburke at redhat.com  Fri May 26 08:42:25 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 26 May 2017 08:42:25 -0400
Subject: [keycloak-dev] [keycloak-user] Admin API Authz was Re: Keycloak
 Performance with large number of realms
In-Reply-To: <CAOqetn-4Anu4Xh8LcLUQ8o7SJUudJmkotZd9ZzqUdQpcHwhf4g@mail.gmail.com>
References: <CAOqetn9xz+nzWUJG3aoU3xUsU2bhKDmgcTVNbukuvtWsrua4tw@mail.gmail.com>
	<CAJgngAcS0ugMrcczcFj77SVn75KvQOg5J5fzwGEB7AcySGiMRQ@mail.gmail.com>
	<CAOqetn9sncF_UnUH7kWTgGHXg1qLU67Hhy11AVDQgGc6GDMv0w@mail.gmail.com>
	<CAOqetn--yF94cMB6N1rZG_Q1ny1QkFodZewmLzGwzZdeufSMeA@mail.gmail.com>
	<CAJgngAdGQA4rTwGzQbMb0JMFOy2JK=4N97g2rSP97wgmAAOafg@mail.gmail.com>
	<CAOqetn-WamO3nrD0fgsfY-wC0zkqCJ0T5TJaJZ53iqVA3+2tTw@mail.gmail.com>
	<CAJgngAe6oPNUMERP=bdGqU_iywSmjaVoGAAisUEtjHE0SZfnoQ@mail.gmail.com>
	<CAOqetn_NHb8F=AUWzYB6sReK-TvjGm7=d6nCQ5NtBkmd_EbNqA@mail.gmail.com>
	<881802f4-9863-176c-7f3b-760a39aed4d6@redhat.com>
	<CAOqetn-4Anu4Xh8LcLUQ8o7SJUudJmkotZd9ZzqUdQpcHwhf4g@mail.gmail.com>
Message-ID: <e217b65e-ccd4-f1ad-d02c-8c187430f957@redhat.com>

I don't think I'm going to get it in for 3.2.  But its coming.


On 5/26/17 6:11 AM, John D. Ament wrote:
> Bill,
>
> Is this something for 3.2?
>
> If I had to guess, based on what I"m seeing, yes, this would fix the 
> underlying issues.  I'm assuming that the association to the realms 
> involves loading all of the realms from the database, and specifically 
> granting for all of the existing permissions?
>
> John
>
> On Thu, May 25, 2017 at 11:11 PM Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     [keycloak-dev] See below thread.
>
>     I think that this problem might be solved by the work I'm doing. I'm
>     changing the admin console to not include roles in the token. The
>     Admin
>     REST API instead will see that the token was generated for the console
>     client (by "aud" claim) and look up role mappings directly.  I have to
>     do this anyways because with the new fine grain admin permissions, I
>     don't want admins to have to change the scope of the admin console
>     client every time a new fine grain permission policy is specified.
>
>
>     On 5/24/17 11:07 PM, John D. Ament wrote:
>     > Ok,so I think I have a fix working, but one question I have is
>     whether the
>     > existing PR for performance fixes will be getting merged in to
>     3.2?  While
>     > its a different problem it touches a lot of the same areas so it
>     will
>     > create some conflicts if either gets merged first. LIkewise if I
>     have a
>     > fix for this, would you consider it part of 3.2?
>     >
>     > It also seems to me that there's an inherent problem with how
>     some of the
>     > authorizations are done via Keycloak.  Specifically, it seems
>     that a client
>     > authenticated to master is getting the roles from all realms,
>     which is
>     > really what is causing these problems.  So while I can fix
>     queries, without
>     > a fix in that area this type of problem can keep popping up.
>     >
>     > On Wed, May 24, 2017 at 9:42 AM Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     > wrote:
>     >
>     >> That's used by composite roles. It is probably invoked on all
>     roles in the
>     >> realm. Could probably be fetched eagerly rather than lazy. Can
>     you create a
>     >> JIRA please?
>     >>
>     >> On 24 May 2017 at 12:11, John D. Ament <john.d.ament at gmail.com
>     <mailto:john.d.ament at gmail.com>> wrote:
>     >>
>     >>> Stian,
>     >>>
>     >>> No, I don't believe its in that PR.  This seems to be the table
>     >>> "CHILD_ROLE" which has a large number of queries being
>     executed against
>     >>> it.  But I'm not sure which entity that maps to in your
>     persistence.xml
>     >>>
>     https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml
>     >>>
>     >>> John
>     >>>
>     >>> On Wed, May 24, 2017 at 3:54 AM Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>> wrote:
>     >>>
>     >>>> Sure, please create a JIRA and link it to
>     >>>> https://issues.jboss.org/browse/KEYCLOAK-4593
>     >>>>
>     >>>> Does this PR help:
>     https://github.com/keycloak/keycloak/pull/3561?
>     >>>>
>     >>>> On 23 May 2017 at 15:04, John D. Ament
>     <john.d.ament at gmail.com <mailto:john.d.ament at gmail.com>> wrote:
>     >>>>
>     >>>>> Stian,
>     >>>>>
>     >>>>> We just got a report of a new issue, not sure if its related
>     to the
>     >>>>> existing but I can create a ticket on your side if it makes
>     sense.
>     >>>>>
>     >>>>> When accessing
>     /auth/realms/master/protocol/openid-connect/token we are
>     >>>>> seeing 3k SQLs being executed of this format:
>     >>>>>
>     >>>>> select compositer0_.COMPOSITE as COMPOSIT1_16_0_,
>     >>>>> compositer0_.CHILD_ROLE as CHILD_RO2_16_0_, roleentity1_.ID
>     as ID1_38_1_,
>     >>>>> roleentity1_.CLIENT as CLIENT8_38_1_,
>     roleentity1_.CLIENT_REALM_CONSTRAINT
>     >>>>> as CLIENT_R2_38_1_, roleentity1_.CLIENT_ROLE as CLIENT_R3_38_1_,
>     >>>>> roleentity1_.DESCRIPTION as DESCRIPT4_38_1_,
>     roleentity1_.NAME as
>     >>>>> NAME5_38_1_, roleentity1_.REALM as REALM9_38_1_,
>     roleentity1_.REALM_ID as
>     >>>>> REALM_ID6_38_1_, roleentity1_.SCOPE_PARAM_REQUIRED as
>     SCOPE_PA7_38_1_ from
>     >>>>> COMPOSITE_ROLE compositer0_ inner join KEYCLOAK_ROLE
>     roleentity1_ on
>     >>>>> compositer0_.CHILD_ROLE=roleentity1_.ID where
>     compositer0_.COMPOSITE=?
>     >>>>>
>     >>>>> On Wed, May 10, 2017 at 12:40 PM John D. Ament
>     <john.d.ament at gmail.com <mailto:john.d.ament at gmail.com>>
>     >>>>> wrote:
>     >>>>>
>     >>>>>> Stian,
>     >>>>>>
>     >>>>>> Good news.  Glad to see these things get prioritized.  So
>     far they
>     >>>>>> look like they're matching the problems I'm running into,
>     specifically
>     >>>>>> around the whoami endpoint and overall number of SQLs (2800
>     queries in one
>     >>>>>> of my tests) and the total number of DB connections
>     allocated within that
>     >>>>>> one request (3200+).
>     >>>>>>
>     >>>>>> John
>     >>>>>>
>     >>>>>>
>     >>>>>> On Wed, May 10, 2017 at 8:02 AM Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>     >>>>>> wrote:
>     >>>>>>
>     >>>>>>> There are a number of issues around having a large number
>     of realms.
>     >>>>>>> We have a general issue open to support this:
>     >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-4593
>     >>>>>>>
>     >>>>>>> We haven't prioritized this in the past, but that has
>     changed and we
>     >>>>>>> would like to get this sorted out.
>     >>>>>>>
>     >>>>>>> There's a few more related PRs including the one you linked:
>     >>>>>>> https://github.com/keycloak/keycloak/pull/3557
>     >>>>>>> https://github.com/keycloak/keycloak/pull/3561
>     >>>>>>>
>     >>>>>>> On 10 May 2017 at 12:35, John D. Ament
>     <john.d.ament at gmail.com <mailto:john.d.ament at gmail.com>>
>     >>>>>>> wrote:
>     >>>>>>>
>     >>>>>>>> Hi,
>     >>>>>>>>
>     >>>>>>>> After enabling Keycloak and starting work on a multi-tenant
>     >>>>>>>> application, it
>     >>>>>>>> was noted that the admin console started to get very slow in
>     >>>>>>>> keycloak.
>     >>>>>>>> After some searching around, it seemed like this was an
>     already
>     >>>>>>>> reported
>     >>>>>>>> issue [1] and a fix underway [2].  I was wondering if
>     this fix would
>     >>>>>>>> make
>     >>>>>>>> it into 3.2?
>     >>>>>>>>
>     >>>>>>>> If additional testing is needed, I'd be happy to help
>     out.  Deleting
>     >>>>>>>> 161
>     >>>>>>>> realms with minimal clients and users took me 15 minutes
>     via the
>     >>>>>>>> REST API.
>     >>>>>>>>
>     >>>>>>>> [1]: https://issues.jboss.org/browse/KEYCLOAK-4858
>     >>>>>>>> [2]: https://github.com/keycloak/keycloak/pull/4095
>     >>>>>>>>
>     >>>>>>> _______________________________________________
>     >>>>>>>> keycloak-user mailing list
>     >>>>>>>> keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>     >>>>>>>>
>     >>>>>>>
>     > _______________________________________________
>     > keycloak-user mailing list
>     > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>


From sthorger at redhat.com  Mon May 29 03:29:06 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 May 2017 09:29:06 +0200
Subject: [keycloak-dev] Quickstarts dev flow
In-Reply-To: <CAM5SUC7fY+g9rpYA=xTgS_QXWNPFpdP9dCZtNXa_H3QJ7E_P_w@mail.gmail.com>
References: <CAM5SUC7fY+g9rpYA=xTgS_QXWNPFpdP9dCZtNXa_H3QJ7E_P_w@mail.gmail.com>
Message-ID: <CAJgngAfstN4b=z_Lt7Rus7etK_dUN+MGXywKGCdqL67hADe=WQ@mail.gmail.com>

Why not just do it at the same time as a release? The Keycloak release
server could:

* Release Keycloak
* Bump version in quickstarts master
* Pull in changes from master to latest
* Bump version in quickstart master to next SNAPSHOT

That does require CI job that runs master branch to make sure it works with
latest SNAPSHOT though.

On 24 May 2017 at 11:11, Bruno Oliveira <bruno at abstractj.org> wrote:

> Ahoy, now that Travis is happy with the master branch from the
> quickstarts[1]. I would like to confirm the flow for development.
>
> I was thinking about merge to 'latest' the changes from master only after
> the Keycloak release and we keep submitting PRs to master.
>
> Does it make any sense?
>
> [1] - https://travis-ci.org/keycloak/keycloak-quickstarts/builds/235530549
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon May 29 05:58:58 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 May 2017 11:58:58 +0200
Subject: [keycloak-dev] Reducing queries when initially loading a realm
Message-ID: <CAJgngAdrHD=YhnLs-VH4xKPDc+K7eFLYve_sc7B_3cJBZpYEnQ@mail.gmail.com>

When we initially load a realm there are a lot of queries going to the db.
A lot of things are fetched lazily which results a large number of queries.
For example to load roles see https://issues.jboss.org/browse/KEYCLOAK-4964.

How feasible would it be to have a single query that fetches most things
(if not everything) when a realm is initially loaded? We could at least
fetch all realm data including roles and composites, but excluding clients
and users.

From sthorger at redhat.com  Mon May 29 07:42:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 May 2017 13:42:29 +0200
Subject: [keycloak-dev] Reducing queries when initially loading a realm
In-Reply-To: <CAJgngAdrHD=YhnLs-VH4xKPDc+K7eFLYve_sc7B_3cJBZpYEnQ@mail.gmail.com>
References: <CAJgngAdrHD=YhnLs-VH4xKPDc+K7eFLYve_sc7B_3cJBZpYEnQ@mail.gmail.com>
Message-ID: <CAJgngAeSFDhM=Yt58c=uDiv1ktTPt63NZpJqRNXuiihH_sCmXA@mail.gmail.com>

Another related thing. I believe we currently look for composite roles
cross realms, which is not ideal. This comes down to admin master realm I
believe.

On 29 May 2017 at 11:58, Stian Thorgersen <sthorger at redhat.com> wrote:

> When we initially load a realm there are a lot of queries going to the db.
> A lot of things are fetched lazily which results a large number of queries.
> For example to load roles see https://issues.jboss.org/
> browse/KEYCLOAK-4964.
>
> How feasible would it be to have a single query that fetches most things
> (if not everything) when a realm is initially loaded? We could at least
> fetch all realm data including roles and composites, but excluding clients
> and users.
>

From bruno at abstractj.org  Mon May 29 10:47:36 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 29 May 2017 14:47:36 +0000
Subject: [keycloak-dev] Quickstarts dev flow
In-Reply-To: <CAJgngAfstN4b=z_Lt7Rus7etK_dUN+MGXywKGCdqL67hADe=WQ@mail.gmail.com>
References: <CAM5SUC7fY+g9rpYA=xTgS_QXWNPFpdP9dCZtNXa_H3QJ7E_P_w@mail.gmail.com>
	<CAJgngAfstN4b=z_Lt7Rus7etK_dUN+MGXywKGCdqL67hADe=WQ@mail.gmail.com>
Message-ID: <CAM5SUC6TeKn7pG-kE1WR1omxgaDfLwW8e7oy5VVmBhhEFekYUw@mail.gmail.com>

My question was related with the daily basis dev flow and yes, we need to
automate this. To not miss what you mentioned I created this jira:
https://issues.jboss.org/browse/KEYCLOAK-4982

On Mon, May 29, 2017 at 4:29 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Why not just do it at the same time as a release? The Keycloak release
> server could:
>
> * Release Keycloak
> * Bump version in quickstarts master
> * Pull in changes from master to latest
> * Bump version in quickstart master to next SNAPSHOT
>
> That does require CI job that runs master branch to make sure it works
> with latest SNAPSHOT though.
>
> On 24 May 2017 at 11:11, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> Ahoy, now that Travis is happy with the master branch from the
>> quickstarts[1]. I would like to confirm the flow for development.
>>
>> I was thinking about merge to 'latest' the changes from master only after
>> the Keycloak release and we keep submitting PRs to master.
>>
>> Does it make any sense?
>>
>> [1] -
>> https://travis-ci.org/keycloak/keycloak-quickstarts/builds/235530549
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From bburke at redhat.com  Mon May 29 16:33:13 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 May 2017 16:33:13 -0400
Subject: [keycloak-dev] Reducing queries when initially loading a realm
In-Reply-To: <CAJgngAdrHD=YhnLs-VH4xKPDc+K7eFLYve_sc7B_3cJBZpYEnQ@mail.gmail.com>
References: <CAJgngAdrHD=YhnLs-VH4xKPDc+K7eFLYve_sc7B_3cJBZpYEnQ@mail.gmail.com>
Message-ID: <e663ec97-4ec9-e071-c7c1-3ec574e07a6f@redhat.com>

Don't think that's a good idea.  We have users  that have thousands of 
roles and groups.


On 5/29/17 5:58 AM, Stian Thorgersen wrote:
> When we initially load a realm there are a lot of queries going to the db.
> A lot of things are fetched lazily which results a large number of queries.
> For example to load roles see https://issues.jboss.org/browse/KEYCLOAK-4964.
>
> How feasible would it be to have a single query that fetches most things
> (if not everything) when a realm is initially loaded? We could at least
> fetch all realm data including roles and composites, but excluding clients
> and users.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Tue May 30 02:58:15 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 30 May 2017 08:58:15 +0200
Subject: [keycloak-dev] Reducing queries when initially loading a realm
In-Reply-To: <e663ec97-4ec9-e071-c7c1-3ec574e07a6f@redhat.com>
References: <CAJgngAdrHD=YhnLs-VH4xKPDc+K7eFLYve_sc7B_3cJBZpYEnQ@mail.gmail.com>
	<e663ec97-4ec9-e071-c7c1-3ec574e07a6f@redhat.com>
Message-ID: <CAJgngAe2Hwtjsw1dtJYCaVqfK+pTEM1vzD=pvfnDyezrS-r6LA@mail.gmail.com>

If you look at the attached issue (
https://issues.jboss.org/browse/KEYCLOAK-4964) it looks like we currently
end up with doing thousands of queries instead. So how do you propose we
solve this?

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

> Don't think that's a good idea.  We have users  that have thousands of
> roles and groups.
>
>
> On 5/29/17 5:58 AM, Stian Thorgersen wrote:
> > When we initially load a realm there are a lot of queries going to the
> db.
> > A lot of things are fetched lazily which results a large number of
> queries.
> > For example to load roles see https://issues.jboss.org/
> browse/KEYCLOAK-4964.
> >
> > How feasible would it be to have a single query that fetches most things
> > (if not everything) when a realm is initially loaded? We could at least
> > fetch all realm data including roles and composites, but excluding
> clients
> > and users.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From aszczucz at redhat.com  Tue May 30 11:37:15 2017
From: aszczucz at redhat.com (Alex Szczuczko)
Date: Tue, 30 May 2017 11:37:15 -0400 (EDT)
Subject: [keycloak-dev] The browser property and the
 org.keycloak.testsuite.console.* UI tests
In-Reply-To: <1122490420.13181047.1496158085615.JavaMail.zimbra@redhat.com>
Message-ID: <632204267.13183372.1496158635111.JavaMail.zimbra@redhat.com>

Hi,

I just lost a couple days to a really simple mistake when running the UI tests. I didn't set -Dbrowser=firefox, so the headless WebDriver was used, which produces a lot of impossible errors that I couldn't figure out at all. To save the next person the same agony, I think there are two possible solutions:

1. Define a default browser=firefox property in testsuite/integration-arquillian/tests/other/console/pom.xml

2. Use a plugin to fail the build if the user has not defined the browser property on the command line.

Note that you need to enable a profile to run these tests (-Pconsole-ui-tests), so this doesn't impact the project's normal mvn clean install.

Opinions on either of these options?

Thanks,
Alex

From Marcel.Hartwig at cstx.de  Tue May 30 19:23:04 2017
From: Marcel.Hartwig at cstx.de (Marcel Hartwig)
Date: Tue, 30 May 2017 23:23:04 +0000
Subject: [keycloak-dev] Client role not supplied
Message-ID: <E0FDA5C6-85AE-4917-985B-707EC520DB62@cstx.de>

Hi,

I added a client (access type ?confidential?) to a realm and added one role to the client. If I authorize against that realm with the correct client id, then the role is not supplied in the created access token. There are only role for the client ?account? supplied.

I am using key cloak from the latest docker image. Can anybody help me?

kind regards

Marcel Hartwig


From sthorger at redhat.com  Wed May 31 02:31:33 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 31 May 2017 08:31:33 +0200
Subject: [keycloak-dev] The browser property and the
 org.keycloak.testsuite.console.* UI tests
In-Reply-To: <632204267.13183372.1496158635111.JavaMail.zimbra@redhat.com>
References: <1122490420.13181047.1496158085615.JavaMail.zimbra@redhat.com>
	<632204267.13183372.1496158635111.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAfQV+n0QBJzUYXvtxyMD_F9AfEXtLR-Y5LOw9JgQ1obcA@mail.gmail.com>

Ideally the console tests should work with HtmlUnit, but failing that they
certainly need to work with PhantomJS.

Pavel - any chance we can get the console tests working with HtmlUnit? If
not I guess we need to set the default for the console tests to PhantomJS.

On 30 May 2017 at 17:37, Alex Szczuczko <aszczucz at redhat.com> wrote:

> Hi,
>
> I just lost a couple days to a really simple mistake when running the UI
> tests. I didn't set -Dbrowser=firefox, so the headless WebDriver was used,
> which produces a lot of impossible errors that I couldn't figure out at
> all. To save the next person the same agony, I think there are two possible
> solutions:
>
> 1. Define a default browser=firefox property in testsuite/integration-
> arquillian/tests/other/console/pom.xml
>
> 2. Use a plugin to fail the build if the user has not defined the browser
> property on the command line.
>
> Note that you need to enable a profile to run these tests
> (-Pconsole-ui-tests), so this doesn't impact the project's normal mvn clean
> install.
>
> Opinions on either of these options?
>
> Thanks,
> Alex
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Wed May 31 06:35:37 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 31 May 2017 10:35:37 +0000
Subject: [keycloak-dev] Fuse quickstarts
Message-ID: <CAM5SUC5etRQmU01f6woLpMdr1G1_2vtZ5o_u5SiE7f-1q-aB-Q@mail.gmail.com>

For Fuse quickstarts, we have a some configuration steps to setup the
server like:

1. Set the Keycloak version

KEYCLOAK_VERSION=3.2.0.CR1-SNAPSHOT

2. Add Maven local repository

config:edit org.ops4j.pax.url.mvn
config:propset org.ops4j.pax.url.mvn.localRepository
file:///$HOME/.m2/repository
config:update

3. Install quickstarts artifacts

4. Install features

features:addurl
mvn:org.keycloak/keycloak-osgi-features/$KEYCLOAK_VERSION/xml/features
features:addurl
mvn:org.keycloak.quickstarts/keycloak-fuse-features/$KEYCLOAK_VERSION/xml/features
features:install keycloak-fuse-quickstarts

I was wondering if we could have a profile to make this process more
simple. Something like mvn clean install -Pfuse-server and you're good to
go. Do we want this? Or follow all these steps would be the goal as part of
the learning process?

From sblanc at redhat.com  Wed May 31 10:48:20 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 31 May 2017 14:48:20 +0000
Subject: [keycloak-dev] Fuse quickstarts
In-Reply-To: <CAM5SUC5etRQmU01f6woLpMdr1G1_2vtZ5o_u5SiE7f-1q-aB-Q@mail.gmail.com>
References: <CAM5SUC5etRQmU01f6woLpMdr1G1_2vtZ5o_u5SiE7f-1q-aB-Q@mail.gmail.com>
Message-ID: <CAMZCGg_QMbx9f7wmK7WHfyb+wy_t+oLi_02eemAL3m7Pw6RXMA@mail.gmail.com>

Since it's a *Quick*Start ;) I would say go with the profile. In the same
time in the readme we can add a note that explains the detailed process
Le mer. 31 mai 2017 ? 16:46, Bruno Oliveira <bruno at abstractj.org> a ?crit :

> For Fuse quickstarts, we have a some configuration steps to setup the
> server like:
>
> 1. Set the Keycloak version
>
> KEYCLOAK_VERSION=3.2.0.CR1-SNAPSHOT
>
> 2. Add Maven local repository
>
> config:edit org.ops4j.pax.url.mvn
> config:propset org.ops4j.pax.url.mvn.localRepository
> file:///$HOME/.m2/repository
> config:update
>
> 3. Install quickstarts artifacts
>
> 4. Install features
>
> features:addurl
> mvn:org.keycloak/keycloak-osgi-features/$KEYCLOAK_VERSION/xml/features
> features:addurl
>
> mvn:org.keycloak.quickstarts/keycloak-fuse-features/$KEYCLOAK_VERSION/xml/features
> features:install keycloak-fuse-quickstarts
>
> I was wondering if we could have a profile to make this process more
> simple. Something like mvn clean install -Pfuse-server and you're good to
> go. Do we want this? Or follow all these steps would be the goal as part of
> the learning process?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Wed May 31 11:42:53 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 31 May 2017 11:42:53 -0400
Subject: [keycloak-dev] Fuse quickstarts
In-Reply-To: <CAM5SUC5etRQmU01f6woLpMdr1G1_2vtZ5o_u5SiE7f-1q-aB-Q@mail.gmail.com>
References: <CAM5SUC5etRQmU01f6woLpMdr1G1_2vtZ5o_u5SiE7f-1q-aB-Q@mail.gmail.com>
Message-ID: <581b30fb-3bec-a6bb-d10e-fe7efb86c005@redhat.com>

I believe that the goal of the quickstart should be to let the developer 
get something working as fast as possible.  (Hence the name "quickstart")

After that, he can look it over, see how it works, and experiment with 
changes.

Anything that delays the joy of a working example increases the 
likelihood that the developer will abandon the effort.

On 5/31/2017 6:35 AM, Bruno Oliveira wrote:
> For Fuse quickstarts, we have a some configuration steps to setup the
> server like:
>
> 1. Set the Keycloak version
>
> KEYCLOAK_VERSION=3.2.0.CR1-SNAPSHOT
>
> 2. Add Maven local repository
>
> config:edit org.ops4j.pax.url.mvn
> config:propset org.ops4j.pax.url.mvn.localRepository
> file:///$HOME/.m2/repository
> config:update
>
> 3. Install quickstarts artifacts
>
> 4. Install features
>
> features:addurl
> mvn:org.keycloak/keycloak-osgi-features/$KEYCLOAK_VERSION/xml/features
> features:addurl
> mvn:org.keycloak.quickstarts/keycloak-fuse-features/$KEYCLOAK_VERSION/xml/features
> features:install keycloak-fuse-quickstarts
>
> I was wondering if we could have a profile to make this process more
> simple. Something like mvn clean install -Pfuse-server and you're good to
> go. Do we want this? Or follow all these steps would be the goal as part of
> the learning process?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From vmuzikar at redhat.com  Wed May 31 12:43:09 2017
From: vmuzikar at redhat.com (Vaclav Muzikar)
Date: Wed, 31 May 2017 18:43:09 +0200
Subject: [keycloak-dev] The browser property and the
 org.keycloak.testsuite.console.* UI tests
In-Reply-To: <592E65B2.8060909@redhat.com>
References: <1122490420.13181047.1496158085615.JavaMail.zimbra@redhat.com>
	<632204267.13183372.1496158635111.JavaMail.zimbra@redhat.com>
	<CAJgngAfQV+n0QBJzUYXvtxyMD_F9AfEXtLR-Y5LOw9JgQ1obcA@mail.gmail.com>
	<592E65B2.8060909@redhat.com>
Message-ID: <CAMQSZyhsaKq-Nb+chQVVuh8xpdBs3zE5bZzC1TkZC3vEcWnR5Q@mail.gmail.com>

The UI tests are not supposed to work with "artificial" browsers - only the
real-life ones are supported.
UI tests are high-demanding on JS interpreter (PhantomJS nor HtmlUnit can
satisfy such demands) and moreover UI needs to be anyway tested with all
supported browsers (due to some differences between them). So it wouldn't
make much sense to run them with e.g. HtmlUnit.
Please see our HOW-TO-RUN [1] where are the instructions on some special
tests (like UI or adapters).

However, good point that we should add some check for supported browsers
before running the tests. I'll look into it.

[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#ui-tests

V.

On Wed, May 31, 2017 at 8:41 AM, Pavel Drozd <pdrozd at redhat.com> wrote:

> Dne 31.5.2017 v 08:31 Stian Thorgersen napsal(a):
>
> Ideally the console tests should work with HtmlUnit, but failing that they
> certainly need to work with PhantomJS.
>
> Pavel - any chance we can get the console tests working with HtmlUnit? If
> not I guess we need to set the default for the console tests to PhantomJS.
>
>
> We were focusing to run the tests mainly with real browsers. Vasek did you
> try to run the UI tests with HtmlUnit?
>
>
> On 30 May 2017 at 17:37, Alex Szczuczko <aszczucz at redhat.com> wrote:
>
>> Hi,
>>
>> I just lost a couple days to a really simple mistake when running the UI
>> tests. I didn't set -Dbrowser=firefox, so the headless WebDriver was used,
>> which produces a lot of impossible errors that I couldn't figure out at
>> all. To save the next person the same agony, I think there are two possible
>> solutions:
>>
>> 1. Define a default browser=firefox property in
>> testsuite/integration-arquillian/tests/other/console/pom.xml
>>
>> 2. Use a plugin to fail the build if the user has not defined the browser
>> property on the command line.
>>
>> Note that you need to enable a profile to run these tests
>> (-Pconsole-ui-tests), so this doesn't impact the project's normal mvn clean
>> install.
>>
>> Opinions on either of these options?
>>
>> Thanks,
>> Alex
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>


-- 
V?clav Muzik??
Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

From shanonvl at yahoo.com  Wed May 31 14:14:58 2017
From: shanonvl at yahoo.com (Shanon Levenherz)
Date: Wed, 31 May 2017 14:14:58 -0400
Subject: [keycloak-dev] Assign group roles to specific users
Message-ID: <F7EE0B12-301C-4961-AF9B-DC1FCADFC439@yahoo.com>

Hi there,

I?m looking to leverage Keycloak as the primary IdP for our SaaS platform.   We have many tenants, each with sub-tenants and would like to provide them with the ability to administer themselves (including any applicable sub-tenants).     Based on my current research, which includes the multi-tenant example in the GitHub repo, it appears that multiple tenants are supported via separate realms.    My current thinking is that I?d like to use a single realm as I?d like for a platform administrator (like myself) to be able to manage all users in a single place, use a group hierarchy to support multiple tenants, and apply roles to specific users in a group to eg. administer the users or create a sub group for a new tenant.

Something like this:

REALM
|
|- User 1 (user-admin role)
|
|- Tenant 1 Group
|  |
|  |- User 1.1 (user-admin role)
|  |- User 1.2
|  |- ?
|  |- User 1.n
|
|- Tenant 2 Group
|  |
|  |- User 2.1 (user-admin role)
|  |- User 2.1
|  |- ?
|  |- User 2.n
|  |
|  |- Tenant 3 Group
|  |
|  |- User 3.1 (user-admin role)
|  |- User 3.2
|  |- ?
|  |- User 3.n

From the above we?re looking for:

* User 1 is the realm/platform administrator and has full control over all groups/users
* User 1.1 is the administrator for Tenant 1
* User 2.1 is the administrator for Tenants 2 and 3
* User 3.1 is the administrator for Tenant 3

I came across this thread <http://lists.jboss.org/pipermail/keycloak-user/2015-October/003359.html> and specifically this comment from Bill Burke:
>I like that idea.  A better alternative might be that each group has an 
>"user-admin" role.  If a user has the "user-admin" role of the group, it 
>can administer users in that group and assign roles defined in that 
>group.  One thing to really think about is, what about sub-groups.  Can 
>an admin of the parent group administer sub groups?
This post is from October 2015, so I?m curious if the ability to grant specific roles to specific users in a specific group has been implemented at all?   I can?t find anything about it in the docs.  I also just noticed this JIRA issue <https://issues.jboss.org/browse/KEYCLOAK-3168> but am not sure if it?s the same thing.

Please let me know if I can provide more information; I can provide a more complete description of my goals / requirements if that would help.   Thank you! 

Best,
Shanon


From bruno at abstractj.org  Wed May 31 16:22:38 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 31 May 2017 20:22:38 +0000
Subject: [keycloak-dev] Fuse quickstarts
In-Reply-To: <581b30fb-3bec-a6bb-d10e-fe7efb86c005@redhat.com>
References: <CAM5SUC5etRQmU01f6woLpMdr1G1_2vtZ5o_u5SiE7f-1q-aB-Q@mail.gmail.com>
	<581b30fb-3bec-a6bb-d10e-fe7efb86c005@redhat.com>
Message-ID: <CAM5SUC5XnaGcNV7fHiEuovH7PxN5-3sf_yMGEFhiB9DifVKp6w@mail.gmail.com>

Thank you! You guys really know the essence of quick from the start :)

On Wed, May 31, 2017 at 5:01 PM Stan Silvert <ssilvert at redhat.com> wrote:

> I believe that the goal of the quickstart should be to let the developer
> get something working as fast as possible.  (Hence the name "quickstart")
>
> After that, he can look it over, see how it works, and experiment with
> changes.
>
> Anything that delays the joy of a working example increases the
> likelihood that the developer will abandon the effort.
>
> On 5/31/2017 6:35 AM, Bruno Oliveira wrote:
> > For Fuse quickstarts, we have a some configuration steps to setup the
> > server like:
> >
> > 1. Set the Keycloak version
> >
> > KEYCLOAK_VERSION=3.2.0.CR1-SNAPSHOT
> >
> > 2. Add Maven local repository
> >
> > config:edit org.ops4j.pax.url.mvn
> > config:propset org.ops4j.pax.url.mvn.localRepository
> > file:///$HOME/.m2/repository
> > config:update
> >
> > 3. Install quickstarts artifacts
> >
> > 4. Install features
> >
> > features:addurl
> > mvn:org.keycloak/keycloak-osgi-features/$KEYCLOAK_VERSION/xml/features
> > features:addurl
> >
> mvn:org.keycloak.quickstarts/keycloak-fuse-features/$KEYCLOAK_VERSION/xml/features
> > features:install keycloak-fuse-quickstarts
> >
> > I was wondering if we could have a profile to make this process more
> > simple. Something like mvn clean install -Pfuse-server and you're good to
> > go. Do we want this? Or follow all these steps would be the goal as part
> of
> > the learning process?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From john.d.ament at gmail.com  Wed May 31 23:15:49 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 01 Jun 2017 03:15:49 +0000
Subject: [keycloak-dev] Keycloak 3.2 & Clustering
Message-ID: <CAOqetn_jBM5_7tmbcchXpHF1aF1Eai-xgj-fMK6Eq0otR+R+Zg@mail.gmail.com>

All,

I'm not sure what the current release state looks like, but wanted to bring
your attention to an issue in WF11 I had raised.  It actually impacts the
clustering pieces, which is pretty important to keycloak.

https://issues.jboss.org/browse/WFLY-8488

Basically, a number of jgroups configs no longer work in WF11.  I'm not
sure if you have a way to escalate this, since it has pretty important
impact to Keycloak.

John