From sthorger at redhat.com  Thu Jun  1 03:59:59 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Jun 2017 09:59:59 +0200
Subject: [keycloak-dev] Keycloak 3.2 & Clustering
In-Reply-To: <CAOqetn_jBM5_7tmbcchXpHF1aF1Eai-xgj-fMK6Eq0otR+R+Zg@mail.gmail.com>
References: <CAOqetn_jBM5_7tmbcchXpHF1aF1Eai-xgj-fMK6Eq0otR+R+Zg@mail.gmail.com>
Message-ID: <CAJgngAfqYXZ_OHt6uwpiz2XnAmzOW+jkTc2Pzg15FZCR=6_4LQ@mail.gmail.com>

Is JDBC_PING not working at all? Or is it something specific with your
config? Seems like something that would important to get fixed before WF 11
FInal is released.

On 1 June 2017 at 05:15, John D. Ament <john.d.ament at gmail.com> wrote:

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

From sthorger at redhat.com  Thu Jun  1 04:05:19 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Jun 2017 10:05:19 +0200
Subject: [keycloak-dev] The browser property and the
 org.keycloak.testsuite.console.* UI tests
In-Reply-To: <CAMQSZyhsaKq-Nb+chQVVuh8xpdBs3zE5bZzC1TkZC3vEcWnR5Q@mail.gmail.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>
	<CAMQSZyhsaKq-Nb+chQVVuh8xpdBs3zE5bZzC1TkZC3vEcWnR5Q@mail.gmail.com>
Message-ID: <CAJgngAfXVecOhHKE3DCzWWDP8WKQXFkGCeNJ7LjW3ZKsCgghgA@mail.gmail.com>

As long as the tests require a real browser we can't run them as part of a
default build and I also doubt we can run them on Travis. That's a problem
IMO.

On 31 May 2017 at 18:43, Vaclav Muzikar <vmuzikar at redhat.com> wrote:

> 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 sthorger at redhat.com  Thu Jun  1 07:05:44 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Jun 2017 13:05:44 +0200
Subject: [keycloak-dev] Optional client role to specify who is permitted to
	authenticate to client
Message-ID: <CAJgngAfSYtppTwvNfVGWNsY3euVsCZkM4PTRQMD+JSbTaYWJbw@mail.gmail.com>

Would it be an idea to have a field on a client to specify a required role
that users have to have to be permitted to authenticate to the client?

We could add support for this directly in the login flows. If the user has
the required role redirect to the app, but if the user doesn't display an
error page stating you don't have access.

From thomas.raehalme at aitiofinland.com  Thu Jun  1 07:35:40 2017
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 1 Jun 2017 14:35:40 +0300
Subject: [keycloak-dev] Optional client role to specify who is permitted
 to authenticate to client
In-Reply-To: <CAJgngAfSYtppTwvNfVGWNsY3euVsCZkM4PTRQMD+JSbTaYWJbw@mail.gmail.com>
References: <CAJgngAfSYtppTwvNfVGWNsY3euVsCZkM4PTRQMD+JSbTaYWJbw@mail.gmail.com>
Message-ID: <CAPyAMobZHrOHisUKmpSytDrOPxC1jqL3Ufkvt9G3W1d-741gYg@mail.gmail.com>

On Thu, Jun 1, 2017 at 2:05 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Would it be an idea to have a field on a client to specify a required role
> that users have to have to be permitted to authenticate to the client?
>

Yes, please! I think it'd simplify access control when not every user is
authorized to access every client.

Best regards,
Thomas

From sthorger at redhat.com  Thu Jun  1 07:49:02 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Jun 2017 13:49:02 +0200
Subject: [keycloak-dev] Optional client role to specify who is permitted
 to authenticate to client
In-Reply-To: <CAPyAMobZHrOHisUKmpSytDrOPxC1jqL3Ufkvt9G3W1d-741gYg@mail.gmail.com>
References: <CAJgngAfSYtppTwvNfVGWNsY3euVsCZkM4PTRQMD+JSbTaYWJbw@mail.gmail.com>
	<CAPyAMobZHrOHisUKmpSytDrOPxC1jqL3Ufkvt9G3W1d-741gYg@mail.gmail.com>
Message-ID: <CAJgngAdEEs3YssCzfi5Lb9O-b+Tbb5rSvqLYGNZP0ohG2v-GsQ@mail.gmail.com>

It could probably also be used in the future if we ever add a page in
account management console or an SSO landing page that let's users list all
applications they can login to.

On 1 June 2017 at 13:35, Thomas Raehalme <thomas.raehalme at aitiofinland.com>
wrote:

> On Thu, Jun 1, 2017 at 2:05 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Would it be an idea to have a field on a client to specify a required role
>> that users have to have to be permitted to authenticate to the client?
>>
>
> Yes, please! I think it'd simplify access control when not every user is
> authorized to access every client.
>
> Best regards,
> Thomas
>
>
>
>

From john.d.ament at gmail.com  Thu Jun  1 08:15:26 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 01 Jun 2017 12:15:26 +0000
Subject: [keycloak-dev] Keycloak 3.2 & Clustering
In-Reply-To: <CAJgngAfqYXZ_OHt6uwpiz2XnAmzOW+jkTc2Pzg15FZCR=6_4LQ@mail.gmail.com>
References: <CAOqetn_jBM5_7tmbcchXpHF1aF1Eai-xgj-fMK6Eq0otR+R+Zg@mail.gmail.com>
	<CAJgngAfqYXZ_OHt6uwpiz2XnAmzOW+jkTc2Pzg15FZCR=6_4LQ@mail.gmail.com>
Message-ID: <CAOqetn8QTOfavCvG0xdS4XfgZ3TFF2GzJCJ=wAG=VZjgxwcOkg@mail.gmail.com>

Stian,

I haven't tried all permutations.  I'm in general having issues getting
clustering to work 100% in 11, similar to testing I did on 10 to see how to
make KC clustering work in my environment.

The option I'm using is the registration of a datasource to do the
JDBC_PING instead of duplicating the JDBC configuration.  My hunch is that
jgroups is being initialized before the datasource is, and as a result it
can't find the data source.  This implies though that the module itself
isn't available either.

I haven't gotten any TCP based configurations to work, including OOTB.  UDP
at least boots but I haven't tried a two node cluster yet to confirm
replication.

John

On Thu, Jun 1, 2017 at 3:59 AM Stian Thorgersen <sthorger at redhat.com> wrote:

> Is JDBC_PING not working at all? Or is it something specific with your
> config? Seems like something that would important to get fixed before WF 11
> FInal is released.
>
> On 1 June 2017 at 05:15, John D. Ament <john.d.ament at gmail.com> wrote:
>
>> 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
>>
> _______________________________________________
>> 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  Thu Jun  1 08:20:41 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 01 Jun 2017 12:20:41 +0000
Subject: [keycloak-dev] Different internal and external URLs
Message-ID: <CAOqetn96UDozDq2_tQZNtivowEnicMXucYaWbQd_kahBFFfjxw@mail.gmail.com>

Hi

I have a weird deployment (if you haven't already noticed).  Since we're
hosted on AWS, internal bandwidth is cheap while external bandwidth is
expensive and nearly 4x the number of requests required (due to ELBs, HTTP
proxies etc).

I wanted to have different public facing URLs for the end user to have vs
what the internal URLs are for keycloak.  So that any request made from the
client app on the server side to the keycloak instances was routed to an
internal hostname instead of the public hostname.

Right now this isn't possible, but I was wondering if there would be any
interest in making such a change, to allow this?

John

From sthorger at redhat.com  Thu Jun  1 08:47:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Jun 2017 14:47:39 +0200
Subject: [keycloak-dev] Keycloak 3.2 & Clustering
In-Reply-To: <CAOqetn8QTOfavCvG0xdS4XfgZ3TFF2GzJCJ=wAG=VZjgxwcOkg@mail.gmail.com>
References: <CAOqetn_jBM5_7tmbcchXpHF1aF1Eai-xgj-fMK6Eq0otR+R+Zg@mail.gmail.com>
	<CAJgngAfqYXZ_OHt6uwpiz2XnAmzOW+jkTc2Pzg15FZCR=6_4LQ@mail.gmail.com>
	<CAOqetn8QTOfavCvG0xdS4XfgZ3TFF2GzJCJ=wAG=VZjgxwcOkg@mail.gmail.com>
Message-ID: <CAJgngAc7Kcb1k0ZUJiqbmqaW2E-MiGjiJBqBxaWTCG79WZiruQ@mail.gmail.com>

There's a new comment from the WF guys on the issue. They're saying it's a
configuration error on your end that's the problem. If you don't get
anywhere with the suggestions add a comment to the issue and let me know if
you don't get any response quickly. I can ask nicely to get it solved for
WF 11 Final if there is indeed an issue in WF 11, but it would have to be a
general problem with JDBC_PING rather than a minor issue specific to you.

On 1 June 2017 at 14:15, John D. Ament <john.d.ament at gmail.com> wrote:

> Stian,
>
> I haven't tried all permutations.  I'm in general having issues getting
> clustering to work 100% in 11, similar to testing I did on 10 to see how to
> make KC clustering work in my environment.
>
> The option I'm using is the registration of a datasource to do the
> JDBC_PING instead of duplicating the JDBC configuration.  My hunch is that
> jgroups is being initialized before the datasource is, and as a result it
> can't find the data source.  This implies though that the module itself
> isn't available either.
>
> I haven't gotten any TCP based configurations to work, including OOTB.
> UDP at least boots but I haven't tried a two node cluster yet to confirm
> replication.
>
> John
>
>
> On Thu, Jun 1, 2017 at 3:59 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Is JDBC_PING not working at all? Or is it something specific with your
>> config? Seems like something that would important to get fixed before WF 11
>> FInal is released.
>>
>> On 1 June 2017 at 05:15, John D. Ament <john.d.ament at gmail.com> wrote:
>>
>>> 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
>>>
>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>

From sthorger at redhat.com  Thu Jun  1 09:30:54 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Jun 2017 15:30:54 +0200
Subject: [keycloak-dev] Different internal and external URLs
In-Reply-To: <CAOqetn96UDozDq2_tQZNtivowEnicMXucYaWbQd_kahBFFfjxw@mail.gmail.com>
References: <CAOqetn96UDozDq2_tQZNtivowEnicMXucYaWbQd_kahBFFfjxw@mail.gmail.com>
Message-ID: <CAJgngAfON5UJkTupnihjUQ+65d8iGevW8zxpsVrbXXBsA8G8sA@mail.gmail.com>

Can't you just override the IP address in the host file on the machine?

We could consider adding a feature, but it wouldn't be trivial to implement:

* A realm would need to have an issuer/public URL. Maybe also a list of
acceptable request URLs.
* Adapters would need to have two URLs for the auth-server. One the issuer
URL and another the request URL
* This would all need to have automated testing and the documentation would
need to be updated

Then there's also the fact that ideally all connections should use HTTPs so
you'd need one certificate for external request as well as another one for
internal requests. Not sure how that'd look like in the wild.

On 1 June 2017 at 14:20, John D. Ament <john.d.ament at gmail.com> wrote:

> Hi
>
> I have a weird deployment (if you haven't already noticed).  Since we're
> hosted on AWS, internal bandwidth is cheap while external bandwidth is
> expensive and nearly 4x the number of requests required (due to ELBs, HTTP
> proxies etc).
>
> I wanted to have different public facing URLs for the end user to have vs
> what the internal URLs are for keycloak.  So that any request made from the
> client app on the server side to the keycloak instances was routed to an
> internal hostname instead of the public hostname.
>
> Right now this isn't possible, but I was wondering if there would be any
> interest in making such a change, to allow this?
>
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From shanonvl at gmail.com  Thu Jun  1 11:33:03 2017
From: shanonvl at gmail.com (Shanon Levenherz)
Date: Thu, 1 Jun 2017 11:33:03 -0400
Subject: [keycloak-dev] Multiple tenants in a single realm
Message-ID: <2514D7EB-D027-4C2D-8AA7-43EF40E8EEE8@gmail.com>

Hi there,

I?m looking to leverage Keycloak as the primary IdP for our SaaS platform.   We have many tenants, each with their own sub-tenants ( their customers ) and would like to provide them with the ability to administer themselves (and enable sub-tenant users to admin the sub-tenant, etc).     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.   

Disclaimer:  I?m new to Keycloak so maybe am misunderstanding and/or going about this incorrectly? 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 hmlnarik at redhat.com  Thu Jun  1 17:59:10 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 1 Jun 2017 23:59:10 +0200
Subject: [keycloak-dev] The browser property and the
 org.keycloak.testsuite.console.* UI tests
In-Reply-To: <CAJgngAfXVecOhHKE3DCzWWDP8WKQXFkGCeNJ7LjW3ZKsCgghgA@mail.gmail.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>
	<CAMQSZyhsaKq-Nb+chQVVuh8xpdBs3zE5bZzC1TkZC3vEcWnR5Q@mail.gmail.com>
	<CAJgngAfXVecOhHKE3DCzWWDP8WKQXFkGCeNJ7LjW3ZKsCgghgA@mail.gmail.com>
Message-ID: <CAMvXD=F3DCaFiVdHiNp8OSt5cdB9eJQ-MMuyytCYQwOoxyN7=w@mail.gmail.com>

My 2 cents - Travis can run tests with Chrome and Firefox [1] so there
might be a way for automating these. +1 for checking whether the
browser is supported or not before running the UI tests.

--Hynek

[1] https://docs.travis-ci.com/user/gui-and-headless-browsers/

On Thu, Jun 1, 2017 at 10:05 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> As long as the tests require a real browser we can't run them as part of a
> default build and I also doubt we can run them on Travis. That's a problem
> IMO.
>
> On 31 May 2017 at 18:43, Vaclav Muzikar <vmuzikar at redhat.com> wrote:
>
>> 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.
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

--Hynek


From sthorger at redhat.com  Fri Jun  2 02:40:02 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 2 Jun 2017 08:40:02 +0200
Subject: [keycloak-dev] The browser property and the
 org.keycloak.testsuite.console.* UI tests
In-Reply-To: <CAMvXD=F3DCaFiVdHiNp8OSt5cdB9eJQ-MMuyytCYQwOoxyN7=w@mail.gmail.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>
	<CAMQSZyhsaKq-Nb+chQVVuh8xpdBs3zE5bZzC1TkZC3vEcWnR5Q@mail.gmail.com>
	<CAJgngAfXVecOhHKE3DCzWWDP8WKQXFkGCeNJ7LjW3ZKsCgghgA@mail.gmail.com>
	<CAMvXD=F3DCaFiVdHiNp8OSt5cdB9eJQ-MMuyytCYQwOoxyN7=w@mail.gmail.com>
Message-ID: <CAJgngAeh_dZWxa4uehsL9hw2n-FzKyNdrK3-m07MLZQuQ9dSRQ@mail.gmail.com>

Pavel/Vaclav have we properly tried to get these tests to run on PhantomJS?

On 1 June 2017 at 23:59, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> My 2 cents - Travis can run tests with Chrome and Firefox [1] so there
> might be a way for automating these. +1 for checking whether the
> browser is supported or not before running the UI tests.
>
> --Hynek
>
> [1] https://docs.travis-ci.com/user/gui-and-headless-browsers/
>
> On Thu, Jun 1, 2017 at 10:05 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > As long as the tests require a real browser we can't run them as part of
> a
> > default build and I also doubt we can run them on Travis. That's a
> problem
> > IMO.
> >
> > On 31 May 2017 at 18:43, Vaclav Muzikar <vmuzikar at redhat.com> wrote:
> >
> >> 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.
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
>
> --Hynek
>

From bburke at redhat.com  Sat Jun  3 10:22:51 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 3 Jun 2017 10:22:51 -0400
Subject: [keycloak-dev] arquillian testsuite still eating exceptions
Message-ID: <28785f1d-538a-fba9-0143-429fe291b65c@redhat.com>

I'm getting an error during 
AbstractKeycloakTest.afterAbstractKeycloakTest() when cleanup is 
executed.  The problem is that the log only shows NullPointerException 
with no stack trace.  Even worse, the failure only occurs during a full 
maven build.  I can't duplicate the problem in IDE.  Why does arquillian 
not display stack traces?



From bburke at redhat.com  Sat Jun  3 22:09:40 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 3 Jun 2017 22:09:40 -0400
Subject: [keycloak-dev] arquillian testsuite still eating exceptions
In-Reply-To: <28785f1d-538a-fba9-0143-429fe291b65c@redhat.com>
References: <28785f1d-538a-fba9-0143-429fe291b65c@redhat.com>
Message-ID: <c686b9a7-2648-5874-9897-8deb26b937e6@redhat.com>

I guess i should just read the docs?


On 6/3/17 10:22 AM, Bill Burke wrote:
> I'm getting an error during
> AbstractKeycloakTest.afterAbstractKeycloakTest() when cleanup is
> executed.  The problem is that the log only shows NullPointerException
> with no stack trace.  Even worse, the failure only occurs during a full
> maven build.  I can't duplicate the problem in IDE.  Why does arquillian
> not display stack traces?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ivan at akvo.org  Mon Jun  5 03:58:28 2017
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Mon, 5 Jun 2017 09:58:28 +0200
Subject: [keycloak-dev] JavaScript adapter & caching of session status iframe
Message-ID: <c4d24eab-44d2-ba58-847b-95cd9897e954@akvo.org>

Hi all,

We have found an issue when using the JavaScript Adapter [1] and
upgrading from Keycloak 2.5.1 Final to 3.1.0.Final [2]

> By default, the JavaScript adapter creates a hidden iframe that is
> used to detect if a Single-Sign Out has occurred.

Using default settings, Keycloak will send a cache-control header to the
browser and will cache the iframe status page for 30 days. [3]

If you happen to upgrade Keycloak within those 30 days, there is a
out-of-sync interaction between the adapter and Keycloak. The browser
won't even make the HTTP request before those 30 days, and the upgraded
adapter code will attempt to use code from a page that is oudated.

A potential solution is that we use the Keycloak version as cache
busting via query parameters [4], e.g. when injecting the iframe it will
append the Keycloak version:

https://kc-host/realms/realm/protocol/openid-connect/login-status-iframe.html?kc_version=3.1.0.Final

Another 'easier' solution is to not cache the status iframe at all.
This is easier because the JS Adapter is *not* version aware. To include
the version as cache busting, we'll need to include it as part of the
Keycloak object, that means touching this file on every release, even if
the code itself has not changed.

Do you consider this a bug? Should i log it in JIRA? We're happy to
contribute the change.

[1]
http://www.keycloak.org/docs/3.1/securing_apps/topics/oidc/javascript-adapter.html
[2] https://github.com/akvo/akvo-lumen/issues/801
[3]
https://github.com/keycloak/keycloak/blob/3.1.0.Final/services/src/main/java/org/keycloak/protocol/oidc/endpoints/LoginStatusIframeEndpoint.java#L63
[4] https://stackoverflow.com/questions/9692665/cache-busting-via-params

-- 
Iv?n


From ivan at akvo.org  Tue Jun  6 09:28:34 2017
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Tue, 6 Jun 2017 15:28:34 +0200
Subject: [keycloak-dev] JavaScript adapter & caching of session status
 iframe
In-Reply-To: <c4d24eab-44d2-ba58-847b-95cd9897e954@akvo.org>
References: <c4d24eab-44d2-ba58-847b-95cd9897e954@akvo.org>
Message-ID: <655f9f37-46ce-ca4f-303d-36221f3618ef@akvo.org>

Hi again,

I logged the problem as https://issues.jboss.org/browse/KEYCLOAK-5022

I propose to implement the easiest path: not to cache the iframe status
page.

Let me know if you're OK with this approach.

Thanks,

On 06/05/2017 09:58 AM, Iv?n Perdomo wrote:
> Hi all,
> 
> We have found an issue when using the JavaScript Adapter [1] and
> upgrading from Keycloak 2.5.1 Final to 3.1.0.Final [2]
> 
>> By default, the JavaScript adapter creates a hidden iframe that is
>> used to detect if a Single-Sign Out has occurred.
> 
> Using default settings, Keycloak will send a cache-control header to the
> browser and will cache the iframe status page for 30 days. [3]
> 
> If you happen to upgrade Keycloak within those 30 days, there is a
> out-of-sync interaction between the adapter and Keycloak. The browser
> won't even make the HTTP request before those 30 days, and the upgraded
> adapter code will attempt to use code from a page that is oudated.
> 
> A potential solution is that we use the Keycloak version as cache
> busting via query parameters [4], e.g. when injecting the iframe it will
> append the Keycloak version:
> 
> https://kc-host/realms/realm/protocol/openid-connect/login-status-iframe.html?kc_version=3.1.0.Final
> 
> Another 'easier' solution is to not cache the status iframe at all.
> This is easier because the JS Adapter is *not* version aware. To include
> the version as cache busting, we'll need to include it as part of the
> Keycloak object, that means touching this file on every release, even if
> the code itself has not changed.
> 
> Do you consider this a bug? Should i log it in JIRA? We're happy to
> contribute the change.
> 
> [1]
> http://www.keycloak.org/docs/3.1/securing_apps/topics/oidc/javascript-adapter.html
> [2] https://github.com/akvo/akvo-lumen/issues/801
> [3]
> https://github.com/keycloak/keycloak/blob/3.1.0.Final/services/src/main/java/org/keycloak/protocol/oidc/endpoints/LoginStatusIframeEndpoint.java#L63
> [4] https://stackoverflow.com/questions/9692665/cache-busting-via-params
> 

-- 
Iv?n


From psilva at redhat.com  Tue Jun  6 14:37:38 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 Jun 2017 15:37:38 -0300
Subject: [keycloak-dev] Group Based Policy
Message-ID: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>

Hi All,

I'm adding a Group Based Policy to our set of supported policies.
Basically, this policy allows you to define the group(s) you want to give
access to some resource or scope.

Would like to share my initial scope with you and see if you guys have
anything else to add:

* Users can select one or more groups
* Users can define groups using paths (e.g.: /Group A/Group B/*, /Group A,
/Group A/Group B)
* Users can decide whether or not access is granted if the identity is a
member of all or any of the selected groups
* Users can decide whether or not access extends to sub-groups of a parent
group

Please, let me know your thoughts.

Regards.
Pedro Igor

From psilva at redhat.com  Tue Jun  6 15:18:43 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 Jun 2017 16:18:43 -0300
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
Message-ID: <CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>

Forgot to add something to the discussion.

I'm not 100% sure if we should have a group policy though. Reason being
that groups are usually administrative things to group a set of one or more
users and usually they are not really suitable for authorization. For
instance, with current design you could enforce access based on groups as
long as your groups have a specific role which you can use in a role based
policy. In this sense, roles are definitely more suitable for authorization
than groups.


On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi All,
>
> I'm adding a Group Based Policy to our set of supported policies.
> Basically, this policy allows you to define the group(s) you want to give
> access to some resource or scope.
>
> Would like to share my initial scope with you and see if you guys have
> anything else to add:
>
> * Users can select one or more groups
> * Users can define groups using paths (e.g.: /Group A/Group B/*, /Group A,
> /Group A/Group B)
> * Users can decide whether or not access is granted if the identity is a
> member of all or any of the selected groups
> * Users can decide whether or not access extends to sub-groups of a parent
> group
>
> Please, let me know your thoughts.
>
> Regards.
> Pedro Igor
>
>

From bburke at redhat.com  Tue Jun  6 17:52:01 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 6 Jun 2017 17:52:01 -0400
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
Message-ID: <63175197-2ddd-989f-97cd-14593dbddb2e@redhat.com>

I don't think we have any group claim token mappers.


On 6/6/17 2:37 PM, Pedro Igor Silva wrote:
> Hi All,
>
> I'm adding a Group Based Policy to our set of supported policies.
> Basically, this policy allows you to define the group(s) you want to give
> access to some resource or scope.
>
> Would like to share my initial scope with you and see if you guys have
> anything else to add:
>
> * Users can select one or more groups
> * Users can define groups using paths (e.g.: /Group A/Group B/*, /Group A,
> /Group A/Group B)
> * Users can decide whether or not access is granted if the identity is a
> member of all or any of the selected groups
> * Users can decide whether or not access extends to sub-groups of a parent
> group
>
> Please, let me know your thoughts.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Jun  6 18:49:27 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 6 Jun 2017 18:49:27 -0400
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
Message-ID: <cc2e076c-6a64-b40c-1977-331c249e0d66@redhat.com>

Many companies don't have the concept of a role and everything is done 
via group membership.  Just look at Kubernates that relies on group 
membership to define permissions.


On 6/6/17 3:18 PM, Pedro Igor Silva wrote:
> Forgot to add something to the discussion.
>
> I'm not 100% sure if we should have a group policy though. Reason being
> that groups are usually administrative things to group a set of one or more
> users and usually they are not really suitable for authorization. For
> instance, with current design you could enforce access based on groups as
> long as your groups have a specific role which you can use in a role based
> policy. In this sense, roles are definitely more suitable for authorization
> than groups.
>
>
> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hi All,
>>
>> I'm adding a Group Based Policy to our set of supported policies.
>> Basically, this policy allows you to define the group(s) you want to give
>> access to some resource or scope.
>>
>> Would like to share my initial scope with you and see if you guys have
>> anything else to add:
>>
>> * Users can select one or more groups
>> * Users can define groups using paths (e.g.: /Group A/Group B/*, /Group A,
>> /Group A/Group B)
>> * Users can decide whether or not access is granted if the identity is a
>> member of all or any of the selected groups
>> * Users can decide whether or not access extends to sub-groups of a parent
>> group
>>
>> Please, let me know your thoughts.
>>
>> 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  Wed Jun  7 03:00:02 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Wed, 7 Jun 2017 07:00:02 +0000
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
Message-ID: <aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>

I agree 100% with your arguments against supporting group-based policies. :) I guess people doing authorization based on groups are essentially using roles, they are just calling them groups. Keycloak can perfectly cover that case by using roles. The only potential difference I see is when there is something like composite roles or composite groups. With a composite role, you get all the subroles. With a composite group, you are in all the parent groups. However, offering this opposite direction (and adding composite groups) comes at the price of making it even harder for people to decide what they should (and do it correctly) so I don?t think it's really worth it.
I do like the current RBAC way as it is a very clear concept. You can still switch to ABAC if RBAC does not cover your case...

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 Pedro Igor Silva
> Sent: Dienstag, 6. Juni 2017 21:19
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Group Based Policy
> 
> Forgot to add something to the discussion.
> 
> I'm not 100% sure if we should have a group policy though. Reason being that
> groups are usually administrative things to group a set of one or more users and
> usually they are not really suitable for authorization. For instance, with current
> design you could enforce access based on groups as long as your groups have a
> specific role which you can use in a role based policy. In this sense, roles are
> definitely more suitable for authorization than groups.
> 
> 
> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> > Hi All,
> >
> > I'm adding a Group Based Policy to our set of supported policies.
> > Basically, this policy allows you to define the group(s) you want to
> > give access to some resource or scope.
> >
> > Would like to share my initial scope with you and see if you guys have
> > anything else to add:
> >
> > * Users can select one or more groups
> > * Users can define groups using paths (e.g.: /Group A/Group B/*,
> > /Group A, /Group A/Group B)
> > * Users can decide whether or not access is granted if the identity is
> > a member of all or any of the selected groups
> > * Users can decide whether or not access extends to sub-groups of a
> > parent group
> >
> > Please, let me know your thoughts.
> >
> > 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  Wed Jun  7 05:32:37 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 7 Jun 2017 11:32:37 +0200
Subject: [keycloak-dev] JavaScript adapter & caching of session status
	iframe
In-Reply-To: <655f9f37-46ce-ca4f-303d-36221f3618ef@akvo.org>
References: <c4d24eab-44d2-ba58-847b-95cd9897e954@akvo.org>
	<655f9f37-46ce-ca4f-303d-36221f3618ef@akvo.org>
Message-ID: <CAJgngAf_RhQDUfZnE0ToRtgmtE9ccSf5GQ3+NASaJfk21_kkgQ@mail.gmail.com>

There's a similar issue with keycloak.js (
https://issues.jboss.org/browse/KEYCLOAK-4556).

I'm thinking about some hybrid solution to what you are suggesting. Have
one endpoint that doesn't cache and another that caches, but includes the
version in the URL. Then it's up to folks to chose which one to use.

I'll prepare a PR for both issues shortly.

On 6 June 2017 at 15:28, Iv?n Perdomo <ivan at akvo.org> wrote:

> Hi again,
>
> I logged the problem as https://issues.jboss.org/browse/KEYCLOAK-5022
>
> I propose to implement the easiest path: not to cache the iframe status
> page.
>
> Let me know if you're OK with this approach.
>
> Thanks,
>
> On 06/05/2017 09:58 AM, Iv?n Perdomo wrote:
> > Hi all,
> >
> > We have found an issue when using the JavaScript Adapter [1] and
> > upgrading from Keycloak 2.5.1 Final to 3.1.0.Final [2]
> >
> >> By default, the JavaScript adapter creates a hidden iframe that is
> >> used to detect if a Single-Sign Out has occurred.
> >
> > Using default settings, Keycloak will send a cache-control header to the
> > browser and will cache the iframe status page for 30 days. [3]
> >
> > If you happen to upgrade Keycloak within those 30 days, there is a
> > out-of-sync interaction between the adapter and Keycloak. The browser
> > won't even make the HTTP request before those 30 days, and the upgraded
> > adapter code will attempt to use code from a page that is oudated.
> >
> > A potential solution is that we use the Keycloak version as cache
> > busting via query parameters [4], e.g. when injecting the iframe it will
> > append the Keycloak version:
> >
> > https://kc-host/realms/realm/protocol/openid-connect/login-
> status-iframe.html?kc_version=3.1.0.Final
> >
> > Another 'easier' solution is to not cache the status iframe at all.
> > This is easier because the JS Adapter is *not* version aware. To include
> > the version as cache busting, we'll need to include it as part of the
> > Keycloak object, that means touching this file on every release, even if
> > the code itself has not changed.
> >
> > Do you consider this a bug? Should i log it in JIRA? We're happy to
> > contribute the change.
> >
> > [1]
> > http://www.keycloak.org/docs/3.1/securing_apps/topics/oidc/
> javascript-adapter.html
> > [2] https://github.com/akvo/akvo-lumen/issues/801
> > [3]
> > https://github.com/keycloak/keycloak/blob/3.1.0.Final/
> services/src/main/java/org/keycloak/protocol/oidc/endpoints/
> LoginStatusIframeEndpoint.java#L63
> > [4] https://stackoverflow.com/questions/9692665/cache-busting-via-params
> >
>
> --
> Iv?n
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Jun  7 06:14:06 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 7 Jun 2017 12:14:06 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
Message-ID: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>

We've picked Htmlunit as the default browser to run tests with due to it
being the fastest. Downside is that it simply doesn't work very well for
all tests, especially those heavy on the javascript side of things like
testing the JavaScript adapter and admin console.

Just saw that Chrome is actually bringing a headless option to Chrome 59
[1]. This is really nice as it allows headless testing with a real browser,
not just an emulated browser.

Ideally if this is fast we could use it as the default browser instead of
htmlunit. Obviously waiting until it's released on all platforms. If it's
not as fast as htmlunit then maybe there is a compromise.

The default browser would still be htmlunit. Then individual tests could be
marked (with an annotation on the class or on the WebDriver field). Those
marked would use Chrome in headless mode instead of htmlunit. Obviously
-Dbrowser would continue to override the browser in either case.

Thoughts? Anyone interested in giving the new headless Chrome option a spin
and evaluating how fast it is compared to htmlunit?

[1] https://developers.google.com/web/updates/2017/04/headless-chrome

From psilva at redhat.com  Wed Jun  7 07:42:30 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 7 Jun 2017 08:42:30 -0300
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <cc2e076c-6a64-b40c-1977-331c249e0d66@redhat.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<cc2e076c-6a64-b40c-1977-331c249e0d66@redhat.com>
Message-ID: <CAJrcDBfhazQ0Ss33Tuph9XFkokZn+FzhriU9DAxVMutrgTaAww@mail.gmail.com>

Yeah, we don't have any group claim token mapper. But if you assign a
specific role to a group and use this role to represent the group in k8s,
it should work fine. Considering that we do have a role claim token mapper
and k8s allows you to specify a claim from where groups are obtained from a
token.

A group policy could be easily achieved today if you perform the same steps
(create group + assign role to group), where users inherit the role
assigned to they groups they are member of. At the end you just need to
check the role and not really the group membership. Membership is implicit.

On Tue, Jun 6, 2017 at 7:49 PM, Bill Burke <bburke at redhat.com> wrote:

> Many companies don't have the concept of a role and everything is done
> via group membership.  Just look at Kubernates that relies on group
> membership to define permissions.
>
>
> On 6/6/17 3:18 PM, Pedro Igor Silva wrote:
> > Forgot to add something to the discussion.
> >
> > I'm not 100% sure if we should have a group policy though. Reason being
> > that groups are usually administrative things to group a set of one or
> more
> > users and usually they are not really suitable for authorization. For
> > instance, with current design you could enforce access based on groups as
> > long as your groups have a specific role which you can use in a role
> based
> > policy. In this sense, roles are definitely more suitable for
> authorization
> > than groups.
> >
> >
> > On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >
> >> Hi All,
> >>
> >> I'm adding a Group Based Policy to our set of supported policies.
> >> Basically, this policy allows you to define the group(s) you want to
> give
> >> access to some resource or scope.
> >>
> >> Would like to share my initial scope with you and see if you guys have
> >> anything else to add:
> >>
> >> * Users can select one or more groups
> >> * Users can define groups using paths (e.g.: /Group A/Group B/*, /Group
> A,
> >> /Group A/Group B)
> >> * Users can decide whether or not access is granted if the identity is a
> >> member of all or any of the selected groups
> >> * Users can decide whether or not access extends to sub-groups of a
> parent
> >> group
> >>
> >> Please, let me know your thoughts.
> >>
> >> 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  Wed Jun  7 07:46:57 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 7 Jun 2017 08:46:57 -0300
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
Message-ID: <CAJrcDBeZEaw-7CgpAm=nXQjJzWvEyu_TTbssxpuGRCoEJZ8TyA@mail.gmail.com>

Yeah, this is an old discussion .... JEE is another example about how
groups and roles are used in pretty much the same way. The really
difference is that you could actually map a set of one or more roles to a
group. But at the end is just another name with broader permissions.

On Wed, Jun 7, 2017 at 4:00 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> I agree 100% with your arguments against supporting group-based policies.
> :) I guess people doing authorization based on groups are essentially using
> roles, they are just calling them groups. Keycloak can perfectly cover that
> case by using roles. The only potential difference I see is when there is
> something like composite roles or composite groups. With a composite role,
> you get all the subroles. With a composite group, you are in all the parent
> groups. However, offering this opposite direction (and adding composite
> groups) comes at the price of making it even harder for people to decide
> what they should (and do it correctly) so I don?t think it's really worth
> it.
> I do like the current RBAC way as it is a very clear concept. You can
> still switch to ABAC if RBAC does not cover your case...
>
> 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 Pedro Igor Silva
> > Sent: Dienstag, 6. Juni 2017 21:19
> > To: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Subject: Re: [keycloak-dev] Group Based Policy
> >
> > Forgot to add something to the discussion.
> >
> > I'm not 100% sure if we should have a group policy though. Reason being
> that
> > groups are usually administrative things to group a set of one or more
> users and
> > usually they are not really suitable for authorization. For instance,
> with current
> > design you could enforce access based on groups as long as your groups
> have a
> > specific role which you can use in a role based policy. In this sense,
> roles are
> > definitely more suitable for authorization than groups.
> >
> >
> > On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >
> > > Hi All,
> > >
> > > I'm adding a Group Based Policy to our set of supported policies.
> > > Basically, this policy allows you to define the group(s) you want to
> > > give access to some resource or scope.
> > >
> > > Would like to share my initial scope with you and see if you guys have
> > > anything else to add:
> > >
> > > * Users can select one or more groups
> > > * Users can define groups using paths (e.g.: /Group A/Group B/*,
> > > /Group A, /Group A/Group B)
> > > * Users can decide whether or not access is granted if the identity is
> > > a member of all or any of the selected groups
> > > * Users can decide whether or not access extends to sub-groups of a
> > > parent group
> > >
> > > Please, let me know your thoughts.
> > >
> > > Regards.
> > > Pedro Igor
> > >
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From machielg at gmail.com  Wed Jun  7 08:20:49 2017
From: machielg at gmail.com (Machiel Groeneveld)
Date: Wed, 7 Jun 2017 14:20:49 +0200
Subject: [keycloak-dev] Importing credentials via API
Message-ID: <033DCCD7-1424-4911-AA52-8EEB2C42D675@gmail.com>

Hi,

I?m currently migrating a legacy database to Keycloak. I?m importing the users via the REST API. Now I?ve run into the issue that credentials are not stored when the user is created. The code doesn?t seem to invoke any calls related to credentials. The code does exist but is only invoked during the file import (or partial import). 

Is it an option to add the credential processing to the UsersResource.createUser() ?

I?ve also created an issue https://issues.jboss.org/browse/KEYCLOAK-5026 <https://issues.jboss.org/browse/KEYCLOAK-5026> 

From bburke at redhat.com  Wed Jun  7 08:45:33 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 7 Jun 2017 08:45:33 -0400
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
Message-ID: <b170e715-7333-2dc9-d526-d69159885565@redhat.com>

Groups and roles can from a technological perspective be used for the 
same purpose.  But in my mind, Groups are for organizing sets of 
users.   Composite Roles are for managing a set of permissions often 
defined by applications.


On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
> I agree 100% with your arguments against supporting group-based policies. :) I guess people doing authorization based on groups are essentially using roles, they are just calling them groups. Keycloak can perfectly cover that case by using roles. The only potential difference I see is when there is something like composite roles or composite groups. With a composite role, you get all the subroles. With a composite group, you are in all the parent groups. However, offering this opposite direction (and adding composite groups) comes at the price of making it even harder for people to decide what they should (and do it correctly) so I don?t think it's really worth it.
> I do like the current RBAC way as it is a very clear concept. You can still switch to ABAC if RBAC does not cover your case...
>
> 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 Pedro Igor Silva
>> Sent: Dienstag, 6. Juni 2017 21:19
>> To: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Group Based Policy
>>
>> Forgot to add something to the discussion.
>>
>> I'm not 100% sure if we should have a group policy though. Reason being that
>> groups are usually administrative things to group a set of one or more users and
>> usually they are not really suitable for authorization. For instance, with current
>> design you could enforce access based on groups as long as your groups have a
>> specific role which you can use in a role based policy. In this sense, roles are
>> definitely more suitable for authorization than groups.
>>
>>
>> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm adding a Group Based Policy to our set of supported policies.
>>> Basically, this policy allows you to define the group(s) you want to
>>> give access to some resource or scope.
>>>
>>> Would like to share my initial scope with you and see if you guys have
>>> anything else to add:
>>>
>>> * Users can select one or more groups
>>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
>>> /Group A, /Group A/Group B)
>>> * Users can decide whether or not access is granted if the identity is
>>> a member of all or any of the selected groups
>>> * Users can decide whether or not access extends to sub-groups of a
>>> parent group
>>>
>>> Please, let me know your thoughts.
>>>
>>> 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 aszczucz at redhat.com  Wed Jun  7 10:42:52 2017
From: aszczucz at redhat.com (Alex Szczuczko)
Date: Wed, 7 Jun 2017 10:42:52 -0400 (EDT)
Subject: [keycloak-dev] Inconsistency in handling null User attribute
 values: IdentityProviderMapper versus UserRepresentation
In-Reply-To: <2061922386.18583850.1496845743223.JavaMail.zimbra@redhat.com>
Message-ID: <1609519846.18586649.1496846572045.JavaMail.zimbra@redhat.com>

Hi,

My work on KEYCLOAK-4778 highlighted an inconsistency in User attribute value handling. When a IdentityProviderMapper accepts a user attribute, it seems (I haven't looked at all of them) they will drop (not import/store) those that have a null value. However, the REST API does something different. UserRepresentation (through StringListMapDeserializer) will convert null values to a String of "null".

Any objections to changing StringListMapDeserializer to also ignore null valued attributes? UserRepresentation is the only user of StringListMapDeserializer.

Alex

From mposolda at redhat.com  Wed Jun  7 15:53:53 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 7 Jun 2017 21:53:53 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
In-Reply-To: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
References: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
Message-ID: <a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>

Just a note, the main reason why htmlUnit web driver is so faster than 
other browsers is, that it is fully embedded in the same JVM like tests. 
There is no additional overhead in the communication with other 
processes. The only exception are the HTTP requests for the 
communication with the tested Keycloak server and adapters.

On the other hand, the other web driver implementations, including 
phantomJS, are using external process and there is remote selenium 
server with which the webDriver needs to communicate. It means that all 
the webDriver calls including the most simple (like driver.getTitle() ) 
need to send additional HTTP request to the remote selenium server under 
the covers. All of this adds an additional overhead.

I suspect that headless chrome will also use remote selenium, hence I 
don't expect that performance will be much better comparing to 
phantomJS. But maybe I am wrong..

Marek

On 07/06/17 12:14, Stian Thorgersen wrote:
> We've picked Htmlunit as the default browser to run tests with due to it
> being the fastest. Downside is that it simply doesn't work very well for
> all tests, especially those heavy on the javascript side of things like
> testing the JavaScript adapter and admin console.
>
> Just saw that Chrome is actually bringing a headless option to Chrome 59
> [1]. This is really nice as it allows headless testing with a real browser,
> not just an emulated browser.
>
> Ideally if this is fast we could use it as the default browser instead of
> htmlunit. Obviously waiting until it's released on all platforms. If it's
> not as fast as htmlunit then maybe there is a compromise.
>
> The default browser would still be htmlunit. Then individual tests could be
> marked (with an annotation on the class or on the WebDriver field). Those
> marked would use Chrome in headless mode instead of htmlunit. Obviously
> -Dbrowser would continue to override the browser in either case.
>
> Thoughts? Anyone interested in giving the new headless Chrome option a spin
> and evaluating how fast it is compared to htmlunit?
>
> [1] https://developers.google.com/web/updates/2017/04/headless-chrome
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From thomas.darimont at googlemail.com  Wed Jun  7 15:59:58 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 7 Jun 2017 21:59:58 +0200
Subject: [keycloak-dev] Importing credentials via API
In-Reply-To: <033DCCD7-1424-4911-AA52-8EEB2C42D675@gmail.com>
References: <033DCCD7-1424-4911-AA52-8EEB2C42D675@gmail.com>
Message-ID: <CAK-7U1jEGT=CWjJ5Tu4+PExF3W7U9n8w+CJ93UFK_DDWxT0CTQ@mail.gmail.com>

Hello Machiel,

you need to use the resetCredential(..) endpoint of a user resource,
e.g.: userRessource.get(userId).resetPassword(passwordCred);

Here is an complete example for the Keycloak AdminClient:
https://gist.github.com/thomasdarimont/0c136d0b8d339b997928e9bef225f941
which shows how to:
- create a user
- set user attributes
- assign roles (realm roles as well as client specific roles)
- set a password

Cheers,
Thomas

2017-06-07 14:20 GMT+02:00 Machiel Groeneveld <machielg at gmail.com>:

> Hi,
>
> I?m currently migrating a legacy database to Keycloak. I?m importing the
> users via the REST API. Now I?ve run into the issue that credentials are
> not stored when the user is created. The code doesn?t seem to invoke any
> calls related to credentials. The code does exist but is only invoked
> during the file import (or partial import).
>
> Is it an option to add the credential processing to the
> UsersResource.createUser() ?
>
> I?ve also created an issue https://issues.jboss.org/browse/KEYCLOAK-5026 <
> https://issues.jboss.org/browse/KEYCLOAK-5026>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Thu Jun  8 02:01:48 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Jun 2017 08:01:48 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
In-Reply-To: <a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
References: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
	<a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
Message-ID: <CAJgngAdR2g1a0Sxtob=_6P4383XGyX0GXuxPR83Ow45WAST=Xw@mail.gmail.com>

Is it always using HTTP? Surely it could be using some sort of sockets for
better perf. I think you're right though and we'll probably end up sticking
with htmlunit for most tests.

On 7 June 2017 at 21:53, Marek Posolda <mposolda at redhat.com> wrote:

> Just a note, the main reason why htmlUnit web driver is so faster than
> other browsers is, that it is fully embedded in the same JVM like tests.
> There is no additional overhead in the communication with other processes.
> The only exception are the HTTP requests for the communication with the
> tested Keycloak server and adapters.
>
> On the other hand, the other web driver implementations, including
> phantomJS, are using external process and there is remote selenium server
> with which the webDriver needs to communicate. It means that all the
> webDriver calls including the most simple (like driver.getTitle() ) need to
> send additional HTTP request to the remote selenium server under the
> covers. All of this adds an additional overhead.
>
> I suspect that headless chrome will also use remote selenium, hence I
> don't expect that performance will be much better comparing to phantomJS.
> But maybe I am wrong..
>
> Marek
>
>
> On 07/06/17 12:14, Stian Thorgersen wrote:
>
>> We've picked Htmlunit as the default browser to run tests with due to it
>> being the fastest. Downside is that it simply doesn't work very well for
>> all tests, especially those heavy on the javascript side of things like
>> testing the JavaScript adapter and admin console.
>>
>> Just saw that Chrome is actually bringing a headless option to Chrome 59
>> [1]. This is really nice as it allows headless testing with a real
>> browser,
>> not just an emulated browser.
>>
>> Ideally if this is fast we could use it as the default browser instead of
>> htmlunit. Obviously waiting until it's released on all platforms. If it's
>> not as fast as htmlunit then maybe there is a compromise.
>>
>> The default browser would still be htmlunit. Then individual tests could
>> be
>> marked (with an annotation on the class or on the WebDriver field). Those
>> marked would use Chrome in headless mode instead of htmlunit. Obviously
>> -Dbrowser would continue to override the browser in either case.
>>
>> Thoughts? Anyone interested in giving the new headless Chrome option a
>> spin
>> and evaluating how fast it is compared to htmlunit?
>>
>> [1] https://developers.google.com/web/updates/2017/04/headless-chrome
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From sthorger at redhat.com  Thu Jun  8 02:02:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Jun 2017 08:02:27 +0200
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <b170e715-7333-2dc9-d526-d69159885565@redhat.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
Message-ID: <CAJgngAeZBgHYD4V+7tfGd-Z+Pg9MZ+U8ZbR+2DwsiPYesK6MLQ@mail.gmail.com>

+1 That's a very elegant way of explaining the difference.

On 7 June 2017 at 14:45, Bill Burke <bburke at redhat.com> wrote:

> Groups and roles can from a technological perspective be used for the
> same purpose.  But in my mind, Groups are for organizing sets of
> users.   Composite Roles are for managing a set of permissions often
> defined by applications.
>
>
> On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
> > I agree 100% with your arguments against supporting group-based
> policies. :) I guess people doing authorization based on groups are
> essentially using roles, they are just calling them groups. Keycloak can
> perfectly cover that case by using roles. The only potential difference I
> see is when there is something like composite roles or composite groups.
> With a composite role, you get all the subroles. With a composite group,
> you are in all the parent groups. However, offering this opposite direction
> (and adding composite groups) comes at the price of making it even harder
> for people to decide what they should (and do it correctly) so I don?t
> think it's really worth it.
> > I do like the current RBAC way as it is a very clear concept. You can
> still switch to ABAC if RBAC does not cover your case...
> >
> > 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 Pedro Igor Silva
> >> Sent: Dienstag, 6. Juni 2017 21:19
> >> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Group Based Policy
> >>
> >> Forgot to add something to the discussion.
> >>
> >> I'm not 100% sure if we should have a group policy though. Reason being
> that
> >> groups are usually administrative things to group a set of one or more
> users and
> >> usually they are not really suitable for authorization. For instance,
> with current
> >> design you could enforce access based on groups as long as your groups
> have a
> >> specific role which you can use in a role based policy. In this sense,
> roles are
> >> definitely more suitable for authorization than groups.
> >>
> >>
> >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I'm adding a Group Based Policy to our set of supported policies.
> >>> Basically, this policy allows you to define the group(s) you want to
> >>> give access to some resource or scope.
> >>>
> >>> Would like to share my initial scope with you and see if you guys have
> >>> anything else to add:
> >>>
> >>> * Users can select one or more groups
> >>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
> >>> /Group A, /Group A/Group B)
> >>> * Users can decide whether or not access is granted if the identity is
> >>> a member of all or any of the selected groups
> >>> * Users can decide whether or not access extends to sub-groups of a
> >>> parent group
> >>>
> >>> Please, let me know your thoughts.
> >>>
> >>> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Jun  8 02:27:42 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Jun 2017 08:27:42 +0200
Subject: [keycloak-dev] Renaming testsuite/integration to
	testsuite/integration-deprecated
Message-ID: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>

I would like to rename testsuite/integration to
testsuite/integration-deprecated. This is to make it clear to external
contributors that the testsuite is deprecated and new tests should be added
to testsuite/integration-arquillian.

I would also like to rename testsuite/integration-arquillian
to testsuite/integration.

From vmuzikar at redhat.com  Thu Jun  8 03:20:38 2017
From: vmuzikar at redhat.com (Vaclav Muzikar)
Date: Thu, 8 Jun 2017 09:20:38 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
In-Reply-To: <a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
References: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
	<a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
Message-ID: <CAMQSZyg2r3fah-EpkYfB+uZPFEnDe5dwXrZZsBcFWH-2p7sw9g@mail.gmail.com>

I agree with Marek - I don't think it would do any good for us as the
default browser.
Imho the new headless mode doesn't make a much difference for us - the
Chrome would be working on the same principle as before (through
ChromeDriver).
Moreover, Chrome and ChromeDriver would need to be downloaded/installed
from external sources - yet, this could be perhaps solvable with Maven (at
least ChromeDriver as it's in the Maven repo).

On Wed, Jun 7, 2017 at 9:53 PM, Marek Posolda <mposolda at redhat.com> wrote:

> Just a note, the main reason why htmlUnit web driver is so faster than
> other browsers is, that it is fully embedded in the same JVM like tests.
> There is no additional overhead in the communication with other
> processes. The only exception are the HTTP requests for the
> communication with the tested Keycloak server and adapters.
>
> On the other hand, the other web driver implementations, including
> phantomJS, are using external process and there is remote selenium
> server with which the webDriver needs to communicate. It means that all
> the webDriver calls including the most simple (like driver.getTitle() )
> need to send additional HTTP request to the remote selenium server under
> the covers. All of this adds an additional overhead.
>
> I suspect that headless chrome will also use remote selenium, hence I
> don't expect that performance will be much better comparing to
> phantomJS. But maybe I am wrong..
>
> Marek
>
> On 07/06/17 12:14, Stian Thorgersen wrote:
> > We've picked Htmlunit as the default browser to run tests with due to it
> > being the fastest. Downside is that it simply doesn't work very well for
> > all tests, especially those heavy on the javascript side of things like
> > testing the JavaScript adapter and admin console.
> >
> > Just saw that Chrome is actually bringing a headless option to Chrome 59
> > [1]. This is really nice as it allows headless testing with a real
> browser,
> > not just an emulated browser.
> >
> > Ideally if this is fast we could use it as the default browser instead of
> > htmlunit. Obviously waiting until it's released on all platforms. If it's
> > not as fast as htmlunit then maybe there is a compromise.
> >
> > The default browser would still be htmlunit. Then individual tests could
> be
> > marked (with an annotation on the class or on the WebDriver field). Those
> > marked would use Chrome in headless mode instead of htmlunit. Obviously
> > -Dbrowser would continue to override the browser in either case.
> >
> > Thoughts? Anyone interested in giving the new headless Chrome option a
> spin
> > and evaluating how fast it is compared to htmlunit?
> >
> > [1] https://developers.google.com/web/updates/2017/04/headless-chrome
> > _______________________________________________
> > 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
>



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

From mposolda at redhat.com  Thu Jun  8 04:27:18 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Jun 2017 10:27:18 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
In-Reply-To: <CAMQSZyg2r3fah-EpkYfB+uZPFEnDe5dwXrZZsBcFWH-2p7sw9g@mail.gmail.com>
References: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
	<a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
	<CAMQSZyg2r3fah-EpkYfB+uZPFEnDe5dwXrZZsBcFWH-2p7sw9g@mail.gmail.com>
Message-ID: <e50e23a3-b0ea-560b-bfd5-20a32f932922@redhat.com>

 From what I see, there is no support for other protocol besides HTTP. 
All the WebDriver implementations despite HtmlUnit extends from 
RemoteWebDriver, which uses the CommandExecutor interface for 
communicate with the server. In theory, the CommandExecutor 
implementation is pluggable, but in reality, all the implementations 
uses HTTP based command executor, which uses Apache HTTP Client under 
the covers to communicate with the selenium server and they don't 
provide straightforward way to use something different.

Not sure if there is some performance improvement in newest version? We 
use the WebDriver version, which uses selenium 2.53.0. Now there is 
already version 3 available.

Marek

On 08/06/17 09:20, Vaclav Muzikar wrote:
> I agree with Marek - I don't think it would do any good for us as the 
> default browser.
> Imho the new headless mode doesn't make a much difference for us - the 
> Chrome would be working on the same principle as before (through 
> ChromeDriver).
> Moreover, Chrome and ChromeDriver would need to be 
> downloaded/installed from external sources - yet, this could be 
> perhaps solvable with Maven (at least ChromeDriver as it's in the 
> Maven repo).
>
> On Wed, Jun 7, 2017 at 9:53 PM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Just a note, the main reason why htmlUnit web driver is so faster than
>     other browsers is, that it is fully embedded in the same JVM like
>     tests.
>     There is no additional overhead in the communication with other
>     processes. The only exception are the HTTP requests for the
>     communication with the tested Keycloak server and adapters.
>
>     On the other hand, the other web driver implementations, including
>     phantomJS, are using external process and there is remote selenium
>     server with which the webDriver needs to communicate. It means
>     that all
>     the webDriver calls including the most simple (like
>     driver.getTitle() )
>     need to send additional HTTP request to the remote selenium server
>     under
>     the covers. All of this adds an additional overhead.
>
>     I suspect that headless chrome will also use remote selenium, hence I
>     don't expect that performance will be much better comparing to
>     phantomJS. But maybe I am wrong..
>
>     Marek
>
>     On 07/06/17 12:14, Stian Thorgersen wrote:
>     > We've picked Htmlunit as the default browser to run tests with
>     due to it
>     > being the fastest. Downside is that it simply doesn't work very
>     well for
>     > all tests, especially those heavy on the javascript side of
>     things like
>     > testing the JavaScript adapter and admin console.
>     >
>     > Just saw that Chrome is actually bringing a headless option to
>     Chrome 59
>     > [1]. This is really nice as it allows headless testing with a
>     real browser,
>     > not just an emulated browser.
>     >
>     > Ideally if this is fast we could use it as the default browser
>     instead of
>     > htmlunit. Obviously waiting until it's released on all
>     platforms. If it's
>     > not as fast as htmlunit then maybe there is a compromise.
>     >
>     > The default browser would still be htmlunit. Then individual
>     tests could be
>     > marked (with an annotation on the class or on the WebDriver
>     field). Those
>     > marked would use Chrome in headless mode instead of htmlunit.
>     Obviously
>     > -Dbrowser would continue to override the browser in either case.
>     >
>     > Thoughts? Anyone interested in giving the new headless Chrome
>     option a spin
>     > and evaluating how fast it is compared to htmlunit?
>     >
>     > [1]
>     https://developers.google.com/web/updates/2017/04/headless-chrome
>     <https://developers.google.com/web/updates/2017/04/headless-chrome>
>     > _______________________________________________
>     > 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>
>
>
>
>
> -- 
> V?clav Muzik??
> Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.



From sthorger at redhat.com  Thu Jun  8 08:58:03 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Jun 2017 14:58:03 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
In-Reply-To: <e50e23a3-b0ea-560b-bfd5-20a32f932922@redhat.com>
References: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
	<a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
	<CAMQSZyg2r3fah-EpkYfB+uZPFEnDe5dwXrZZsBcFWH-2p7sw9g@mail.gmail.com>
	<e50e23a3-b0ea-560b-bfd5-20a32f932922@redhat.com>
Message-ID: <CAJgngAesiL4fZxzEc5dRp7wXYeySbmvRNGd5MiDxmWuitfr=bw@mail.gmail.com>

Ok, so default browser will 99.999% remain htmlunit. That means we do need
an option to specify two browsers. First browser defaults to htmlunit,
second browser needs to default to something that works well with JS
testing. The second browser could default to Chrome headless, but would  be
possible to disable and in that case those particular tests wouldn't run. I
just don't think it's going to be feasible to get all tests to run on
htmlunit. Feel free to correct me if I'm wrong on the latter part and it is
indeed possible to test everything with htmlunit.

On 8 June 2017 at 10:27, Marek Posolda <mposolda at redhat.com> wrote:

> From what I see, there is no support for other protocol besides HTTP. All
> the WebDriver implementations despite HtmlUnit extends from
> RemoteWebDriver, which uses the CommandExecutor interface for communicate
> with the server. In theory, the CommandExecutor implementation is
> pluggable, but in reality, all the implementations uses HTTP based command
> executor, which uses Apache HTTP Client under the covers to communicate
> with the selenium server and they don't provide straightforward way to use
> something different.
>
> Not sure if there is some performance improvement in newest version? We
> use the WebDriver version, which uses selenium 2.53.0. Now there is already
> version 3 available.
>
> Marek
>
>
> On 08/06/17 09:20, Vaclav Muzikar wrote:
>
> I agree with Marek - I don't think it would do any good for us as the
> default browser.
> Imho the new headless mode doesn't make a much difference for us - the
> Chrome would be working on the same principle as before (through
> ChromeDriver).
> Moreover, Chrome and ChromeDriver would need to be downloaded/installed
> from external sources - yet, this could be perhaps solvable with Maven (at
> least ChromeDriver as it's in the Maven repo).
>
> On Wed, Jun 7, 2017 at 9:53 PM, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Just a note, the main reason why htmlUnit web driver is so faster than
>> other browsers is, that it is fully embedded in the same JVM like tests.
>> There is no additional overhead in the communication with other
>> processes. The only exception are the HTTP requests for the
>> communication with the tested Keycloak server and adapters.
>>
>> On the other hand, the other web driver implementations, including
>> phantomJS, are using external process and there is remote selenium
>> server with which the webDriver needs to communicate. It means that all
>> the webDriver calls including the most simple (like driver.getTitle() )
>> need to send additional HTTP request to the remote selenium server under
>> the covers. All of this adds an additional overhead.
>>
>> I suspect that headless chrome will also use remote selenium, hence I
>> don't expect that performance will be much better comparing to
>> phantomJS. But maybe I am wrong..
>>
>> Marek
>>
>> On 07/06/17 12:14, Stian Thorgersen wrote:
>> > We've picked Htmlunit as the default browser to run tests with due to it
>> > being the fastest. Downside is that it simply doesn't work very well for
>> > all tests, especially those heavy on the javascript side of things like
>> > testing the JavaScript adapter and admin console.
>> >
>> > Just saw that Chrome is actually bringing a headless option to Chrome 59
>> > [1]. This is really nice as it allows headless testing with a real
>> browser,
>> > not just an emulated browser.
>> >
>> > Ideally if this is fast we could use it as the default browser instead
>> of
>> > htmlunit. Obviously waiting until it's released on all platforms. If
>> it's
>> > not as fast as htmlunit then maybe there is a compromise.
>> >
>> > The default browser would still be htmlunit. Then individual tests
>> could be
>> > marked (with an annotation on the class or on the WebDriver field).
>> Those
>> > marked would use Chrome in headless mode instead of htmlunit. Obviously
>> > -Dbrowser would continue to override the browser in either case.
>> >
>> > Thoughts? Anyone interested in giving the new headless Chrome option a
>> spin
>> > and evaluating how fast it is compared to htmlunit?
>> >
>> > [1] https://developers.google.com/web/updates/2017/04/headless-chrome
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
> V?clav Muzik??
> Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
>
>
>

From psilva at redhat.com  Thu Jun  8 10:54:39 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 8 Jun 2017 11:54:39 -0300
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <b170e715-7333-2dc9-d526-d69159885565@redhat.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
Message-ID: <CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>

Yeah, that is what I also think. In any case, I'm going to implement a
group policy as users may not want to assign roles to their groups every
time they want a group-based access control mechanism associated with their
permissions. You can do it that way, but in some cases (like the one you
mentioned) it may be boring specially when groups come from LDAP without
roles associated with them.

On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:

> Groups and roles can from a technological perspective be used for the
> same purpose.  But in my mind, Groups are for organizing sets of
> users.   Composite Roles are for managing a set of permissions often
> defined by applications.
>
>
> On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
> > I agree 100% with your arguments against supporting group-based
> policies. :) I guess people doing authorization based on groups are
> essentially using roles, they are just calling them groups. Keycloak can
> perfectly cover that case by using roles. The only potential difference I
> see is when there is something like composite roles or composite groups.
> With a composite role, you get all the subroles. With a composite group,
> you are in all the parent groups. However, offering this opposite direction
> (and adding composite groups) comes at the price of making it even harder
> for people to decide what they should (and do it correctly) so I don?t
> think it's really worth it.
> > I do like the current RBAC way as it is a very clear concept. You can
> still switch to ABAC if RBAC does not cover your case...
> >
> > 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 Pedro Igor Silva
> >> Sent: Dienstag, 6. Juni 2017 21:19
> >> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Group Based Policy
> >>
> >> Forgot to add something to the discussion.
> >>
> >> I'm not 100% sure if we should have a group policy though. Reason being
> that
> >> groups are usually administrative things to group a set of one or more
> users and
> >> usually they are not really suitable for authorization. For instance,
> with current
> >> design you could enforce access based on groups as long as your groups
> have a
> >> specific role which you can use in a role based policy. In this sense,
> roles are
> >> definitely more suitable for authorization than groups.
> >>
> >>
> >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I'm adding a Group Based Policy to our set of supported policies.
> >>> Basically, this policy allows you to define the group(s) you want to
> >>> give access to some resource or scope.
> >>>
> >>> Would like to share my initial scope with you and see if you guys have
> >>> anything else to add:
> >>>
> >>> * Users can select one or more groups
> >>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
> >>> /Group A, /Group A/Group B)
> >>> * Users can decide whether or not access is granted if the identity is
> >>> a member of all or any of the selected groups
> >>> * Users can decide whether or not access extends to sub-groups of a
> >>> parent group
> >>>
> >>> Please, let me know your thoughts.
> >>>
> >>> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Thu Jun  8 10:55:54 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 8 Jun 2017 10:55:54 -0400
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
Message-ID: <5615c20f-1072-1687-768d-64f49f2788b7@redhat.com>

We need a protocol mapper for groups too for this to be able to work.  
You'll also need to change the Identity interface.


On 6/8/17 10:54 AM, Pedro Igor Silva wrote:
> Yeah, that is what I also think. In any case, I'm going to implement a 
> group policy as users may not want to assign roles to their groups 
> every time they want a group-based access control mechanism associated 
> with their permissions. You can do it that way, but in some cases 
> (like the one you mentioned) it may be boring specially when groups 
> come from LDAP without roles associated with them.
>
> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Groups and roles can from a technological perspective be used for the
>     same purpose.  But in my mind, Groups are for organizing sets of
>     users.   Composite Roles are for managing a set of permissions often
>     defined by applications.
>
>
>     On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
>     > I agree 100% with your arguments against supporting group-based
>     policies. :) I guess people doing authorization based on groups
>     are essentially using roles, they are just calling them groups.
>     Keycloak can perfectly cover that case by using roles. The only
>     potential difference I see is when there is something like
>     composite roles or composite groups. With a composite role, you
>     get all the subroles. With a composite group, you are in all the
>     parent groups. However, offering this opposite direction (and
>     adding composite groups) comes at the price of making it even
>     harder for people to decide what they should (and do it correctly)
>     so I don?t think it's really worth it.
>     > I do like the current RBAC way as it is a very clear concept.
>     You can still switch to ABAC if RBAC does not cover your case...
>     >
>     > 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 Pedro Igor Silva
>     >> Sent: Dienstag, 6. Juni 2017 21:19
>     >> To: keycloak-dev <keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     >> Subject: Re: [keycloak-dev] Group Based Policy
>     >>
>     >> Forgot to add something to the discussion.
>     >>
>     >> I'm not 100% sure if we should have a group policy though.
>     Reason being that
>     >> groups are usually administrative things to group a set of one
>     or more users and
>     >> usually they are not really suitable for authorization. For
>     instance, with current
>     >> design you could enforce access based on groups as long as your
>     groups have a
>     >> specific role which you can use in a role based policy. In this
>     sense, roles are
>     >> definitely more suitable for authorization than groups.
>     >>
>     >>
>     >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
>     <psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
>     >>
>     >>> Hi All,
>     >>>
>     >>> I'm adding a Group Based Policy to our set of supported policies.
>     >>> Basically, this policy allows you to define the group(s) you
>     want to
>     >>> give access to some resource or scope.
>     >>>
>     >>> Would like to share my initial scope with you and see if you
>     guys have
>     >>> anything else to add:
>     >>>
>     >>> * Users can select one or more groups
>     >>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
>     >>> /Group A, /Group A/Group B)
>     >>> * Users can decide whether or not access is granted if the
>     identity is
>     >>> a member of all or any of the selected groups
>     >>> * Users can decide whether or not access extends to sub-groups
>     of a
>     >>> parent group
>     >>>
>     >>> Please, let me know your thoughts.
>     >>>
>     >>> 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>
>
>     _______________________________________________
>     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  Thu Jun  8 11:00:27 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 08 Jun 2017 15:00:27 +0000
Subject: [keycloak-dev] Renaming testsuite/integration to
	testsuite/integration-deprecated
In-Reply-To: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
References: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
Message-ID: <CAM5SUC6HYDMZ65vv-9SpeBa7Vcwn0C_=nJrkwqbhdp7nTZc8_A@mail.gmail.com>

+1000

On Thu, Jun 8, 2017 at 11:49 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> I would like to rename testsuite/integration to
> testsuite/integration-deprecated. This is to make it clear to external
> contributors that the testsuite is deprecated and new tests should be added
> to testsuite/integration-arquillian.
>
> I would also like to rename testsuite/integration-arquillian
> to testsuite/integration.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Thu Jun  8 11:02:52 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 8 Jun 2017 12:02:52 -0300
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <5615c20f-1072-1687-768d-64f49f2788b7@redhat.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
	<5615c20f-1072-1687-768d-64f49f2788b7@redhat.com>
Message-ID: <CAJrcDBfuQMxch10KR_rirO-L15aSduNTxfExow1MDG0pzMSKZw@mail.gmail.com>

Would be enough to include only the groups paths in the token ? I think
that way clients could easily check membership by looking the path for each
group. Probably using a string array claim.

On Thu, Jun 8, 2017 at 11:55 AM, Bill Burke <bburke at redhat.com> wrote:

> We need a protocol mapper for groups too for this to be able to work.
> You'll also need to change the Identity interface.
>
> On 6/8/17 10:54 AM, Pedro Igor Silva wrote:
>
> Yeah, that is what I also think. In any case, I'm going to implement a
> group policy as users may not want to assign roles to their groups every
> time they want a group-based access control mechanism associated with their
> permissions. You can do it that way, but in some cases (like the one you
> mentioned) it may be boring specially when groups come from LDAP without
> roles associated with them.
>
> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Groups and roles can from a technological perspective be used for the
>> same purpose.  But in my mind, Groups are for organizing sets of
>> users.   Composite Roles are for managing a set of permissions often
>> defined by applications.
>>
>>
>> On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
>> > I agree 100% with your arguments against supporting group-based
>> policies. :) I guess people doing authorization based on groups are
>> essentially using roles, they are just calling them groups. Keycloak can
>> perfectly cover that case by using roles. The only potential difference I
>> see is when there is something like composite roles or composite groups.
>> With a composite role, you get all the subroles. With a composite group,
>> you are in all the parent groups. However, offering this opposite direction
>> (and adding composite groups) comes at the price of making it even harder
>> for people to decide what they should (and do it correctly) so I don?t
>> think it's really worth it.
>> > I do like the current RBAC way as it is a very clear concept. You can
>> still switch to ABAC if RBAC does not cover your case...
>> >
>> > 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 Pedro Igor Silva
>> >> Sent: Dienstag, 6. Juni 2017 21:19
>> >> To: keycloak-dev <keycloak-dev at lists.jboss.org>
>> >> Subject: Re: [keycloak-dev] Group Based Policy
>> >>
>> >> Forgot to add something to the discussion.
>> >>
>> >> I'm not 100% sure if we should have a group policy though. Reason
>> being that
>> >> groups are usually administrative things to group a set of one or more
>> users and
>> >> usually they are not really suitable for authorization. For instance,
>> with current
>> >> design you could enforce access based on groups as long as your groups
>> have a
>> >> specific role which you can use in a role based policy. In this sense,
>> roles are
>> >> definitely more suitable for authorization than groups.
>> >>
>> >>
>> >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> >>
>> >>> Hi All,
>> >>>
>> >>> I'm adding a Group Based Policy to our set of supported policies.
>> >>> Basically, this policy allows you to define the group(s) you want to
>> >>> give access to some resource or scope.
>> >>>
>> >>> Would like to share my initial scope with you and see if you guys have
>> >>> anything else to add:
>> >>>
>> >>> * Users can select one or more groups
>> >>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
>> >>> /Group A, /Group A/Group B)
>> >>> * Users can decide whether or not access is granted if the identity is
>> >>> a member of all or any of the selected groups
>> >>> * Users can decide whether or not access extends to sub-groups of a
>> >>> parent group
>> >>>
>> >>> Please, let me know your thoughts.
>> >>>
>> >>> 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
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From bburke at redhat.com  Thu Jun  8 11:04:03 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 8 Jun 2017 11:04:03 -0400
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBfuQMxch10KR_rirO-L15aSduNTxfExow1MDG0pzMSKZw@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
	<5615c20f-1072-1687-768d-64f49f2788b7@redhat.com>
	<CAJrcDBfuQMxch10KR_rirO-L15aSduNTxfExow1MDG0pzMSKZw@mail.gmail.com>
Message-ID: <6a812eca-bbd6-bf10-c5e5-d33c9d10008d@redhat.com>

Yes that works.


On 6/8/17 11:02 AM, Pedro Igor Silva wrote:
> Would be enough to include only the groups paths in the token ? I 
> think that way clients could easily check membership by looking the 
> path for each group. Probably using a string array claim.
>
> On Thu, Jun 8, 2017 at 11:55 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     We need a protocol mapper for groups too for this to be able to
>     work.  You'll also need to change the Identity interface.
>
>
>     On 6/8/17 10:54 AM, Pedro Igor Silva wrote:
>>     Yeah, that is what I also think. In any case, I'm going to
>>     implement a group policy as users may not want to assign roles to
>>     their groups every time they want a group-based access control
>>     mechanism associated with their permissions. You can do it that
>>     way, but in some cases (like the one you mentioned) it may be
>>     boring specially when groups come from LDAP without roles
>>     associated with them.
>>
>>     On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         Groups and roles can from a technological perspective be used
>>         for the
>>         same purpose.  But in my mind, Groups are for organizing sets of
>>         users.   Composite Roles are for managing a set of
>>         permissions often
>>         defined by applications.
>>
>>
>>         On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
>>         > I agree 100% with your arguments against supporting
>>         group-based policies. :) I guess people doing authorization
>>         based on groups are essentially using roles, they are just
>>         calling them groups. Keycloak can perfectly cover that case
>>         by using roles. The only potential difference I see is when
>>         there is something like composite roles or composite groups.
>>         With a composite role, you get all the subroles. With a
>>         composite group, you are in all the parent groups. However,
>>         offering this opposite direction (and adding composite
>>         groups) comes at the price of making it even harder for
>>         people to decide what they should (and do it correctly) so I
>>         don?t think it's really worth it.
>>         > I do like the current RBAC way as it is a very clear
>>         concept. You can still switch to ABAC if RBAC does not cover
>>         your case...
>>         >
>>         > 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 Pedro Igor Silva
>>         >> Sent: Dienstag, 6. Juni 2017 21:19
>>         >> To: keycloak-dev <keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>         >> Subject: Re: [keycloak-dev] Group Based Policy
>>         >>
>>         >> Forgot to add something to the discussion.
>>         >>
>>         >> I'm not 100% sure if we should have a group policy though.
>>         Reason being that
>>         >> groups are usually administrative things to group a set of
>>         one or more users and
>>         >> usually they are not really suitable for authorization.
>>         For instance, with current
>>         >> design you could enforce access based on groups as long as
>>         your groups have a
>>         >> specific role which you can use in a role based policy. In
>>         this sense, roles are
>>         >> definitely more suitable for authorization than groups.
>>         >>
>>         >>
>>         >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
>>         <psilva at redhat.com <mailto:psilva at redhat.com>> wrote:
>>         >>
>>         >>> Hi All,
>>         >>>
>>         >>> I'm adding a Group Based Policy to our set of supported
>>         policies.
>>         >>> Basically, this policy allows you to define the group(s)
>>         you want to
>>         >>> give access to some resource or scope.
>>         >>>
>>         >>> Would like to share my initial scope with you and see if
>>         you guys have
>>         >>> anything else to add:
>>         >>>
>>         >>> * Users can select one or more groups
>>         >>> * Users can define groups using paths (e.g.: /Group
>>         A/Group B/*,
>>         >>> /Group A, /Group A/Group B)
>>         >>> * Users can decide whether or not access is granted if
>>         the identity is
>>         >>> a member of all or any of the selected groups
>>         >>> * Users can decide whether or not access extends to
>>         sub-groups of a
>>         >>> parent group
>>         >>>
>>         >>> Please, let me know your thoughts.
>>         >>>
>>         >>> 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>
>>
>>         _______________________________________________
>>         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  Thu Jun  8 15:56:06 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Jun 2017 21:56:06 +0200
Subject: [keycloak-dev] Renaming testsuite/integration to
 testsuite/integration-deprecated
In-Reply-To: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
References: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
Message-ID: <8f837edd-6b07-6de2-2faf-bc1e75a7e23a@redhat.com>

+1

Bad thing is, that it;s likely not so trivial as it seems to be as we 
probably have lots of links in README files, lots of jenkins/ci jobs 
might be affected etc. But better do it now then never though :)

Marek

On 08/06/17 08:27, Stian Thorgersen wrote:
> I would like to rename testsuite/integration to
> testsuite/integration-deprecated. This is to make it clear to external
> contributors that the testsuite is deprecated and new tests should be added
> to testsuite/integration-arquillian.
>
> I would also like to rename testsuite/integration-arquillian
> to testsuite/integration.
> _______________________________________________
> 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 Jun  9 03:01:28 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 9 Jun 2017 07:01:28 +0000
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
Message-ID: <961902c3ed1b406e9b79a0e42963ffe9@FE-MBX1028.de.bosch.com>

If you do group-based policies, you will probably have to add group hierarchies as well, especially if data is coming from a company LDAP.
With lots of groups, managing authorization without some kind of composition mechanism becomes too tedious.

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 Pedro Igor Silva
> Sent: Donnerstag, 8. Juni 2017 16:55
> To: Bill Burke <bburke at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Group Based Policy
> 
> Yeah, that is what I also think. In any case, I'm going to implement a group policy
> as users may not want to assign roles to their groups every time they want a
> group-based access control mechanism associated with their permissions. You
> can do it that way, but in some cases (like the one you
> mentioned) it may be boring specially when groups come from LDAP without roles
> associated with them.
> 
> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> > Groups and roles can from a technological perspective be used for the
> > same purpose.  But in my mind, Groups are for organizing sets of
> > users.   Composite Roles are for managing a set of permissions often
> > defined by applications.
> >
> >
> > On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
> > > I agree 100% with your arguments against supporting group-based
> > policies. :) I guess people doing authorization based on groups are
> > essentially using roles, they are just calling them groups. Keycloak
> > can perfectly cover that case by using roles. The only potential
> > difference I see is when there is something like composite roles or composite
> groups.
> > With a composite role, you get all the subroles. With a composite
> > group, you are in all the parent groups. However, offering this
> > opposite direction (and adding composite groups) comes at the price of
> > making it even harder for people to decide what they should (and do it
> > correctly) so I don?t think it's really worth it.
> > > I do like the current RBAC way as it is a very clear concept. You
> > > can
> > still switch to ABAC if RBAC does not cover your case...
> > >
> > > 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 Pedro Igor Silva
> > >> Sent: Dienstag, 6. Juni 2017 21:19
> > >> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> > >> Subject: Re: [keycloak-dev] Group Based Policy
> > >>
> > >> Forgot to add something to the discussion.
> > >>
> > >> I'm not 100% sure if we should have a group policy though. Reason
> > >> being
> > that
> > >> groups are usually administrative things to group a set of one or
> > >> more
> > users and
> > >> usually they are not really suitable for authorization. For
> > >> instance,
> > with current
> > >> design you could enforce access based on groups as long as your
> > >> groups
> > have a
> > >> specific role which you can use in a role based policy. In this
> > >> sense,
> > roles are
> > >> definitely more suitable for authorization than groups.
> > >>
> > >>
> > >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
> > >> <psilva at redhat.com>
> > wrote:
> > >>
> > >>> Hi All,
> > >>>
> > >>> I'm adding a Group Based Policy to our set of supported policies.
> > >>> Basically, this policy allows you to define the group(s) you want
> > >>> to give access to some resource or scope.
> > >>>
> > >>> Would like to share my initial scope with you and see if you guys
> > >>> have anything else to add:
> > >>>
> > >>> * Users can select one or more groups
> > >>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
> > >>> /Group A, /Group A/Group B)
> > >>> * Users can decide whether or not access is granted if the
> > >>> identity is a member of all or any of the selected groups
> > >>> * Users can decide whether or not access extends to sub-groups of
> > >>> a parent group
> > >>>
> > >>> Please, let me know your thoughts.
> > >>>
> > >>> 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
> >
> > _______________________________________________
> > 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 ankitrgupta1 at gmail.com  Fri Jun  9 03:53:17 2017
From: ankitrgupta1 at gmail.com (Ankit Gupta)
Date: Fri, 9 Jun 2017 13:23:17 +0530
Subject: [keycloak-dev] SpringBoot multi-tenancy
In-Reply-To: <CA+vsKgapA92qupq=mPRLeFKvkEMquzYHmzueHdKgfp7_Fz=JNA@mail.gmail.com>
References: <CA+vsKgafUN1JjG6cTbBvwKkWT4F9hQbgJbad2rtQdgUCsbqjzQ@mail.gmail.com>
	<CA+vsKgY2OZXAJU2+fsuzqd7f7S3uJC7V5irqHjghJ2khx68-fA@mail.gmail.com>
	<CA+vsKgYi96NmhCZPJYUN0msXpJF0iA4qRFsTHY3b_npa7i_eTg@mail.gmail.com>
	<CA+vsKgYivAAmFHdG27ugaJ7-anN5dmKmAAyt1fi_D5vjtSp1XQ@mail.gmail.com>
	<CA+vsKgY=+GRX7aXg2F9-fx-7iSxLR2d-X3gTQRMdYjkMBQTkjA@mail.gmail.com>
	<CA+vsKgb1yA7evfXTaX3uAn6w9x4w9USuEPOU7rGy6C0se_SWdQ@mail.gmail.com>
	<CA+vsKgbsJZ8Py0K3sYOH-h5V1YFU9wTpPOu5uxgn83i3nykpRw@mail.gmail.com>
	<CA+vsKgapA92qupq=mPRLeFKvkEMquzYHmzueHdKgfp7_Fz=JNA@mail.gmail.com>
Message-ID: <CA+vsKgY2xqRt2+Nj5tsggfL3ZoZmpmKaCK0CXa1D_=BmHGU3pw@mail.gmail.com>

Hi Team,

Woukd it be possible for you guys to guide me on how to implement
Multi-tenant SSO in a spring boot application.

I had gone through the example of multi-tenancy in the github library, but
i am not sure how could I implement the similar feature for the SpringBoot
application.

Any help would be appreciated, as I am trying to weigh the keycloak for our
new application for the clients. As our application is going to SpringBoot
microservice based application, the feature of multi-tenancy is necessary
for us.


Awaiting for response.

Thanks & Regards,
Ankit Gupta

From bruno at abstractj.org  Fri Jun  9 04:57:23 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 9 Jun 2017 05:57:23 -0300
Subject: [keycloak-dev] Branches for Node.js modules
Message-ID: <20170609085723.GB23087@abstractj.org>

Good morning, I would like to propose the creation of 2 branches for
Node.js modules following the same approach from the quickstarts:

- latest: stable
- master: development

The initial motivation behind this, is to enable Travis to test these modules
against the latest change on Keycloak server.

Thoughts?

--

abstractj

From Sebastian.Schuster at bosch-si.com  Fri Jun  9 05:12:07 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 9 Jun 2017 09:12:07 +0000
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
Message-ID: <9051a50da1c642bfbe733e42cb5e07ef@FE-MBX1028.de.bosch.com>

I just saw hierarchical groups are already supported...just ignore me. :)

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 Pedro Igor Silva
> Sent: Donnerstag, 8. Juni 2017 16:55
> To: Bill Burke <bburke at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Group Based Policy
> 
> Yeah, that is what I also think. In any case, I'm going to implement a group policy
> as users may not want to assign roles to their groups every time they want a
> group-based access control mechanism associated with their permissions. You
> can do it that way, but in some cases (like the one you
> mentioned) it may be boring specially when groups come from LDAP without roles
> associated with them.
> 
> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> > Groups and roles can from a technological perspective be used for the
> > same purpose.  But in my mind, Groups are for organizing sets of
> > users.   Composite Roles are for managing a set of permissions often
> > defined by applications.
> >
> >
> > On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
> > > I agree 100% with your arguments against supporting group-based
> > policies. :) I guess people doing authorization based on groups are
> > essentially using roles, they are just calling them groups. Keycloak
> > can perfectly cover that case by using roles. The only potential
> > difference I see is when there is something like composite roles or composite
> groups.
> > With a composite role, you get all the subroles. With a composite
> > group, you are in all the parent groups. However, offering this
> > opposite direction (and adding composite groups) comes at the price of
> > making it even harder for people to decide what they should (and do it
> > correctly) so I don?t think it's really worth it.
> > > I do like the current RBAC way as it is a very clear concept. You
> > > can
> > still switch to ABAC if RBAC does not cover your case...
> > >
> > > 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 Pedro Igor Silva
> > >> Sent: Dienstag, 6. Juni 2017 21:19
> > >> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> > >> Subject: Re: [keycloak-dev] Group Based Policy
> > >>
> > >> Forgot to add something to the discussion.
> > >>
> > >> I'm not 100% sure if we should have a group policy though. Reason
> > >> being
> > that
> > >> groups are usually administrative things to group a set of one or
> > >> more
> > users and
> > >> usually they are not really suitable for authorization. For
> > >> instance,
> > with current
> > >> design you could enforce access based on groups as long as your
> > >> groups
> > have a
> > >> specific role which you can use in a role based policy. In this
> > >> sense,
> > roles are
> > >> definitely more suitable for authorization than groups.
> > >>
> > >>
> > >> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
> > >> <psilva at redhat.com>
> > wrote:
> > >>
> > >>> Hi All,
> > >>>
> > >>> I'm adding a Group Based Policy to our set of supported policies.
> > >>> Basically, this policy allows you to define the group(s) you want
> > >>> to give access to some resource or scope.
> > >>>
> > >>> Would like to share my initial scope with you and see if you guys
> > >>> have anything else to add:
> > >>>
> > >>> * Users can select one or more groups
> > >>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
> > >>> /Group A, /Group A/Group B)
> > >>> * Users can decide whether or not access is granted if the
> > >>> identity is a member of all or any of the selected groups
> > >>> * Users can decide whether or not access extends to sub-groups of
> > >>> a parent group
> > >>>
> > >>> Please, let me know your thoughts.
> > >>>
> > >>> 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
> >
> > _______________________________________________
> > 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 Jun  9 05:49:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 9 Jun 2017 11:49:35 +0200
Subject: [keycloak-dev] Add support for creating user with credentials in
	admin endpoints
Message-ID: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>

Currently the admin endpoints ignores credentials when creating the user
and a second post is needed to add credentials.

I don't see any reason why it has to be this way and we should be able to
change it?

We already have a PR for it https://issues.jboss.org/browse/KEYCLOAK-5026.

From bartosz at redhat.com  Fri Jun  9 06:08:56 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Fri, 9 Jun 2017 12:08:56 +0200
Subject: [keycloak-dev] Htmlunit vs PhantomJS vs Chrome
In-Reply-To: <CAJgngAesiL4fZxzEc5dRp7wXYeySbmvRNGd5MiDxmWuitfr=bw@mail.gmail.com>
References: <CAJgngAe9wib1TH+t05+CPFD=rbvYysAP4wZWRuFtGjowbw4phQ@mail.gmail.com>
	<a575eea0-e030-5c0f-96b6-0c8e4a5ba5f3@redhat.com>
	<CAMQSZyg2r3fah-EpkYfB+uZPFEnDe5dwXrZZsBcFWH-2p7sw9g@mail.gmail.com>
	<e50e23a3-b0ea-560b-bfd5-20a32f932922@redhat.com>
	<CAJgngAesiL4fZxzEc5dRp7wXYeySbmvRNGd5MiDxmWuitfr=bw@mail.gmail.com>
Message-ID: <CA+C8PfyNPXEQAN+v1ZkY4YQt5tdAqaa9vnz2jA2zuwbo5SoiRg@mail.gmail.com>

Have you guys looked at Drone lately? There is a bunch of features you
might like, such as an automatic download of drivers [1] and defining
target browser through a simple property. As for headless chrome, we are
almost there [2]

HTH
Bartosz

[1] http://arquillian.org/arquillian-extension-drone/#_automatic_download
[2] https://github.com/arquillian/arquillian-extension-drone/pull/92

On Thu, Jun 8, 2017 at 2:58 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Ok, so default browser will 99.999% remain htmlunit. That means we do need
> an option to specify two browsers. First browser defaults to htmlunit,
> second browser needs to default to something that works well with JS
> testing. The second browser could default to Chrome headless, but would  be
> possible to disable and in that case those particular tests wouldn't run. I
> just don't think it's going to be feasible to get all tests to run on
> htmlunit. Feel free to correct me if I'm wrong on the latter part and it is
> indeed possible to test everything with htmlunit.
>
> On 8 June 2017 at 10:27, Marek Posolda <mposolda at redhat.com> wrote:
>
> > From what I see, there is no support for other protocol besides HTTP. All
> > the WebDriver implementations despite HtmlUnit extends from
> > RemoteWebDriver, which uses the CommandExecutor interface for communicate
> > with the server. In theory, the CommandExecutor implementation is
> > pluggable, but in reality, all the implementations uses HTTP based
> command
> > executor, which uses Apache HTTP Client under the covers to communicate
> > with the selenium server and they don't provide straightforward way to
> use
> > something different.
> >
> > Not sure if there is some performance improvement in newest version? We
> > use the WebDriver version, which uses selenium 2.53.0. Now there is
> already
> > version 3 available.
> >
> > Marek
> >
> >
> > On 08/06/17 09:20, Vaclav Muzikar wrote:
> >
> > I agree with Marek - I don't think it would do any good for us as the
> > default browser.
> > Imho the new headless mode doesn't make a much difference for us - the
> > Chrome would be working on the same principle as before (through
> > ChromeDriver).
> > Moreover, Chrome and ChromeDriver would need to be downloaded/installed
> > from external sources - yet, this could be perhaps solvable with Maven
> (at
> > least ChromeDriver as it's in the Maven repo).
> >
> > On Wed, Jun 7, 2017 at 9:53 PM, Marek Posolda <mposolda at redhat.com>
> wrote:
> >
> >> Just a note, the main reason why htmlUnit web driver is so faster than
> >> other browsers is, that it is fully embedded in the same JVM like tests.
> >> There is no additional overhead in the communication with other
> >> processes. The only exception are the HTTP requests for the
> >> communication with the tested Keycloak server and adapters.
> >>
> >> On the other hand, the other web driver implementations, including
> >> phantomJS, are using external process and there is remote selenium
> >> server with which the webDriver needs to communicate. It means that all
> >> the webDriver calls including the most simple (like driver.getTitle() )
> >> need to send additional HTTP request to the remote selenium server under
> >> the covers. All of this adds an additional overhead.
> >>
> >> I suspect that headless chrome will also use remote selenium, hence I
> >> don't expect that performance will be much better comparing to
> >> phantomJS. But maybe I am wrong..
> >>
> >> Marek
> >>
> >> On 07/06/17 12:14, Stian Thorgersen wrote:
> >> > We've picked Htmlunit as the default browser to run tests with due to
> it
> >> > being the fastest. Downside is that it simply doesn't work very well
> for
> >> > all tests, especially those heavy on the javascript side of things
> like
> >> > testing the JavaScript adapter and admin console.
> >> >
> >> > Just saw that Chrome is actually bringing a headless option to Chrome
> 59
> >> > [1]. This is really nice as it allows headless testing with a real
> >> browser,
> >> > not just an emulated browser.
> >> >
> >> > Ideally if this is fast we could use it as the default browser instead
> >> of
> >> > htmlunit. Obviously waiting until it's released on all platforms. If
> >> it's
> >> > not as fast as htmlunit then maybe there is a compromise.
> >> >
> >> > The default browser would still be htmlunit. Then individual tests
> >> could be
> >> > marked (with an annotation on the class or on the WebDriver field).
> >> Those
> >> > marked would use Chrome in headless mode instead of htmlunit.
> Obviously
> >> > -Dbrowser would continue to override the browser in either case.
> >> >
> >> > Thoughts? Anyone interested in giving the new headless Chrome option a
> >> spin
> >> > and evaluating how fast it is compared to htmlunit?
> >> >
> >> > [1] https://developers.google.com/web/updates/2017/04/headless-chrome
> >> > _______________________________________________
> >> > 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
> >>
> >
> >
> >
> > --
> > 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 bartosz at redhat.com  Fri Jun  9 06:12:26 2017
From: bartosz at redhat.com (Bartosz Majsak)
Date: Fri, 9 Jun 2017 12:12:26 +0200
Subject: [keycloak-dev] arquillian testsuite still eating exceptions
In-Reply-To: <c686b9a7-2648-5874-9897-8deb26b937e6@redhat.com>
References: <28785f1d-538a-fba9-0143-429fe291b65c@redhat.com>
	<c686b9a7-2648-5874-9897-8deb26b937e6@redhat.com>
Message-ID: <CA+C8Pfwo61jOtks7CRfVMfg5JHF0rzJmNWxPbxZiLydVFa2QpQ@mail.gmail.com>

Can you point me to the exact test which is failing for you? I can have a
look if that's something on Arquillian side.

Cheers,
Bartosz

On Sun, Jun 4, 2017 at 4:09 AM, Bill Burke <bburke at redhat.com> wrote:

> I guess i should just read the docs?
>
>
> On 6/3/17 10:22 AM, Bill Burke wrote:
> > I'm getting an error during
> > AbstractKeycloakTest.afterAbstractKeycloakTest() when cleanup is
> > executed.  The problem is that the log only shows NullPointerException
> > with no stack trace.  Even worse, the failure only occurs during a full
> > maven build.  I can't duplicate the problem in IDE.  Why does arquillian
> > not display stack traces?
> >
> >
> > _______________________________________________
> > 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 Jun  9 10:39:56 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 9 Jun 2017 10:39:56 -0400
Subject: [keycloak-dev] arquillian testsuite still eating exceptions
In-Reply-To: <CA+C8Pfwo61jOtks7CRfVMfg5JHF0rzJmNWxPbxZiLydVFa2QpQ@mail.gmail.com>
References: <28785f1d-538a-fba9-0143-429fe291b65c@redhat.com>
	<c686b9a7-2648-5874-9897-8deb26b937e6@redhat.com>
	<CA+C8Pfwo61jOtks7CRfVMfg5JHF0rzJmNWxPbxZiLydVFa2QpQ@mail.gmail.com>
Message-ID: <9d18d50e-641c-962e-e19f-84dba4f3e3af@redhat.com>

There's some race condition in 
AbstractKeycloakTest.afterAbstractKeycloakTest(). With debug logging 
turned off I was getting a NPE during cleanup with no stack trace in 
log.  With logging turned on, there were no failures.  I can't give you 
any more info because I couldn't generate a stack trace.


On 6/9/17 6:12 AM, Bartosz Majsak wrote:
> Can you point me to the exact test which is failing for you? I can 
> have a look if that's something on Arquillian side.
>
> Cheers,
> Bartosz
>
> On Sun, Jun 4, 2017 at 4:09 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I guess i should just read the docs?
>
>
>     On 6/3/17 10:22 AM, Bill Burke wrote:
>     > I'm getting an error during
>     > AbstractKeycloakTest.afterAbstractKeycloakTest() when cleanup is
>     > executed.  The problem is that the log only shows
>     NullPointerException
>     > with no stack trace.  Even worse, the failure only occurs during
>     a full
>     > maven build.  I can't duplicate the problem in IDE.  Why does
>     arquillian
>     > not display stack traces?
>     >
>     >
>     > _______________________________________________
>     > 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  Fri Jun  9 13:55:10 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 09 Jun 2017 17:55:10 +0000
Subject: [keycloak-dev] Add support for creating user with credentials
 in admin endpoints
In-Reply-To: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
References: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
Message-ID: <CAMZCGg_9AsbqJRQDatz_oUe6zHOX4fHyxGyeLY-pyo4Y2ZhpCg@mail.gmail.com>

+1
That will solve 80% of the admin REST related questions on the mailing list
Le ven. 9 juin 2017 ? 19:06, Stian Thorgersen <sthorger at redhat.com> a
?crit :

> Currently the admin endpoints ignores credentials when creating the user
> and a second post is needed to add credentials.
>
> I don't see any reason why it has to be this way and we should be able to
> change it?
>
> We already have a PR for it https://issues.jboss.org/browse/KEYCLOAK-5026.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Fri Jun  9 16:28:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 9 Jun 2017 16:28:49 -0400
Subject: [keycloak-dev] Add support for creating user with credentials
 in admin endpoints
In-Reply-To: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
References: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
Message-ID: <eaa7134a-5332-c1d5-0afa-0273cf43e1ab@redhat.com>

credentials is somethign that is supposed to be set by the user.


On 6/9/17 5:49 AM, Stian Thorgersen wrote:
> Currently the admin endpoints ignores credentials when creating the user
> and a second post is needed to add credentials.
>
> I don't see any reason why it has to be this way and we should be able to
> change it?
>
> We already have a PR for it https://issues.jboss.org/browse/KEYCLOAK-5026.
> _______________________________________________
> 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  Fri Jun  9 21:33:54 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Sat, 10 Jun 2017 01:33:54 +0000
Subject: [keycloak-dev] Add support for creating user with credentials
 in admin endpoints
In-Reply-To: <CAMZCGg_9AsbqJRQDatz_oUe6zHOX4fHyxGyeLY-pyo4Y2ZhpCg@mail.gmail.com>
References: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
	<CAMZCGg_9AsbqJRQDatz_oUe6zHOX4fHyxGyeLY-pyo4Y2ZhpCg@mail.gmail.com>
Message-ID: <CAOqetn9gGMVYt-d5ZjhJV-daiz2vJUz5mosd+R+fc6i0OEkQ5Q@mail.gmail.com>

We had a similar need internally, to be able to create
FederatedIdentityLinks for a user upon creation (assuming the IDP exists
already).  We were able to work around it with an event listener, but I'm
wondering if more cases should be handled in create user?

On Fri, Jun 9, 2017 at 9:31 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> +1
> That will solve 80% of the admin REST related questions on the mailing list
> Le ven. 9 juin 2017 ? 19:06, Stian Thorgersen <sthorger at redhat.com> a
> ?crit :
>
> > Currently the admin endpoints ignores credentials when creating the user
> > and a second post is needed to add credentials.
> >
> > I don't see any reason why it has to be this way and we should be able to
> > change it?
> >
> > We already have a PR for it
> https://issues.jboss.org/browse/KEYCLOAK-5026.
> > _______________________________________________
> > 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  Sat Jun 10 16:30:03 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 10 Jun 2017 16:30:03 -0400
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <9051a50da1c642bfbe733e42cb5e07ef@FE-MBX1028.de.bosch.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
	<9051a50da1c642bfbe733e42cb5e07ef@FE-MBX1028.de.bosch.com>
Message-ID: <53285b35-ba18-fd83-7f6f-a6a0878f3227@redhat.com>

We did ;-p


On 6/9/17 5:12 AM, Schuster Sebastian (INST/ESY1) wrote:
> I just saw hierarchical groups are already supported...just ignore me. :)
>
> 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 Pedro Igor Silva
>> Sent: Donnerstag, 8. Juni 2017 16:55
>> To: Bill Burke <bburke at redhat.com>
>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Group Based Policy
>>
>> Yeah, that is what I also think. In any case, I'm going to implement a group policy
>> as users may not want to assign roles to their groups every time they want a
>> group-based access control mechanism associated with their permissions. You
>> can do it that way, but in some cases (like the one you
>> mentioned) it may be boring specially when groups come from LDAP without roles
>> associated with them.
>>
>> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Groups and roles can from a technological perspective be used for the
>>> same purpose.  But in my mind, Groups are for organizing sets of
>>> users.   Composite Roles are for managing a set of permissions often
>>> defined by applications.
>>>
>>>
>>> On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
>>>> I agree 100% with your arguments against supporting group-based
>>> policies. :) I guess people doing authorization based on groups are
>>> essentially using roles, they are just calling them groups. Keycloak
>>> can perfectly cover that case by using roles. The only potential
>>> difference I see is when there is something like composite roles or composite
>> groups.
>>> With a composite role, you get all the subroles. With a composite
>>> group, you are in all the parent groups. However, offering this
>>> opposite direction (and adding composite groups) comes at the price of
>>> making it even harder for people to decide what they should (and do it
>>> correctly) so I don?t think it's really worth it.
>>>> I do like the current RBAC way as it is a very clear concept. You
>>>> can
>>> still switch to ABAC if RBAC does not cover your case...
>>>> 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 Pedro Igor Silva
>>>>> Sent: Dienstag, 6. Juni 2017 21:19
>>>>> To: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>>> Subject: Re: [keycloak-dev] Group Based Policy
>>>>>
>>>>> Forgot to add something to the discussion.
>>>>>
>>>>> I'm not 100% sure if we should have a group policy though. Reason
>>>>> being
>>> that
>>>>> groups are usually administrative things to group a set of one or
>>>>> more
>>> users and
>>>>> usually they are not really suitable for authorization. For
>>>>> instance,
>>> with current
>>>>> design you could enforce access based on groups as long as your
>>>>> groups
>>> have a
>>>>> specific role which you can use in a role based policy. In this
>>>>> sense,
>>> roles are
>>>>> definitely more suitable for authorization than groups.
>>>>>
>>>>>
>>>>> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
>>>>> <psilva at redhat.com>
>>> wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I'm adding a Group Based Policy to our set of supported policies.
>>>>>> Basically, this policy allows you to define the group(s) you want
>>>>>> to give access to some resource or scope.
>>>>>>
>>>>>> Would like to share my initial scope with you and see if you guys
>>>>>> have anything else to add:
>>>>>>
>>>>>> * Users can select one or more groups
>>>>>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
>>>>>> /Group A, /Group A/Group B)
>>>>>> * Users can decide whether or not access is granted if the
>>>>>> identity is a member of all or any of the selected groups
>>>>>> * Users can decide whether or not access extends to sub-groups of
>>>>>> a parent group
>>>>>>
>>>>>> Please, let me know your thoughts.
>>>>>>
>>>>>> 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
>>> _______________________________________________
>>> 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 Jun 12 03:05:28 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jun 2017 09:05:28 +0200
Subject: [keycloak-dev] Add support for creating user with credentials
 in admin endpoints
In-Reply-To: <eaa7134a-5332-c1d5-0afa-0273cf43e1ab@redhat.com>
References: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
	<eaa7134a-5332-c1d5-0afa-0273cf43e1ab@redhat.com>
Message-ID: <CAJgngAcpKvfUn15JjDJv2YVronUM_rBgo5we=Kg3_fx2XOu63Q@mail.gmail.com>

Not always. What about for instance the case when folks are importing a
bunch of users and have a dB filled with hashed passwords.

On 10 Jun 2017 6:09 am, "Bill Burke" <bburke at redhat.com> wrote:

> credentials is somethign that is supposed to be set by the user.
>
>
> On 6/9/17 5:49 AM, Stian Thorgersen wrote:
> > Currently the admin endpoints ignores credentials when creating the user
> > and a second post is needed to add credentials.
> >
> > I don't see any reason why it has to be this way and we should be able to
> > change it?
> >
> > We already have a PR for it https://issues.jboss.org/
> browse/KEYCLOAK-5026.
> > _______________________________________________
> > 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 Jun 12 03:08:58 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jun 2017 09:08:58 +0200
Subject: [keycloak-dev] Branches for Node.js modules
In-Reply-To: <20170609085723.GB23087@abstractj.org>
References: <20170609085723.GB23087@abstractj.org>
Message-ID: <CAJgngAdYtd-uSFsx+4qTZQUMCNb=QYORvn2st9jKxgBKdaYjiA@mail.gmail.com>

This doesn't make sense to me. Can you elaborate a bit more? The reason it
makes sense to have two branches for quickstarts is that one branch is Dev
and the other is the latest release. For node.js I can't see that being the
case as there's "proper" releases and tags and such stuff

On 9 Jun 2017 6:25 pm, "Bruno Oliveira" <bruno at abstractj.org> wrote:

Good morning, I would like to propose the creation of 2 branches for
Node.js modules following the same approach from the quickstarts:

- latest: stable
- master: development

The initial motivation behind this, is to enable Travis to test these
modules
against the latest change on Keycloak server.

Thoughts?

--

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

From bruno at abstractj.org  Mon Jun 12 05:18:33 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 12 Jun 2017 06:18:33 -0300
Subject: [keycloak-dev] Branches for Node.js modules
In-Reply-To: <CAJgngAdYtd-uSFsx+4qTZQUMCNb=QYORvn2st9jKxgBKdaYjiA@mail.gmail.com>
References: <20170609085723.GB23087@abstractj.org>
	<CAJgngAdYtd-uSFsx+4qTZQUMCNb=QYORvn2st9jKxgBKdaYjiA@mail.gmail.com>
Message-ID: <20170612091833.GA4261@abstractj.org>

Sure. We actually have this issue: https://issues.jboss.org/browse/KEYCLOAK-4985.
Which we could catch earlier, if we had the CI running tests against
the changes on Keycloak repo.

So the idea is pretty much it:

- latest: test the latest released version of Node.js adapter, against
  the latest stable version of the Keycloak server (we already do this).

- master: test the latest changes from the Node.js adapter, against the
  latest changes on Keycloak server.

Another alternative, if you don't like this idea, is to have a build matrix
on Travis. The same idea from keycloak server tests. Or we can do nothing.

The solo porpuse of this change is to guarantee that we catch issues
like this earlier.


On 2017-06-12, Stian Thorgersen wrote:
> This doesn't make sense to me. Can you elaborate a bit more? The reason it
> makes sense to have two branches for quickstarts is that one branch is Dev
> and the other is the latest release. For node.js I can't see that being the
> case as there's "proper" releases and tags and such stuff
>
> On 9 Jun 2017 6:25 pm, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>
> Good morning, I would like to propose the creation of 2 branches for
> Node.js modules following the same approach from the quickstarts:
>
> - latest: stable
> - master: development
>
> The initial motivation behind this, is to enable Travis to test these
> modules
> against the latest change on Keycloak server.
>
> Thoughts?
>
> --
>
> 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  Mon Jun 12 07:50:13 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Jun 2017 07:50:13 -0400
Subject: [keycloak-dev] Add support for creating user with credentials
 in admin endpoints
In-Reply-To: <CAJgngAcpKvfUn15JjDJv2YVronUM_rBgo5we=Kg3_fx2XOu63Q@mail.gmail.com>
References: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
	<eaa7134a-5332-c1d5-0afa-0273cf43e1ab@redhat.com>
	<CAJgngAcpKvfUn15JjDJv2YVronUM_rBgo5we=Kg3_fx2XOu63Q@mail.gmail.com>
Message-ID: <1b213589-e2ab-f00d-da20-20f02c2d5eaf@redhat.com>

don't we already support this via import?


On 6/12/17 3:05 AM, Stian Thorgersen wrote:
> Not always. What about for instance the case when folks are importing 
> a bunch of users and have a dB filled with hashed passwords.
>
> On 10 Jun 2017 6:09 am, "Bill Burke" <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     credentials is somethign that is supposed to be set by the user.
>
>
>     On 6/9/17 5:49 AM, Stian Thorgersen wrote:
>     > Currently the admin endpoints ignores credentials when creating
>     the user
>     > and a second post is needed to add credentials.
>     >
>     > I don't see any reason why it has to be this way and we should
>     be able to
>     > change it?
>     >
>     > We already have a PR for it
>     https://issues.jboss.org/browse/KEYCLOAK-5026
>     <https://issues.jboss.org/browse/KEYCLOAK-5026>.
>     > _______________________________________________
>     > 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 jairohenaorojas at gmail.com  Tue Jun 13 09:56:59 2017
From: jairohenaorojas at gmail.com (Jairo Henao)
Date: Tue, 13 Jun 2017 08:56:59 -0500
Subject: [keycloak-dev] How to do my pull request successfully
Message-ID: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>

Hello comunity,

I am trying to understand the process to contribute to the project. A few
days ago I did my first pull request but some errors occurred while running
the tests. I do not understand the error very well, what is the process
here ?, Where can I find more information ?, This is the channel where I
should ask about this?

https://github.com/keycloak/keycloak/pull/4219


Thanks

From bruno at abstractj.org  Tue Jun 13 10:13:03 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 13 Jun 2017 14:13:03 +0000
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
Message-ID: <CAM5SUC5Evn0Cn+xZqLY3aqwzZ_dNr96DtB340u8MyH8ipLiXGA@mail.gmail.com>

https://github.com/keycloak/keycloak#contributing

On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <jairohenaorojas at gmail.com>
wrote:

> Hello comunity,
>
> I am trying to understand the process to contribute to the project. A few
> days ago I did my first pull request but some errors occurred while running
> the tests. I do not understand the error very well, what is the process
> here ?, Where can I find more information ?, This is the channel where I
> should ask about this?
>
> https://github.com/keycloak/keycloak/pull/4219
>
>
> Thanks
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From jairohenaorojas at gmail.com  Tue Jun 13 11:27:59 2017
From: jairohenaorojas at gmail.com (Jairo Henao)
Date: Tue, 13 Jun 2017 10:27:59 -0500
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAM5SUC5Evn0Cn+xZqLY3aqwzZ_dNr96DtB340u8MyH8ipLiXGA@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
	<CAM5SUC5Evn0Cn+xZqLY3aqwzZ_dNr96DtB340u8MyH8ipLiXGA@mail.gmail.com>
Message-ID: <CAG3VLqCxf8kh3pEvaua7igHzMoSZqs8L=NSoOwczKRbpbmoA8g@mail.gmail.com>

Thanks, I have already seen the link  but can not find information:

The only thing I can extract from the test log is this:










*21:47:48,254 INFO  [KeycloakOnUndertow] Stopping auth server.Results
:Failed tests:
BruteForceTest.testGrantInvalidOtp:197->assertTokenNull:215 expected null,
but
was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg2R2NGM2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.eyJqdGkiOiI5M2I2NDI1MC04MjYxLTRmOTUtOTY3ZS05ZDRiOTAwYTA1M2YiLCJleHAiOjE0OTcwNDQ5MDcsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjA3LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIsImF1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFmZWMtZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1hcHAiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiI3YzI5M2ZhMC1iYzkxLTRjNjQtYWM1MS1lZWEyYTY1M2I2MjAiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InRlc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0IiwiZ2l2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFpbCI6InRlc3QtdXNlckBsb2NhbGhvc3QifQ.cGA5MmxrvKW_O7B100jotT4f4jb9ctOBizuGyINor579NRWUAutllM9OGEniPtDedZ1_m_IGmbXteiixhg--SG0dDHTec8CYxQZrtC2TjDBzdxkWYj3iHL0Yj-1wcZZEaGb3809ol94oVrjOXcbcpjU-wAmQtK4RhRyoy-a3O-E>
BruteForceTest.testGrantMissingOtp:246->assertTokenNull:215 expected null,
but
was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg2R2NGM2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.eyJqdGkiOiJiNGE1NjY3YS04ZjhlLTQ1YjctYTYzMy01ZDdhNzczMzlkNmEiLCJleHAiOjE0OTcwNDQ5MjIsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjIyLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIsImF1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFmZWMtZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1hcHAiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJlZDg2YWI5Ni1mMDk1LTQwNTItODExYS0wNzNjNjY5ZjBiYjIiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InRlc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0IiwiZ2l2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFpbCI6InRlc3QtdXNlckBsb2NhbGhvc3QifQ.iXHI9NkRM8CaVX_iqIlAXcQGBhg-TH27F58C4XEDgCc_QawXKJ1GZ0qauVTnoS2mJB8ecW74V9HFpo-O0GVt4DyQzEw8dk0UUZtpsKrwLYk-IO0N6sitxJLr_wTjUTtcYJttOSnecuPB5XsxeSK6Lio4eNVarGRO00hNg7h3w1Y>Tests
run: 191, Failures: 2, Errors: 0, Skipped: 2*



On Tue, Jun 13, 2017 at 9:13 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> https://github.com/keycloak/keycloak#contributing
>
> On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <jairohenaorojas at gmail.com>
> wrote:
>
>> Hello comunity,
>>
>> I am trying to understand the process to contribute to the project. A few
>> days ago I did my first pull request but some errors occurred while
>> running
>> the tests. I do not understand the error very well, what is the process
>> here ?, Where can I find more information ?, This is the channel where I
>> should ask about this?
>>
>> https://github.com/keycloak/keycloak/pull/4219
>>
>>
>> Thanks
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


--

From psilva at redhat.com  Tue Jun 13 18:12:56 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 13 Jun 2017 19:12:56 -0300
Subject: [keycloak-dev] Group Based Policy
In-Reply-To: <53285b35-ba18-fd83-7f6f-a6a0878f3227@redhat.com>
References: <CAJrcDBfOb7yjisLz+mzEZsHBi4VDO+VwF9UPS6DyWQhq_GS5yA@mail.gmail.com>
	<CAJrcDBeaWhZvuRbOe3UXHQwrmN_C9rpB-pJc7QgaweYXk3=NWA@mail.gmail.com>
	<aab9a207dca445a7aedadab5aa0bacd7@FE-MBX1028.de.bosch.com>
	<b170e715-7333-2dc9-d526-d69159885565@redhat.com>
	<CAJrcDBfByp-YPVASVjRBdjDn6MY98kKDXQyHUgBRkTrC-91fnw@mail.gmail.com>
	<9051a50da1c642bfbe733e42cb5e07ef@FE-MBX1028.de.bosch.com>
	<53285b35-ba18-fd83-7f6f-a6a0878f3227@redhat.com>
Message-ID: <CAJrcDBc7GmC3zhe=6AdvL2VF3dBS1V23pWCiRS0fT_sHmZGCng@mail.gmail.com>

I've sent a PR [1] with the GBAC policy. Basically, it supports:

* Defining a claim from where groups are obtained. We do support hierarchy
checks but the claim must hold the paths and not only their name. In case
the claim only maps to group names, we do an exact match
* Select a group using the group tree as it stands today in the group list
page
* Define if access to a selected/allowed group also extends to children

Please let me know if you want to add/change something else. There are
tests for this new policy in case you want to check how it can be used.

[1] https://github.com/keycloak/keycloak/pull/4224

Regards.
Pedro Igor

On Sat, Jun 10, 2017 at 5:30 PM, Bill Burke <bburke at redhat.com> wrote:

> We did ;-p
>
>
>
> On 6/9/17 5:12 AM, Schuster Sebastian (INST/ESY1) wrote:
>
>> I just saw hierarchical groups are already supported...just ignore me. :)
>>
>> 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 Pedro Igor Silva
>>> Sent: Donnerstag, 8. Juni 2017 16:55
>>> To: Bill Burke <bburke at redhat.com>
>>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Group Based Policy
>>>
>>> Yeah, that is what I also think. In any case, I'm going to implement a
>>> group policy
>>> as users may not want to assign roles to their groups every time they
>>> want a
>>> group-based access control mechanism associated with their permissions.
>>> You
>>> can do it that way, but in some cases (like the one you
>>> mentioned) it may be boring specially when groups come from LDAP without
>>> roles
>>> associated with them.
>>>
>>> On Wed, Jun 7, 2017 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:
>>>
>>> Groups and roles can from a technological perspective be used for the
>>>> same purpose.  But in my mind, Groups are for organizing sets of
>>>> users.   Composite Roles are for managing a set of permissions often
>>>> defined by applications.
>>>>
>>>>
>>>> On 6/7/17 3:00 AM, Schuster Sebastian (INST/ESY1) wrote:
>>>>
>>>>> I agree 100% with your arguments against supporting group-based
>>>>>
>>>> policies. :) I guess people doing authorization based on groups are
>>>> essentially using roles, they are just calling them groups. Keycloak
>>>> can perfectly cover that case by using roles. The only potential
>>>> difference I see is when there is something like composite roles or
>>>> composite
>>>>
>>> groups.
>>>
>>>> With a composite role, you get all the subroles. With a composite
>>>> group, you are in all the parent groups. However, offering this
>>>> opposite direction (and adding composite groups) comes at the price of
>>>> making it even harder for people to decide what they should (and do it
>>>> correctly) so I don?t think it's really worth it.
>>>>
>>>>> I do like the current RBAC way as it is a very clear concept. You
>>>>> can
>>>>>
>>>> still switch to ABAC if RBAC does not cover your case...
>>>>
>>>>> 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 Pedro Igor Silva
>>>>>> Sent: Dienstag, 6. Juni 2017 21:19
>>>>>> To: keycloak-dev <keycloak-dev at lists.jboss.org>
>>>>>> Subject: Re: [keycloak-dev] Group Based Policy
>>>>>>
>>>>>> Forgot to add something to the discussion.
>>>>>>
>>>>>> I'm not 100% sure if we should have a group policy though. Reason
>>>>>> being
>>>>>>
>>>>> that
>>>>
>>>>> groups are usually administrative things to group a set of one or
>>>>>> more
>>>>>>
>>>>> users and
>>>>
>>>>> usually they are not really suitable for authorization. For
>>>>>> instance,
>>>>>>
>>>>> with current
>>>>
>>>>> design you could enforce access based on groups as long as your
>>>>>> groups
>>>>>>
>>>>> have a
>>>>
>>>>> specific role which you can use in a role based policy. In this
>>>>>> sense,
>>>>>>
>>>>> roles are
>>>>
>>>>> definitely more suitable for authorization than groups.
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 6, 2017 at 3:37 PM, Pedro Igor Silva
>>>>>> <psilva at redhat.com>
>>>>>>
>>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>>>
>>>>>>> I'm adding a Group Based Policy to our set of supported policies.
>>>>>>> Basically, this policy allows you to define the group(s) you want
>>>>>>> to give access to some resource or scope.
>>>>>>>
>>>>>>> Would like to share my initial scope with you and see if you guys
>>>>>>> have anything else to add:
>>>>>>>
>>>>>>> * Users can select one or more groups
>>>>>>> * Users can define groups using paths (e.g.: /Group A/Group B/*,
>>>>>>> /Group A, /Group A/Group B)
>>>>>>> * Users can decide whether or not access is granted if the
>>>>>>> identity is a member of all or any of the selected groups
>>>>>>> * Users can decide whether or not access extends to sub-groups of
>>>>>>> a parent group
>>>>>>>
>>>>>>> Please, let me know your thoughts.
>>>>>>>
>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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  Wed Jun 14 08:50:05 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 14 Jun 2017 09:50:05 -0300
Subject: [keycloak-dev] UMA 2.0
Message-ID: <CAJrcDBeshp=CeFwY_hbKZwvkLt8w+EBE8OHMLtB4p8Q24XWGPQ@mail.gmail.com>

Hi,

I would like to review our UMA implementation (which is based on v1), and
get it aligned with the new version, v2.

One of the main changes we need is that now UMA has a specific grant type
that should be used by clients to obtain RPTs. The Authorization API no
longer exists.

Other changes are basically related with parts of the specs we are missing
that don't really bring issues for people already using UMA in Keycloak.
But new features and better UMA support.

My question is if it is reasonable to have those changes in 3.2.0.CR1 and
how ? For instance, if we decide to have those changes in, specially the
new UMA grant type, should we keep/deprecate the legacy Authorization API
for backward compatibility or just remove it from AuthZ REST API ?

Regards.
Pedro Igor

From sthorger at redhat.com  Wed Jun 14 10:36:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jun 2017 16:36:29 +0200
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAG3VLqCxf8kh3pEvaua7igHzMoSZqs8L=NSoOwczKRbpbmoA8g@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
	<CAM5SUC5Evn0Cn+xZqLY3aqwzZ_dNr96DtB340u8MyH8ipLiXGA@mail.gmail.com>
	<CAG3VLqCxf8kh3pEvaua7igHzMoSZqs8L=NSoOwczKRbpbmoA8g@mail.gmail.com>
Message-ID: <CAJgngAfYSGy7SuVT0uEWFAKd5K7OhG-YPNmttQc+oZKDUah9hA@mail.gmail.com>

Most likely you didn't break the test. We have a couple tests at the moment
that are unstable and fail intermittently. See
https://issues.jboss.org/browse/KEYCLOAK-5020.

I've restarted the test for your PR.

On 13 June 2017 at 17:27, Jairo Henao <jairohenaorojas at gmail.com> wrote:

> Thanks, I have already seen the link  but can not find information:
>
> The only thing I can extract from the test log is this:
>
>
>
>
>
>
>
>
>
>
> *21:47:48,254 INFO  [KeycloakOnUndertow] Stopping auth server.Results
> :Failed tests:
> BruteForceTest.testGrantInvalidOtp:197->assertTokenNull:215 expected null,
> but
> was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg2R2NG
> M2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.
> eyJqdGkiOiI5M2I2NDI1MC04MjYxLTRmOTUtOTY3ZS05ZDRiOTAwYTA1M2Yi
> LCJleHAiOjE0OTcwNDQ5MDcsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjA3LCJp
> c3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIs
> ImF1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFm
> ZWMtZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1h
> cHAiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiI3YzI5M2ZhMC1i
> YzkxLTRjNjQtYWM1MS1lZWEyYTY1M2I2MjAiLCJhY3IiOiIxIiwiYWxsb3dl
> ZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9h
> Y2Nlc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7
> InRlc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291
> bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3Vu
> dC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHki
> LCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0Iiwi
> Z2l2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFp
> bCI6InRlc3QtdXNlckBsb2NhbGhvc3Qi!
>  fQ.cGA5MmxrvKW_O7B100jotT4f4jb9ctOBizuGyINor579NRWUAutllM9OGEniPtDedZ1_m_
> IGmbXteiixhg--SG0dDHTec8CYxQZrtC2TjDBzdxkWYj3iHL0Yj-
> 1wcZZEaGb3809ol94oVrjOXcbcpjU-wAmQtK4RhRyoy-a3O-E>
> BruteForceTest.testGrantMissingOtp:246->assertTokenNull:215 expected null,
> but
> was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg2R2NG
> M2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.
> eyJqdGkiOiJiNGE1NjY3YS04ZjhlLTQ1YjctYTYzMy01ZDdhNzczMzlkNmEi
> LCJleHAiOjE0OTcwNDQ5MjIsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjIyLCJp
> c3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIs
> ImF1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFm
> ZWMtZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1h
> cHAiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJlZDg2YWI5Ni1m
> MDk1LTQwNTItODExYS0wNzNjNjY5ZjBiYjIiLCJhY3IiOiIxIiwiYWxsb3dl
> ZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9h
> Y2Nlc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7
> InRlc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291
> bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3Vu
> dC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHki
> LCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0Iiwi
> Z2l2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFp
> bCI6InRlc3QtdXNlckBsb2NhbGhvc3Qi!
>  fQ.iXHI9NkRM8CaVX_iqIlAXcQGBhg-TH27F58C4XEDgCc_
> QawXKJ1GZ0qauVTnoS2mJB8ecW74V9HFpo-O0GVt4DyQzEw8dk0UUZtpsKrwLYk-
> IO0N6sitxJLr_wTjUTtcYJttOSnecuPB5XsxeSK6Lio4eNVarGRO00hNg7h3w1Y>Tests
> run: 191, Failures: 2, Errors: 0, Skipped: 2*
>
>
>
> On Tue, Jun 13, 2017 at 9:13 AM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > https://github.com/keycloak/keycloak#contributing
> >
> > On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <jairohenaorojas at gmail.com>
> > wrote:
> >
> >> Hello comunity,
> >>
> >> I am trying to understand the process to contribute to the project. A
> few
> >> days ago I did my first pull request but some errors occurred while
> >> running
> >> the tests. I do not understand the error very well, what is the process
> >> here ?, Where can I find more information ?, This is the channel where I
> >> should ask about this?
> >>
> >> https://github.com/keycloak/keycloak/pull/4219
> >>
> >>
> >> Thanks
> >> _______________________________________________
> >> 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 jairohenaorojas at gmail.com  Wed Jun 14 11:26:28 2017
From: jairohenaorojas at gmail.com (Jairo Henao)
Date: Wed, 14 Jun 2017 10:26:28 -0500
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAJgngAfYSGy7SuVT0uEWFAKd5K7OhG-YPNmttQc+oZKDUah9hA@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
	<CAM5SUC5Evn0Cn+xZqLY3aqwzZ_dNr96DtB340u8MyH8ipLiXGA@mail.gmail.com>
	<CAG3VLqCxf8kh3pEvaua7igHzMoSZqs8L=NSoOwczKRbpbmoA8g@mail.gmail.com>
	<CAJgngAfYSGy7SuVT0uEWFAKd5K7OhG-YPNmttQc+oZKDUah9hA@mail.gmail.com>
Message-ID: <CAG3VLqCHRdwUu3Wj7fUZhDWgZGNMT-4SZNi3wCfJ846AXLJh7g@mail.gmail.com>

Thanks, but I see that it just failed again.

:(

On Wed, Jun 14, 2017 at 9:36 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Most likely you didn't break the test. We have a couple tests at the
> moment that are unstable and fail intermittently. See
> https://issues.jboss.org/browse/KEYCLOAK-5020.
>
> I've restarted the test for your PR.
>
> On 13 June 2017 at 17:27, Jairo Henao <jairohenaorojas at gmail.com> wrote:
>
>> Thanks, I have already seen the link  but can not find information:
>>
>> The only thing I can extract from the test log is this:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *21:47:48,254 INFO  [KeycloakOnUndertow] Stopping auth server.Results
>> :Failed tests:
>> BruteForceTest.testGrantInvalidOtp:197->assertTokenNull:215 expected
>> null,
>> but
>> was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg
>> 2R2NGM2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.eyJ
>> qdGkiOiI5M2I2NDI1MC04MjYxLTRmOTUtOTY3ZS05ZDRiOTAwYTA1M2YiLCJ
>> leHAiOjE0OTcwNDQ5MDcsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjA3LCJpc3M
>> iOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIsImF
>> 1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFmZWM
>> tZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1hcHA
>> iLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiI3YzI5M2ZhMC1iYzk
>> xLTRjNjQtYWM1MS1lZWEyYTY1M2I2MjAiLCJhY3IiOiIxIiwiYWxsb3dlZC1
>> vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9hY2N
>> lc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InR
>> lc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291bnQ
>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>> saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHkiLCJ
>> wcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0IiwiZ2l
>> 2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFpbCI
>> 6InRlc3QtdXNlckBsb2NhbGhvc3Qi!
>>  fQ.cGA5MmxrvKW_O7B100jotT4f4jb9ctOBizuGyINor579NRWUAutllM9O
>> GEniPtDedZ1_m_IGmbXteiixhg--SG0dDHTec8CYxQZrtC2TjDBzdxkWYj3i
>> HL0Yj-1wcZZEaGb3809ol94oVrjOXcbcpjU-wAmQtK4RhRyoy-a3O-E>
>> BruteForceTest.testGrantMissingOtp:246->assertTokenNull:215 expected
>> null,
>> but
>> was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg
>> 2R2NGM2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.eyJ
>> qdGkiOiJiNGE1NjY3YS04ZjhlLTQ1YjctYTYzMy01ZDdhNzczMzlkNmEiLCJ
>> leHAiOjE0OTcwNDQ5MjIsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjIyLCJpc3M
>> iOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIsImF
>> 1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFmZWM
>> tZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1hcHA
>> iLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJlZDg2YWI5Ni1mMDk
>> 1LTQwNTItODExYS0wNzNjNjY5ZjBiYjIiLCJhY3IiOiIxIiwiYWxsb3dlZC1
>> vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9hY2N
>> lc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InR
>> lc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291bnQ
>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>> saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHkiLCJ
>> wcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0IiwiZ2l
>> 2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFpbCI
>> 6InRlc3QtdXNlckBsb2NhbGhvc3Qi!
>>  fQ.iXHI9NkRM8CaVX_iqIlAXcQGBhg-TH27F58C4XEDgCc_QawXKJ1GZ0qa
>> uVTnoS2mJB8ecW74V9HFpo-O0GVt4DyQzEw8dk0UUZtpsKrwLYk-IO0N6sit
>> xJLr_wTjUTtcYJttOSnecuPB5XsxeSK6Lio4eNVarGRO00hNg7h3w1Y>Tests
>> run: 191, Failures: 2, Errors: 0, Skipped: 2*
>>
>>
>>
>> On Tue, Jun 13, 2017 at 9:13 AM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>> > https://github.com/keycloak/keycloak#contributing
>> >
>> > On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <jairohenaorojas at gmail.com
>> >
>> > wrote:
>> >
>> >> Hello comunity,
>> >>
>> >> I am trying to understand the process to contribute to the project. A
>> few
>> >> days ago I did my first pull request but some errors occurred while
>> >> running
>> >> the tests. I do not understand the error very well, what is the process
>> >> here ?, Where can I find more information ?, This is the channel where
>> I
>> >> should ask about this?
>> >>
>> >> https://github.com/keycloak/keycloak/pull/4219
>> >>
>> >>
>> >> Thanks
>> >> _______________________________________________
>> >> 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 Jun 15 06:51:46 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jun 2017 12:51:46 +0200
Subject: [keycloak-dev] Add support for creating user with credentials
 in admin endpoints
In-Reply-To: <1b213589-e2ab-f00d-da20-20f02c2d5eaf@redhat.com>
References: <CAJgngAfcxVZS9fnmXkfwgEOVrmRv_n4VsYPiuxL0iAJwbXtdtQ@mail.gmail.com>
	<eaa7134a-5332-c1d5-0afa-0273cf43e1ab@redhat.com>
	<CAJgngAcpKvfUn15JjDJv2YVronUM_rBgo5we=Kg3_fx2XOu63Q@mail.gmail.com>
	<1b213589-e2ab-f00d-da20-20f02c2d5eaf@redhat.com>
Message-ID: <CAJgngAda9MgxJFf0aWGFnivsCX3K+bWOP-0E=q+Thb882YVXrw@mail.gmail.com>

We do, either through import at startup for a new realm or partial import
at runtime. However, those are bulk operations to import a bunch of stuff
at the same time. We already let the admin set the credentials as well as
role-mappings, but it has to be done with several calls. I can see a few
valid uses cases to be able to add users:

* Some sort of scripted migration of users, where you want to import one
user at a time and you have access to the hashed password
* An external user provisioning system and/or user self-registration service

On 12 June 2017 at 13:50, Bill Burke <bburke at redhat.com> wrote:

> don't we already support this via import?
>
> On 6/12/17 3:05 AM, Stian Thorgersen wrote:
>
> Not always. What about for instance the case when folks are importing a
> bunch of users and have a dB filled with hashed passwords.
>
> On 10 Jun 2017 6:09 am, "Bill Burke" <bburke at redhat.com> wrote:
>
>> credentials is somethign that is supposed to be set by the user.
>>
>>
>> On 6/9/17 5:49 AM, Stian Thorgersen wrote:
>> > Currently the admin endpoints ignores credentials when creating the user
>> > and a second post is needed to add credentials.
>> >
>> > I don't see any reason why it has to be this way and we should be able
>> to
>> > change it?
>> >
>> > We already have a PR for it https://issues.jboss.org/brows
>> e/KEYCLOAK-5026.
>> > _______________________________________________
>> > 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  Thu Jun 15 08:24:43 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 15 Jun 2017 12:24:43 +0000
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAG3VLqCHRdwUu3Wj7fUZhDWgZGNMT-4SZNi3wCfJ846AXLJh7g@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
	<CAM5SUC5Evn0Cn+xZqLY3aqwzZ_dNr96DtB340u8MyH8ipLiXGA@mail.gmail.com>
	<CAG3VLqCxf8kh3pEvaua7igHzMoSZqs8L=NSoOwczKRbpbmoA8g@mail.gmail.com>
	<CAJgngAfYSGy7SuVT0uEWFAKd5K7OhG-YPNmttQc+oZKDUah9hA@mail.gmail.com>
	<CAG3VLqCHRdwUu3Wj7fUZhDWgZGNMT-4SZNi3wCfJ846AXLJh7g@mail.gmail.com>
Message-ID: <CAM5SUC6S03WbvtPi+BiNMvo0H-5QQzBNAVaaw_n6f1yarCsr7w@mail.gmail.com>

Like Stian mentioned, it's not caused by your PR. I did a rebase and ran a
test with Travis CI, all the tests pass
https://travis-ci.org/abstractj/keycloak/builds/243201760.

The problem is related with BruteForceTest which occasionally fails.

On Wed, Jun 14, 2017 at 12:26 PM Jairo Henao <jairohenaorojas at gmail.com>
wrote:

> Thanks, but I see that it just failed again.
>
> :(
>
> On Wed, Jun 14, 2017 at 9:36 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Most likely you didn't break the test. We have a couple tests at the
>> moment that are unstable and fail intermittently. See
>> https://issues.jboss.org/browse/KEYCLOAK-5020.
>>
>> I've restarted the test for your PR.
>>
>> On 13 June 2017 at 17:27, Jairo Henao <jairohenaorojas at gmail.com> wrote:
>>
>>> Thanks, I have already seen the link  but can not find information:
>>>
>>> The only thing I can extract from the test log is this:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *21:47:48,254 INFO  [KeycloakOnUndertow] Stopping auth server.Results
>>> :Failed tests:
>>> BruteForceTest.testGrantInvalidOtp:197->assertTokenNull:215 expected
>>> null,
>>> but
>>>
>>> was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg2R2NGM2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.eyJqdGkiOiI5M2I2NDI1MC04MjYxLTRmOTUtOTY3ZS05ZDRiOTAwYTA1M2YiLCJleHAiOjE0OTcwNDQ5MDcsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjA3LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIsImF1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFmZWMtZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1hcHAiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiI3YzI5M2ZhMC1iYzkxLTRjNjQtYWM1MS1lZWEyYTY1M2I2MjAiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InRlc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0IiwiZ2l2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFpbCI6InRlc3QtdXNlckBsb2NhbGhvc3Qi!
>>>
>>>  fQ.cGA5MmxrvKW_O7B100jotT4f4jb9ctOBizuGyINor579NRWUAutllM9OGEniPtDedZ1_m_IGmbXteiixhg--SG0dDHTec8CYxQZrtC2TjDBzdxkWYj3iHL0Yj-1wcZZEaGb3809ol94oVrjOXcbcpjU-wAmQtK4RhRyoy-a3O-E>
>>> BruteForceTest.testGrantMissingOtp:246->assertTokenNull:215 expected
>>> null,
>>> but
>>>
>>> was:<eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJGSjg2R2NGM2pUYk5MT2NvNE52WmtVQ0lVbWZZQ3FvcXRPUWVNZmJoTmxFIn0.eyJqdGkiOiJiNGE1NjY3YS04ZjhlLTQ1YjctYTYzMy01ZDdhNzczMzlkNmEiLCJleHAiOjE0OTcwNDQ5MjIsIm5iZiI6MCwiaWF0IjoxNDk3MDQ0NjIyLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvdGVzdCIsImF1ZCI6InRlc3QtYXBwIiwic3ViIjoiYTM2Nzk1MmQtMTQ5ZS00NTRjLWFmZWMtZDU2MjNkZWFhYzZlIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoidGVzdC1hcHAiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJlZDg2YWI5Ni1mMDk1LTQwNTItODExYS0wNzNjNjY5ZjBiYjIiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbImh0dHA6Ly9sb2NhbGhvc3Q6ODE4MCJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsidXNlciJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InRlc3QtYXBwIjp7InJvbGVzIjpbImN1c3RvbWVyLXVzZXIiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiJUb20gQnJhZHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0ZXN0LXVzZXJAbG9jYWxob3N0IiwiZ2l2ZW5fbmFtZSI6IlRvbSIsImZhbWlseV9uYW1lIjoiQnJhZHkiLCJlbWFpbCI6InRlc3QtdXNlckBsb2NhbGhvc3Qi!
>>>
>>>  fQ.iXHI9NkRM8CaVX_iqIlAXcQGBhg-TH27F58C4XEDgCc_QawXKJ1GZ0qauVTnoS2mJB8ecW74V9HFpo-O0GVt4DyQzEw8dk0UUZtpsKrwLYk-IO0N6sitxJLr_wTjUTtcYJttOSnecuPB5XsxeSK6Lio4eNVarGRO00hNg7h3w1Y>Tests
>>> run: 191, Failures: 2, Errors: 0, Skipped: 2*
>>>
>>>
>>>
>>> On Tue, Jun 13, 2017 at 9:13 AM, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>>
>>> > https://github.com/keycloak/keycloak#contributing
>>> >
>>> > On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <
>>> jairohenaorojas at gmail.com>
>>> > wrote:
>>> >
>>> >> Hello comunity,
>>> >>
>>> >> I am trying to understand the process to contribute to the project. A
>>> few
>>> >> days ago I did my first pull request but some errors occurred while
>>> >> running
>>> >> the tests. I do not understand the error very well, what is the
>>> process
>>> >> here ?, Where can I find more information ?, This is the channel
>>> where I
>>> >> should ask about this?
>>> >>
>>> >> https://github.com/keycloak/keycloak/pull/4219
>>> >>
>>> >>
>>> >> Thanks
>>> >> _______________________________________________
>>> >> 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 Jun 15 08:41:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jun 2017 14:41:27 +0200
Subject: [keycloak-dev] UMA 2.0
In-Reply-To: <CAJrcDBeshp=CeFwY_hbKZwvkLt8w+EBE8OHMLtB4p8Q24XWGPQ@mail.gmail.com>
References: <CAJrcDBeshp=CeFwY_hbKZwvkLt8w+EBE8OHMLtB4p8Q24XWGPQ@mail.gmail.com>
Message-ID: <CAJgngAfgm1+syi1C6vqjnxpGW-fGT97j77xc0185+=S4=foEZA@mail.gmail.com>

Depends on amount of work. If it's not to much extra work I'd prefer to
have backwards compatibility for a while to allow users to migrate then
remove in the last 3.x release. If that is a lot of work then we should
just remove it.

On 14 June 2017 at 14:50, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> I would like to review our UMA implementation (which is based on v1), and
> get it aligned with the new version, v2.
>
> One of the main changes we need is that now UMA has a specific grant type
> that should be used by clients to obtain RPTs. The Authorization API no
> longer exists.
>
> Other changes are basically related with parts of the specs we are missing
> that don't really bring issues for people already using UMA in Keycloak.
> But new features and better UMA support.
>
> My question is if it is reasonable to have those changes in 3.2.0.CR1 and
> how ? For instance, if we decide to have those changes in, specially the
> new UMA grant type, should we keep/deprecate the legacy Authorization API
> for backward compatibility or just remove it from AuthZ REST API ?
>
> 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  Thu Jun 15 08:43:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jun 2017 14:43:39 +0200
Subject: [keycloak-dev] Branches for Node.js modules
In-Reply-To: <20170612091833.GA4261@abstractj.org>
References: <20170609085723.GB23087@abstractj.org>
	<CAJgngAdYtd-uSFsx+4qTZQUMCNb=QYORvn2st9jKxgBKdaYjiA@mail.gmail.com>
	<20170612091833.GA4261@abstractj.org>
Message-ID: <CAJgngAeFQhXBKJtWH-apJPDCbXuSEYdfg-VUuxiQ6StWQ=_sRQ@mail.gmail.com>

Having multiple branches to control the version of Keycloak is not the
right approach. IMO Travis should just test with the latest Keycloak
release, then we should have a CI job in Central CI that checks with
Keycloak and RHSSO master.

On 12 June 2017 at 11:18, Bruno Oliveira <bruno at abstractj.org> wrote:

> Sure. We actually have this issue: https://issues.jboss.org/
> browse/KEYCLOAK-4985.
> Which we could catch earlier, if we had the CI running tests against
> the changes on Keycloak repo.
>
> So the idea is pretty much it:
>
> - latest: test the latest released version of Node.js adapter, against
>   the latest stable version of the Keycloak server (we already do this).
>
> - master: test the latest changes from the Node.js adapter, against the
>   latest changes on Keycloak server.
>
> Another alternative, if you don't like this idea, is to have a build matrix
> on Travis. The same idea from keycloak server tests. Or we can do nothing.
>
> The solo porpuse of this change is to guarantee that we catch issues
> like this earlier.
>
>
> On 2017-06-12, Stian Thorgersen wrote:
> > This doesn't make sense to me. Can you elaborate a bit more? The reason
> it
> > makes sense to have two branches for quickstarts is that one branch is
> Dev
> > and the other is the latest release. For node.js I can't see that being
> the
> > case as there's "proper" releases and tags and such stuff
> >
> > On 9 Jun 2017 6:25 pm, "Bruno Oliveira" <bruno at abstractj.org> wrote:
> >
> > Good morning, I would like to propose the creation of 2 branches for
> > Node.js modules following the same approach from the quickstarts:
> >
> > - latest: stable
> > - master: development
> >
> > The initial motivation behind this, is to enable Travis to test these
> > modules
> > against the latest change on Keycloak server.
> >
> > Thoughts?
> >
> > --
> >
> > 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  Thu Jun 15 08:44:32 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jun 2017 14:44:32 +0200
Subject: [keycloak-dev] Branches for Node.js modules
In-Reply-To: <CAJgngAeFQhXBKJtWH-apJPDCbXuSEYdfg-VUuxiQ6StWQ=_sRQ@mail.gmail.com>
References: <20170609085723.GB23087@abstractj.org>
	<CAJgngAdYtd-uSFsx+4qTZQUMCNb=QYORvn2st9jKxgBKdaYjiA@mail.gmail.com>
	<20170612091833.GA4261@abstractj.org>
	<CAJgngAeFQhXBKJtWH-apJPDCbXuSEYdfg-VUuxiQ6StWQ=_sRQ@mail.gmail.com>
Message-ID: <CAJgngAeFfzujHNwmqri55A1F5O44ufZO8HT7Z5dmUaJz_VN_1A@mail.gmail.com>

Actually central CI should only test with the latest Keycloak master, it
doesn't need to test Node.js master against previous KC release

On 15 June 2017 at 14:43, Stian Thorgersen <sthorger at redhat.com> wrote:

> Having multiple branches to control the version of Keycloak is not the
> right approach. IMO Travis should just test with the latest Keycloak
> release, then we should have a CI job in Central CI that checks with
> Keycloak and RHSSO master.
>
> On 12 June 2017 at 11:18, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> Sure. We actually have this issue: https://issues.jboss.org/brows
>> e/KEYCLOAK-4985.
>> Which we could catch earlier, if we had the CI running tests against
>> the changes on Keycloak repo.
>>
>> So the idea is pretty much it:
>>
>> - latest: test the latest released version of Node.js adapter, against
>>   the latest stable version of the Keycloak server (we already do this).
>>
>> - master: test the latest changes from the Node.js adapter, against the
>>   latest changes on Keycloak server.
>>
>> Another alternative, if you don't like this idea, is to have a build
>> matrix
>> on Travis. The same idea from keycloak server tests. Or we can do nothing.
>>
>> The solo porpuse of this change is to guarantee that we catch issues
>> like this earlier.
>>
>>
>> On 2017-06-12, Stian Thorgersen wrote:
>> > This doesn't make sense to me. Can you elaborate a bit more? The reason
>> it
>> > makes sense to have two branches for quickstarts is that one branch is
>> Dev
>> > and the other is the latest release. For node.js I can't see that being
>> the
>> > case as there's "proper" releases and tags and such stuff
>> >
>> > On 9 Jun 2017 6:25 pm, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>> >
>> > Good morning, I would like to propose the creation of 2 branches for
>> > Node.js modules following the same approach from the quickstarts:
>> >
>> > - latest: stable
>> > - master: development
>> >
>> > The initial motivation behind this, is to enable Travis to test these
>> > modules
>> > against the latest change on Keycloak server.
>> >
>> > Thoughts?
>> >
>> > --
>> >
>> > abstractj
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> --
>>
>> abstractj
>>
>
>

From psilva at redhat.com  Thu Jun 15 09:03:37 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 15 Jun 2017 10:03:37 -0300
Subject: [keycloak-dev] UMA 2.0
In-Reply-To: <CAJgngAfgm1+syi1C6vqjnxpGW-fGT97j77xc0185+=S4=foEZA@mail.gmail.com>
References: <CAJrcDBeshp=CeFwY_hbKZwvkLt8w+EBE8OHMLtB4p8Q24XWGPQ@mail.gmail.com>
	<CAJgngAfgm1+syi1C6vqjnxpGW-fGT97j77xc0185+=S4=foEZA@mail.gmail.com>
Message-ID: <CAJrcDBdwviL=4zzTFiLuP+URBBAZu9U3NLWVYReTd-X=ggV86Q@mail.gmail.com>

I see. Well, I think we can keep for a while. Shall we remove it in
3.2.0.Final ?

On Thu, Jun 15, 2017 at 9:41 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Depends on amount of work. If it's not to much extra work I'd prefer to
> have backwards compatibility for a while to allow users to migrate then
> remove in the last 3.x release. If that is a lot of work then we should
> just remove it.
>
> On 14 June 2017 at 14:50, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hi,
>>
>> I would like to review our UMA implementation (which is based on v1), and
>> get it aligned with the new version, v2.
>>
>> One of the main changes we need is that now UMA has a specific grant type
>> that should be used by clients to obtain RPTs. The Authorization API no
>> longer exists.
>>
>> Other changes are basically related with parts of the specs we are missing
>> that don't really bring issues for people already using UMA in Keycloak.
>> But new features and better UMA support.
>>
>> My question is if it is reasonable to have those changes in 3.2.0.CR1 and
>> how ? For instance, if we decide to have those changes in, specially the
>> new UMA grant type, should we keep/deprecate the legacy Authorization API
>> for backward compatibility or just remove it from AuthZ REST API ?
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From psilva at redhat.com  Thu Jun 15 09:05:15 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 15 Jun 2017 10:05:15 -0300
Subject: [keycloak-dev] UMA 2.0
In-Reply-To: <bdbcc2aa-d69a-61c6-f1fe-56906d78ea82@redhat.com>
References: <CAJrcDBeshp=CeFwY_hbKZwvkLt8w+EBE8OHMLtB4p8Q24XWGPQ@mail.gmail.com>
	<bdbcc2aa-d69a-61c6-f1fe-56906d78ea82@redhat.com>
Message-ID: <CAJrcDBfn2Zctzbmn-wLUmAJ_NZmSezSay9ni-JPV24Xtd8Ezjw@mail.gmail.com>

On Wed, Jun 14, 2017 at 6:11 PM, Alexey Kazakov <alkazako at redhat.com> wrote:

> IMO it's not a good approach in general to remove any public API without
> deprecating it first. Give users some time to adopt the changes :)
>
I won't dare to break you guys :)


>
> On 06/14/2017 05:50 AM, Pedro Igor Silva wrote:
>
> Hi,
>
> I would like to review our UMA implementation (which is based on v1), and
> get it aligned with the new version, v2.
>
> One of the main changes we need is that now UMA has a specific grant type
> that should be used by clients to obtain RPTs. The Authorization API no
> longer exists.
>
> Other changes are basically related with parts of the specs we are missing
> that don't really bring issues for people already using UMA in Keycloak.
> But new features and better UMA support.
>
> My question is if it is reasonable to have those changes in 3.2.0.CR1 and
> how ? For instance, if we decide to have those changes in, specially the
> new UMA grant type, should we keep/deprecate the legacy Authorization API
> for backward compatibility or just remove it from AuthZ REST API ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From bruno at abstractj.org  Thu Jun 15 09:31:16 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 15 Jun 2017 13:31:16 +0000
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
Message-ID: <CAM5SUC69PkxVtQ5O4+r+UPtxLqTPO6axhjcGe4N40UHmRym09A@mail.gmail.com>

It must be green now :)

On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <jairohenaorojas at gmail.com>
wrote:

> Hello comunity,
>
> I am trying to understand the process to contribute to the project. A few
> days ago I did my first pull request but some errors occurred while running
> the tests. I do not understand the error very well, what is the process
> here ?, Where can I find more information ?, This is the channel where I
> should ask about this?
>
> https://github.com/keycloak/keycloak/pull/4219
>
>
> Thanks
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From jairohenaorojas at gmail.com  Thu Jun 15 09:59:14 2017
From: jairohenaorojas at gmail.com (Jairo Henao)
Date: Thu, 15 Jun 2017 08:59:14 -0500
Subject: [keycloak-dev] How to do my pull request successfully
In-Reply-To: <CAM5SUC69PkxVtQ5O4+r+UPtxLqTPO6axhjcGe4N40UHmRym09A@mail.gmail.com>
References: <CAG3VLqDq4w08xQQ0egEbb=5rqkU50DakjzccSVRCaSfuTw7BDA@mail.gmail.com>
	<CAM5SUC69PkxVtQ5O4+r+UPtxLqTPO6axhjcGe4N40UHmRym09A@mail.gmail.com>
Message-ID: <CAG3VLqAPVv4nQkX=5sVc4W-NTWT-j=WAyB+oVz+Wu_pvULGi1g@mail.gmail.com>

Excellent, thanks.

On Thu, Jun 15, 2017 at 8:31 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> It must be green now :)
>
> On Tue, Jun 13, 2017 at 10:58 AM Jairo Henao <jairohenaorojas at gmail.com>
> wrote:
>
>> Hello comunity,
>>
>> I am trying to understand the process to contribute to the project. A few
>> days ago I did my first pull request but some errors occurred while
>> running
>> the tests. I do not understand the error very well, what is the process
>> here ?, Where can I find more information ?, This is the channel where I
>> should ask about this?
>>
>> https://github.com/keycloak/keycloak/pull/4219
>>
>>
>> Thanks
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


-- 
Saludos

Jairo Henao

*Chat Skype: jairo.henao.05*

From jma at corefiling.com  Fri Jun 16 09:46:39 2017
From: jma at corefiling.com (Jay Anslow)
Date: Fri, 16 Jun 2017 14:46:39 +0100
Subject: [keycloak-dev] JS policy performance improvements
Message-ID: <504B0D85-3A30-4E49-BC20-3ABB397DF4EC@corefiling.com>

Hi all,

I'm using the JS Policy to evaluate resource permissions, but we've started to run into some performance problems when using large numbers of resources.

However, I've managed to improve the performance of the JSPolicyProvider, by caching the ScriptEngine (creating new bindings per evaluation) and compiling the code on policy update.

The "Obtaining Entitlements" operation is now ~5x faster than before, for my test setup (100 test runs, ~1100 resources, remote Postgres).

I'd like to merge my changes back to Keycloak, so I just wanted to check if the community would be interested in this change before I prepare a PR and create a JIRA issue.

Regards,
Jay

-- 
Jay Anslow, Product Development, CoreFiling Limited
http://www.corefiling.com
Phone: +44-1865-203192



From psilva at redhat.com  Fri Jun 16 10:10:15 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 16 Jun 2017 11:10:15 -0300
Subject: [keycloak-dev] JS policy performance improvements
In-Reply-To: <504B0D85-3A30-4E49-BC20-3ABB397DF4EC@corefiling.com>
References: <504B0D85-3A30-4E49-BC20-3ABB397DF4EC@corefiling.com>
Message-ID: <CAJrcDBdkYVBxg3PMD_9+bW=ie=+J8uC0mDtKWmQ=TTdRV2L2bw@mail.gmail.com>

+1. I'm glad to review your changes if you send a PR.

On Fri, Jun 16, 2017 at 10:46 AM, Jay Anslow <jma at corefiling.com> wrote:

> Hi all,
>
> I'm using the JS Policy to evaluate resource permissions, but we've
> started to run into some performance problems when using large numbers of
> resources.
>
> However, I've managed to improve the performance of the JSPolicyProvider,
> by caching the ScriptEngine (creating new bindings per evaluation) and
> compiling the code on policy update.
>
> The "Obtaining Entitlements" operation is now ~5x faster than before, for
> my test setup (100 test runs, ~1100 resources, remote Postgres).
>
> I'd like to merge my changes back to Keycloak, so I just wanted to check
> if the community would be interested in this change before I prepare a PR
> and create a JIRA issue.
>
> Regards,
> Jay
>
> --
> Jay Anslow, Product Development, CoreFiling Limited
> http://www.corefiling.com
> Phone: +44-1865-203192
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Fri Jun 16 10:42:38 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 16 Jun 2017 11:42:38 -0300
Subject: [keycloak-dev] JS policy performance improvements
In-Reply-To: <CAJrcDBdkYVBxg3PMD_9+bW=ie=+J8uC0mDtKWmQ=TTdRV2L2bw@mail.gmail.com>
References: <504B0D85-3A30-4E49-BC20-3ABB397DF4EC@corefiling.com>
	<CAJrcDBdkYVBxg3PMD_9+bW=ie=+J8uC0mDtKWmQ=TTdRV2L2bw@mail.gmail.com>
Message-ID: <CAJrcDBcULrk-z1O7Ajr5PhnRopf6Eh95xU-511cqDgH4_L_Z=g@mail.gmail.com>

Btw, we were already planning to cahnge JSPolicyprovider to use Keycloak's
ScriptingSPI. I have some changes at this respect which I was planning to
include to 3.2.0.CR1.

Maybe I can share my changes too, so you can check if they also give you a
better performance. It is basically the same SPI used to write custom
authentication flows.

On Fri, Jun 16, 2017 at 11:10 AM, Pedro Igor Silva <psilva at redhat.com>
wrote:

> +1. I'm glad to review your changes if you send a PR.
>
> On Fri, Jun 16, 2017 at 10:46 AM, Jay Anslow <jma at corefiling.com> wrote:
>
>> Hi all,
>>
>> I'm using the JS Policy to evaluate resource permissions, but we've
>> started to run into some performance problems when using large numbers of
>> resources.
>>
>> However, I've managed to improve the performance of the JSPolicyProvider,
>> by caching the ScriptEngine (creating new bindings per evaluation) and
>> compiling the code on policy update.
>>
>> The "Obtaining Entitlements" operation is now ~5x faster than before, for
>> my test setup (100 test runs, ~1100 resources, remote Postgres).
>>
>> I'd like to merge my changes back to Keycloak, so I just wanted to check
>> if the community would be interested in this change before I prepare a PR
>> and create a JIRA issue.
>>
>> Regards,
>> Jay
>>
>> --
>> Jay Anslow, Product Development, CoreFiling Limited
>> http://www.corefiling.com
>> Phone: +44-1865-203192
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From jma at corefiling.com  Fri Jun 16 13:14:39 2017
From: jma at corefiling.com (Jay Anslow)
Date: Fri, 16 Jun 2017 18:14:39 +0100
Subject: [keycloak-dev] JS policy performance improvements
In-Reply-To: <CAJrcDBcULrk-z1O7Ajr5PhnRopf6Eh95xU-511cqDgH4_L_Z=g@mail.gmail.com>
References: <504B0D85-3A30-4E49-BC20-3ABB397DF4EC@corefiling.com>
	<CAJrcDBdkYVBxg3PMD_9+bW=ie=+J8uC0mDtKWmQ=TTdRV2L2bw@mail.gmail.com>
	<CAJrcDBcULrk-z1O7Ajr5PhnRopf6Eh95xU-511cqDgH4_L_Z=g@mail.gmail.com>
Message-ID: <ACA906DF-E964-4914-8466-A9B37215D276@corefiling.com>

Thanks, I've created the PR now (https://github.com/keycloak/keycloak/pull/4236).

I'd be happy to help with the move to use the ScriptingSPI, as these changes should be able to help there as well.

> On 16 Jun 2017, at 15:42, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> Btw, we were already planning to cahnge JSPolicyprovider to use Keycloak's ScriptingSPI. I have some changes at this respect which I was planning to include to 3.2.0.CR1.
> 
> Maybe I can share my changes too, so you can check if they also give you a better performance. It is basically the same SPI used to write custom authentication flows.
> 
> On Fri, Jun 16, 2017 at 11:10 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
> +1. I'm glad to review your changes if you send a PR.
> 
> On Fri, Jun 16, 2017 at 10:46 AM, Jay Anslow <jma at corefiling.com> wrote:
> Hi all,
> 
> I'm using the JS Policy to evaluate resource permissions, but we've started to run into some performance problems when using large numbers of resources.
> 
> However, I've managed to improve the performance of the JSPolicyProvider, by caching the ScriptEngine (creating new bindings per evaluation) and compiling the code on policy update.
> 
> The "Obtaining Entitlements" operation is now ~5x faster than before, for my test setup (100 test runs, ~1100 resources, remote Postgres).
> 
> I'd like to merge my changes back to Keycloak, so I just wanted to check if the community would be interested in this change before I prepare a PR and create a JIRA issue.
> 
> Regards,
> Jay
> 
> --
> Jay Anslow, Product Development, CoreFiling Limited
> http://www.corefiling.com
> Phone: +44-1865-203192
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 



From bburke at redhat.com  Fri Jun 16 17:36:16 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jun 2017 17:36:16 -0400
Subject: [keycloak-dev] no stack trace in testsuite failed run
Message-ID: <ac315077-e6d7-a1a2-2740-3be45a1e18f6@redhat.com>

I performed the following in integration-arquillian testsuite

mvn -Dkeycloak.logging.level=debug clean install > out.txt 2>&1

My test is failing in AbstractKeycloakTest.afterAbstractKeycloakTest 
while running TestCleanup loop.  I'm getting a NullPointerException but 
I can't seem to get the testsuite to output the stack trace.  I do see 
info level logs from this class, but no stack trace.  Even if I add a 
exception.printStackTrace(). The stack trace is empty.

Any ideas?  This popped up before but just magically disappeared.  Now 
its back.  The test failure only comes up in a full maven build.  Can't 
reproduce in IDE.

Thanks,

Bill



From sthorger at redhat.com  Mon Jun 19 02:56:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 19 Jun 2017 08:56:29 +0200
Subject: [keycloak-dev] UMA 2.0
In-Reply-To: <CAJrcDBdwviL=4zzTFiLuP+URBBAZu9U3NLWVYReTd-X=ggV86Q@mail.gmail.com>
References: <CAJrcDBeshp=CeFwY_hbKZwvkLt8w+EBE8OHMLtB4p8Q24XWGPQ@mail.gmail.com>
	<CAJgngAfgm1+syi1C6vqjnxpGW-fGT97j77xc0185+=S4=foEZA@mail.gmail.com>
	<CAJrcDBdwviL=4zzTFiLuP+URBBAZu9U3NLWVYReTd-X=ggV86Q@mail.gmail.com>
Message-ID: <CAJgngAcmK4QttvGoxnL8b8SP2guHefm3+zkitcA2byh_hP7PWA@mail.gmail.com>

We can remove it in 3.3 or maybe even 3.4. Just add a JIRA to remove it to
3.3 and we can discuss exactly when later.

On 15 June 2017 at 15:03, Pedro Igor Silva <psilva at redhat.com> wrote:

> I see. Well, I think we can keep for a while. Shall we remove it in
> 3.2.0.Final ?
>
> On Thu, Jun 15, 2017 at 9:41 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Depends on amount of work. If it's not to much extra work I'd prefer to
>> have backwards compatibility for a while to allow users to migrate then
>> remove in the last 3.x release. If that is a lot of work then we should
>> just remove it.
>>
>> On 14 June 2017 at 14:50, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to review our UMA implementation (which is based on v1), and
>>> get it aligned with the new version, v2.
>>>
>>> One of the main changes we need is that now UMA has a specific grant type
>>> that should be used by clients to obtain RPTs. The Authorization API no
>>> longer exists.
>>>
>>> Other changes are basically related with parts of the specs we are
>>> missing
>>> that don't really bring issues for people already using UMA in Keycloak.
>>> But new features and better UMA support.
>>>
>>> My question is if it is reasonable to have those changes in 3.2.0.CR1 and
>>> how ? For instance, if we decide to have those changes in, specially the
>>> new UMA grant type, should we keep/deprecate the legacy Authorization API
>>> for backward compatibility or just remove it from AuthZ REST API ?
>>>
>>> Regards.
>>> Pedro Igor
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From vmuzikar at redhat.com  Tue Jun 20 06:57:08 2017
From: vmuzikar at redhat.com (Vaclav Muzikar)
Date: Tue, 20 Jun 2017 12:57:08 +0200
Subject: [keycloak-dev] Branches for Node.js modules
In-Reply-To: <CAJgngAeFfzujHNwmqri55A1F5O44ufZO8HT7Z5dmUaJz_VN_1A@mail.gmail.com>
References: <20170609085723.GB23087@abstractj.org>
	<CAJgngAdYtd-uSFsx+4qTZQUMCNb=QYORvn2st9jKxgBKdaYjiA@mail.gmail.com>
	<20170612091833.GA4261@abstractj.org>
	<CAJgngAeFQhXBKJtWH-apJPDCbXuSEYdfg-VUuxiQ6StWQ=_sRQ@mail.gmail.com>
	<CAJgngAeFfzujHNwmqri55A1F5O44ufZO8HT7Z5dmUaJz_VN_1A@mail.gmail.com>
Message-ID: <CAMQSZyiRU+Qw_rTTN5bjpK1AoTG6bYCv_uu-BT97bDy0hXBQHQ@mail.gmail.com>

On Thu, Jun 15, 2017 at 2:44 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Actually central CI should only test with the latest Keycloak master, it
> doesn't need to test Node.js master against previous KC release
>
>
Yes, that's exactly what we do. The community nightly jobs for Node.js are
testing with Keycloak's master branch.
(And of course we have RHSSO jobs which are fired on releases and are
testing the released product version of Node.js adapter and server.)


> On 15 June 2017 at 14:43, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> > Having multiple branches to control the version of Keycloak is not the
> > right approach. IMO Travis should just test with the latest Keycloak
> > release, then we should have a CI job in Central CI that checks with
> > Keycloak and RHSSO master.
> >
> > On 12 June 2017 at 11:18, Bruno Oliveira <bruno at abstractj.org> wrote:
> >
> >> Sure. We actually have this issue: https://issues.jboss.org/brows
> >> e/KEYCLOAK-4985.
> >> Which we could catch earlier, if we had the CI running tests against
> >> the changes on Keycloak repo.
> >>
> >> So the idea is pretty much it:
> >>
> >> - latest: test the latest released version of Node.js adapter, against
> >>   the latest stable version of the Keycloak server (we already do this).
> >>
> >> - master: test the latest changes from the Node.js adapter, against the
> >>   latest changes on Keycloak server.
> >>
> >> Another alternative, if you don't like this idea, is to have a build
> >> matrix
> >> on Travis. The same idea from keycloak server tests. Or we can do
> nothing.
> >>
> >> The solo porpuse of this change is to guarantee that we catch issues
> >> like this earlier.
> >>
> >>
> >> On 2017-06-12, Stian Thorgersen wrote:
> >> > This doesn't make sense to me. Can you elaborate a bit more? The
> reason
> >> it
> >> > makes sense to have two branches for quickstarts is that one branch is
> >> Dev
> >> > and the other is the latest release. For node.js I can't see that
> being
> >> the
> >> > case as there's "proper" releases and tags and such stuff
> >> >
> >> > On 9 Jun 2017 6:25 pm, "Bruno Oliveira" <bruno at abstractj.org> wrote:
> >> >
> >> > Good morning, I would like to propose the creation of 2 branches for
> >> > Node.js modules following the same approach from the quickstarts:
> >> >
> >> > - latest: stable
> >> > - master: development
> >> >
> >> > The initial motivation behind this, is to enable Travis to test these
> >> > modules
> >> > against the latest change on Keycloak server.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> >
> >> > 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
>



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

From thomas.darimont at googlemail.com  Tue Jun 20 20:06:02 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 21 Jun 2017 02:06:02 +0200
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <CAJgngAeHFECbX0UgiKpo1B5KBYxxDLAnvoQ_JA046=GPnV=jMQ@mail.gmail.com>
References: <577524F4.9070803@redhat.com>
	<CAJgngAeKV1tPR61KW5963qanORXLFiUZ7KVZNDHpD9z0M5Y1GQ@mail.gmail.com>
	<5776635C.1000606@redhat.com>
	<CAJgngAe46i3Yjgwn3EZo=cx_R_nnCG4EJ9NjFdmFpY5cUu4iHQ@mail.gmail.com>
	<1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com>
	<5776C857.2070703@redhat.com>
	<CAJgngAeZEVdFEUTtqUZbBLqwdgJ6gYu8drcqH+mDW_K5yoT36w@mail.gmail.com>
	<577E08A0.4010409@redhat.com>
	<CAJgngAdov6Gz8o8ccKumPT2GXOSdbot9C_F=cFdrW9UUGhC86A@mail.gmail.com>
	<577F9794.6060904@redhat.com>
	<CAJgngAcMFSoD31SGo6cEH=-s71ZvdCLvWRBncynmfOx32C0KZA@mail.gmail.com>
	<57834C28.7090309@redhat.com>
	<CAJgngAeHFECbX0UgiKpo1B5KBYxxDLAnvoQ_JA046=GPnV=jMQ@mail.gmail.com>
Message-ID: <CAK-7U1ghAS49n-6iGYDh5KyGdaJOVFBYt_F3HPFMxzF_uXDM1A@mail.gmail.com>

Hello folks,

are the conclusions of this discussion regarding scope parameter support
still current or are they already superseded by new insights?

For completeness the JIRA issue for "Scope query parameter support":
https://issues.jboss.org/browse/KEYCLOAK-349

Cheers,
Thomas

2016-07-11 12:13 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

>
>
> On 11 July 2016 at 09:35, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 11/07/16 08:22, Stian Thorgersen wrote:
>>
>>
>>
>> On 8 July 2016 at 14:07, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 07/07/16 12:07, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 7 July 2016 at 09:45, Marek Posolda < <mposolda at redhat.com>
>>> mposolda at redhat.com> wrote:
>>>
>>>> On 04/07/16 09:47, Stian Thorgersen wrote:
>>>>
>>>> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite
>>>> sure how it would look like to an end-user.
>>>>
>>>> * Are these managed on a separate screen or on the protocol mappers
>>>> screen?
>>>>
>>>> I am thinking about the protocolMappers screen. Just add another "type"
>>>> of protocolMapper. This means that we don't need to add another
>>>> concept/modelType just for scope parameter, but still we can easily
>>>> filter/view the available mappers of type 'scope aggregator' (on the screen
>>>> with list of all protocolMappers).
>>>>
>>>
>>> Not quite sure I see why it should be on the protocol mappers screen. As
>>> it's a separate type of mapper as well the UI to define them would be
>>> different I'm not sure I see why it can't be a separate screen.
>>>
>>> I think it would fit better on the scope tab. It could have two tabs
>>> "Default scope" and "Scopes" or something like that.
>>>
>>> Not sure which place is better. However I am maybe slightly more for
>>> protocolMappers screen because:
>>>
>>> - It just looks a bit more intuitive to me if all the things, which are
>>> represented at model/DB level by protocolMapper entity are also in admin
>>> console grouped together on single place. But maybe it's just me ;-)
>>>
>>
>>>
>>> - For the aggregated mapper, you can select that "children" mappers will
>>> be either simple mappers or other aggregated mappers. For example for the
>>> "full-profile" mapper, you can select that it's child is another aggregated
>>> mapper "profile" together with some additional simple mappers like
>>> "first_name" or "last_name" . Hence in the list of available mappers, you
>>> should be able to see both simple and aggregated mappers.
>>> Isn't it then a bit confusing that you will see both the simple mappers
>>> like "firstName" (which are configured in "mappers" tab) together with
>>> aggregated mappers like "profile" (which are configured under
>>> "scope/default scope" tab) together?
>>>
>>
>> You lost me a bit here. I think I may have miss understood something you
>> explained before.
>>
>> My assumption was that there are two separate things: regular mappers and
>> scope mappers. Regular mappers are configured as before, while scope
>> mappers are configured for each scope. So there would be separate screens
>> in either case. Maybe I'm wrong here, but I could see a page that lists all
>> scopes, then you can click on the scope to see what mappers are applied as
>> well as what roles are applied.
>>
>> I was thinking about ScopeAggregatedMapper just like about another
>> implementation of ProtocolMapper interface. No another special model or
>> special mapper type, which Keycloak needs to deal with. The Keycloak
>> (TokenManager) will treat like any other mapper, so will just call
>> "transformAccessToken" to it and ScopeAggregatedMapper impl will delegate
>> to other children mappers and apply roles.
>>
>> The difference is, that UI will need to be a bit special then for other
>> mappers. There is possibility that we will add the support showing list of
>> roles and protocolMappers to the directive "kc-provider-config" . However
>> it looks the better option might be that particular protocolMapper
>> implementation (or particular provider implementation in general) has a way
>> to override the angular template with it's own UI if it wants to do it.
>>
>> For example, if there is protocolMapper provider with id "foo" then
>> angular will:
>> - First look if there is special screen "protocol-mapper-detail_foo.html"
>> .
>> - If the screen doesn't exist, it will fallback to default
>> "protocol-mapper-detail.html" screen with the "kc-provider-config"
>> directive for generic properties.
>>
>> For the protocolMapper, the scopeAggregatedMapper will have special
>> screen "protocol-mapper-detail_scope-aggregate.html" when all other
>> impls just use the generic screen like now.
>>
>>
>> Maybe it's time to do some mock screens or wire frames?
>>
>> +1
>>
>> or start prototyping and see how it goes? :)
>>
>
> Prototyping is just a superior mock ;)
>
>
>>
>>
>> Marek
>>
>>
>>
>>>
>>>
>>> Btv. Our current providerModel classes usually have something like:
>>>
>>> Map<String, String> config;
>>>
>>> on them. However for the aggregated mapper impl, it may be needed to
>>> extend this to:
>>>
>>> Map<String, List<String>> config;
>>>
>>> as mapper will need to have the property with the list of children
>>> mappers and property with the list of children roles. The question is, how
>>> to represent it in DB? I can see possibilities like:
>>> a) The value at DB level will be just simple string with children values
>>> divided by some delimiter (eg. "mapper123###mapper456###mapper789" )
>>> b) The value will be list at DB level with separate record for every
>>> value (eg. 3 values like "mapper123" , "mapper456" , "mapper789" )
>>>
>>> It seems the (b) is a bit harder for migration, but likely the more
>>> proper way to address this? It looks like something to keep in mind once we
>>> refactor to the "unified" providerModel table.
>>>
>>>
>>>
>>>>
>>>> * How do users define and view scopes, including viewing what
>>>> claims/mappers/roles are associated with a scope?
>>>> * How does a user add/remove claims, protocol mappers and roles to a ScopeAggregatorProtocolMapper?
>>>>
>>>>
>>>> I am thinking that for roles, you will select the roles in same way,
>>>> like it's in current "Scopes" tab of client (or "role mappings" tab of
>>>> user). Probably very similar UI can be used for selecting "children"
>>>> mappers of current protocolMapper though? Something like "Available
>>>> mappers" and "Assigned mappers" and buttons like "Add selected" and "Remove
>>>> selected". Also similarly like for roles, you can view in "Effective
>>>> mappers" the list of all effective mappers in case that you have more
>>>> composed aggregated scopeAggregatorMappers.
>>>>
>>>> For example, if you have mapper for scope parameter "full-profile",
>>>> which will have children mappers, that will point to other scope aggregated
>>>> mappers : "profile" , "email" and "phone". Hence in "Effective mappers" for
>>>> "full-profile" you will see all the descendants, not just the direct
>>>> children. So you will see also all the simple attribute mappers like
>>>> "firstName", "lastName", "birthday", "phone number", ...
>>>>
>>>
>>> Sounds good
>>>
>>>
>>>>
>>>> * Do we provide one or more built-in ScopeAggregatorProtocolMapper
>>>> that are configurable? I assume so and that users don't have to
>>>> programatically define scopes.
>>>>
>>>> Yes. I think that we should provide those built-in, which are specified
>>>> by OIDC specification. Which is "profile" , "email" , "phone" , "address".
>>>> And we will need to define mappers for all their simple attributes (
>>>> "birthday", "gender" , ...) . Those simple mappers like "birthday" won't be
>>>> root mappers by default, so they won't be applied unless the scope
>>>> parameter is used (for their parent scopeAggregatorMapper).
>>>>
>>>> For backwards compatibility, we will still use the same 'simple'
>>>> mappers like now ( username, email, full name, family name, given name) and
>>>> they will be added to token by default. The scopeAggregator mappers (and
>>>> their corresponding children) will be applied just if the scope parameter
>>>> with corresponding value will be used.
>>>>
>>>
>>> SAML doesn't have this concept does it? If so it probably doesn't even
>>> make sense to show scope mappers for SAML clients.
>>>
>>> I don't think that SAML has something like scope parameter. At least I
>>> am not aware of that :-)
>>>
>>> However our SAML clients currently have "Scope" tab visible to map which
>>> realm roles (or client roles) are allowed to be put into SAML assertion.
>>> That works same like for OIDC clients and makes sense to keep. I guess you
>>> meant to hide just the new sub-tab of the "Scope" tab for configure scope
>>> parameter?
>>>
>>> Marek
>>>
>>>
>>>
>>>>
>>>>
>>>
>>>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>>>
>>>> Yes (see above)
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda at redhat.com>
>>>> mposolda at redhat.com> wrote:
>>>>
>>>>> Ok, I wasn't also 100% keen about using role.
>>>>>
>>>>> Thinking also about what Pedro mentioned before about protocol
>>>>> mappers. So I wonder that instead of introduce new "scope" concept, we just
>>>>> reuse protocolMappers SPI and have special impl of protocolMapper, which is
>>>>> able to deal with scope parameter and aggregate other "children"
>>>>> protocolMappers and roles?
>>>>>
>>>>> Something like this:
>>>>> - There will be new ProtocolMapper implementation like
>>>>> ScopeAggregatorProtocolMapper.  You will define value of scope
>>>>> parameter (eg. "photo" ) in the configuration of this protocolMapper.
>>>>> Mapper will be ignored if scope parameter value with this name was not used.
>>>>>
>>>>> - You will be able to define "children" protocolMappers and "children"
>>>>> roles in ScopeAggregatorProtocolMapper.
>>>>>
>>>>> - For each client (and clientTemplate), we will have many defined
>>>>> protocolMappers, but just some subset of them are "root" mappers, which are
>>>>> applied by default. The rest of mappers will be used just as "children" of
>>>>> root mappers. So in client model, we might have:
>>>>> client.getDefinedProtocolMappers() // all defined
>>>>> client.getProtocolMappers()    // just subset of defined (defacto root
>>>>> mappers)
>>>>>
>>>>> - For example: client will have defined protocolMappers: firstName,
>>>>> lastName, birthday, profile, email. Just "profile" and "email" will be root
>>>>> mappers. And "profile" is ScopeAggregatorMapper for scope value "profile"
>>>>> and it's children mappers are : firstName, lastName, birthday.
>>>>>
>>>>> So then:
>>>>> -- user will send "scope=profile" . Then defacto all of "firstName",
>>>>> "lastName", "birthday", "email" claims will be included in token. On
>>>>> consent screen will be just "Profile" and "Email"
>>>>> -- user won't send "scope=profile" . Then defacto just "email" claim
>>>>> will be included (So for this example, email is always included even if not
>>>>> specified by scope parameter).
>>>>>
>>>>> - With this concept, we are able to aggregate many various claims into
>>>>> single value of "scope" and on the consent screen have just the roots. This
>>>>> would fit well for the default scope values mentioned by OIDC specs. We are
>>>>> also able to define mappers (claims), which will be always available even
>>>>> if not specified by scope parameter.
>>>>>
>>>>> - For the roles, I am not 100% sure whether to include them into the
>>>>> concept or not? However it seems to me that rather yes. The particular role
>>>>> will be applied into token just if all of those 3 conditions are met:
>>>>> 1) user is member of the role
>>>>> 2) client has scope for the role (so current "scope" tab in clients
>>>>> will remain as is)
>>>>> 3) if role has scopePAramRequired=true, then it must be included in
>>>>> some mapper (in other words, those roles are not included directly in
>>>>> clientSession.getRoles , but it's the responsibility of
>>>>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
>>>>> met).
>>>>>
>>>>> So again, user won't see all children roles on consent screen. Just
>>>>> the parent protocolMapper.
>>>>>
>>>>> This will work fine with "scope=offline_access" . There will be
>>>>> protocolMapper for "offline_access" parameter, which will aggregate just
>>>>> one children role (the current realm role "offline_access"). The offline
>>>>> token will be issued just if accessToken will have "offline_access"
>>>>> permission. So if some client, doesn't need offline tokens, it can just
>>>>> remove "offline_access" protocolMapper. Also if some user shouldn't be
>>>>> allowed to request offline tokens, admin can remove him from the
>>>>> "offline_access" role.
>>>>>
>>>>> - If some scope parameter is applicable for more clients, it can be
>>>>> defined on clientTemplate.
>>>>>
>>>>>
>>>>> PS: I will be on holidays and back on next Thursday 7th July. So sorry
>>>>> if I won't reply immediately to next mails.
>>>>>
>>>>> Mare
>>>>>
>>>>>
>>>>>
>>>>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>>>>
>>>>>> Reading all of this makes me think it would be cleaner to introduce a
>>>>>>> separate scope concept ;)
>>>>>>>
>>>>>>> A user doesn't have a scope - a user has roles and attributes.
>>>>>>> Re-using roles
>>>>>>> concept for the scope just makes it feel awkward and retrofitted.
>>>>>>>
>>>>>> +10000
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Jun 21 02:54:00 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 21 Jun 2017 08:54:00 +0200
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <CAK-7U1ghAS49n-6iGYDh5KyGdaJOVFBYt_F3HPFMxzF_uXDM1A@mail.gmail.com>
References: <577524F4.9070803@redhat.com>
	<CAJgngAeKV1tPR61KW5963qanORXLFiUZ7KVZNDHpD9z0M5Y1GQ@mail.gmail.com>
	<5776635C.1000606@redhat.com>
	<CAJgngAe46i3Yjgwn3EZo=cx_R_nnCG4EJ9NjFdmFpY5cUu4iHQ@mail.gmail.com>
	<1301846468.5448650.1467377842578.JavaMail.zimbra@redhat.com>
	<5776C857.2070703@redhat.com>
	<CAJgngAeZEVdFEUTtqUZbBLqwdgJ6gYu8drcqH+mDW_K5yoT36w@mail.gmail.com>
	<577E08A0.4010409@redhat.com>
	<CAJgngAdov6Gz8o8ccKumPT2GXOSdbot9C_F=cFdrW9UUGhC86A@mail.gmail.com>
	<577F9794.6060904@redhat.com>
	<CAJgngAcMFSoD31SGo6cEH=-s71ZvdCLvWRBncynmfOx32C0KZA@mail.gmail.com>
	<57834C28.7090309@redhat.com>
	<CAJgngAeHFECbX0UgiKpo1B5KBYxxDLAnvoQ_JA046=GPnV=jMQ@mail.gmail.com>
	<CAK-7U1ghAS49n-6iGYDh5KyGdaJOVFBYt_F3HPFMxzF_uXDM1A@mail.gmail.com>
Message-ID: <CAJgngAceS9rCq3yG1aU2ohSEhjgPUJ-NDbGYs9m_VWEET2u1Zw@mail.gmail.com>

Nothing new to report here. If someone wants to contribute it great, but I
doubt we'll find to do it ourselves anytime soon. Would be best to start a
new discussion around it if someone wants to contribute.

On 21 June 2017 at 02:06, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello folks,
>
> are the conclusions of this discussion regarding scope parameter support
> still current or are they already superseded by new insights?
>
> For completeness the JIRA issue for "Scope query parameter support":
> https://issues.jboss.org/browse/KEYCLOAK-349
>
> Cheers,
> Thomas
>
> 2016-07-11 12:13 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>>
>>
>> On 11 July 2016 at 09:35, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 11/07/16 08:22, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 8 July 2016 at 14:07, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> On 07/07/16 12:07, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 7 July 2016 at 09:45, Marek Posolda < <mposolda at redhat.com>
>>>> mposolda at redhat.com> wrote:
>>>>
>>>>> On 04/07/16 09:47, Stian Thorgersen wrote:
>>>>>
>>>>> ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite
>>>>> sure how it would look like to an end-user.
>>>>>
>>>>> * Are these managed on a separate screen or on the protocol mappers
>>>>> screen?
>>>>>
>>>>> I am thinking about the protocolMappers screen. Just add another
>>>>> "type" of protocolMapper. This means that we don't need to add another
>>>>> concept/modelType just for scope parameter, but still we can easily
>>>>> filter/view the available mappers of type 'scope aggregator' (on the screen
>>>>> with list of all protocolMappers).
>>>>>
>>>>
>>>> Not quite sure I see why it should be on the protocol mappers screen.
>>>> As it's a separate type of mapper as well the UI to define them would be
>>>> different I'm not sure I see why it can't be a separate screen.
>>>>
>>>> I think it would fit better on the scope tab. It could have two tabs
>>>> "Default scope" and "Scopes" or something like that.
>>>>
>>>> Not sure which place is better. However I am maybe slightly more for
>>>> protocolMappers screen because:
>>>>
>>>> - It just looks a bit more intuitive to me if all the things, which are
>>>> represented at model/DB level by protocolMapper entity are also in admin
>>>> console grouped together on single place. But maybe it's just me ;-)
>>>>
>>>
>>>>
>>>> - For the aggregated mapper, you can select that "children" mappers
>>>> will be either simple mappers or other aggregated mappers. For example for
>>>> the "full-profile" mapper, you can select that it's child is another
>>>> aggregated mapper "profile" together with some additional simple mappers
>>>> like "first_name" or "last_name" . Hence in the list of available mappers,
>>>> you should be able to see both simple and aggregated mappers.
>>>> Isn't it then a bit confusing that you will see both the simple mappers
>>>> like "firstName" (which are configured in "mappers" tab) together with
>>>> aggregated mappers like "profile" (which are configured under
>>>> "scope/default scope" tab) together?
>>>>
>>>
>>> You lost me a bit here. I think I may have miss understood something you
>>> explained before.
>>>
>>> My assumption was that there are two separate things: regular mappers
>>> and scope mappers. Regular mappers are configured as before, while scope
>>> mappers are configured for each scope. So there would be separate screens
>>> in either case. Maybe I'm wrong here, but I could see a page that lists all
>>> scopes, then you can click on the scope to see what mappers are applied as
>>> well as what roles are applied.
>>>
>>> I was thinking about ScopeAggregatedMapper just like about another
>>> implementation of ProtocolMapper interface. No another special model or
>>> special mapper type, which Keycloak needs to deal with. The Keycloak
>>> (TokenManager) will treat like any other mapper, so will just call
>>> "transformAccessToken" to it and ScopeAggregatedMapper impl will delegate
>>> to other children mappers and apply roles.
>>>
>>> The difference is, that UI will need to be a bit special then for other
>>> mappers. There is possibility that we will add the support showing list of
>>> roles and protocolMappers to the directive "kc-provider-config" . However
>>> it looks the better option might be that particular protocolMapper
>>> implementation (or particular provider implementation in general) has a way
>>> to override the angular template with it's own UI if it wants to do it.
>>>
>>> For example, if there is protocolMapper provider with id "foo" then
>>> angular will:
>>> - First look if there is special screen "protocol-mapper-detail_foo.html"
>>> .
>>> - If the screen doesn't exist, it will fallback to default
>>> "protocol-mapper-detail.html" screen with the "kc-provider-config"
>>> directive for generic properties.
>>>
>>> For the protocolMapper, the scopeAggregatedMapper will have special
>>> screen "protocol-mapper-detail_scope-aggregate.html" when all other
>>> impls just use the generic screen like now.
>>>
>>>
>>> Maybe it's time to do some mock screens or wire frames?
>>>
>>> +1
>>>
>>> or start prototyping and see how it goes? :)
>>>
>>
>> Prototyping is just a superior mock ;)
>>
>>
>>>
>>>
>>> Marek
>>>
>>>
>>>
>>>>
>>>>
>>>> Btv. Our current providerModel classes usually have something like:
>>>>
>>>> Map<String, String> config;
>>>>
>>>> on them. However for the aggregated mapper impl, it may be needed to
>>>> extend this to:
>>>>
>>>> Map<String, List<String>> config;
>>>>
>>>> as mapper will need to have the property with the list of children
>>>> mappers and property with the list of children roles. The question is, how
>>>> to represent it in DB? I can see possibilities like:
>>>> a) The value at DB level will be just simple string with children
>>>> values divided by some delimiter (eg. "mapper123###mapper456###mapper789"
>>>> )
>>>> b) The value will be list at DB level with separate record for every
>>>> value (eg. 3 values like "mapper123" , "mapper456" , "mapper789" )
>>>>
>>>> It seems the (b) is a bit harder for migration, but likely the more
>>>> proper way to address this? It looks like something to keep in mind once we
>>>> refactor to the "unified" providerModel table.
>>>>
>>>>
>>>>
>>>>>
>>>>> * How do users define and view scopes, including viewing what
>>>>> claims/mappers/roles are associated with a scope?
>>>>> * How does a user add/remove claims, protocol mappers and roles to
>>>>> a ScopeAggregatorProtocolMapper?
>>>>>
>>>>> I am thinking that for roles, you will select the roles in same way,
>>>>> like it's in current "Scopes" tab of client (or "role mappings" tab of
>>>>> user). Probably very similar UI can be used for selecting "children"
>>>>> mappers of current protocolMapper though? Something like "Available
>>>>> mappers" and "Assigned mappers" and buttons like "Add selected" and "Remove
>>>>> selected". Also similarly like for roles, you can view in "Effective
>>>>> mappers" the list of all effective mappers in case that you have more
>>>>> composed aggregated scopeAggregatorMappers.
>>>>>
>>>>> For example, if you have mapper for scope parameter "full-profile",
>>>>> which will have children mappers, that will point to other scope aggregated
>>>>> mappers : "profile" , "email" and "phone". Hence in "Effective mappers" for
>>>>> "full-profile" you will see all the descendants, not just the direct
>>>>> children. So you will see also all the simple attribute mappers like
>>>>> "firstName", "lastName", "birthday", "phone number", ...
>>>>>
>>>>
>>>> Sounds good
>>>>
>>>>
>>>>>
>>>>> * Do we provide one or more built-in ScopeAggregatorProtocolMapper
>>>>> that are configurable? I assume so and that users don't have to
>>>>> programatically define scopes.
>>>>>
>>>>> Yes. I think that we should provide those built-in, which are
>>>>> specified by OIDC specification. Which is "profile" , "email" , "phone" ,
>>>>> "address". And we will need to define mappers for all their simple
>>>>> attributes ( "birthday", "gender" , ...) . Those simple mappers like
>>>>> "birthday" won't be root mappers by default, so they won't be applied
>>>>> unless the scope parameter is used (for their parent scopeAggregatorMapper).
>>>>>
>>>>> For backwards compatibility, we will still use the same 'simple'
>>>>> mappers like now ( username, email, full name, family name, given name) and
>>>>> they will be added to token by default. The scopeAggregator mappers (and
>>>>> their corresponding children) will be applied just if the scope parameter
>>>>> with corresponding value will be used.
>>>>>
>>>>
>>>> SAML doesn't have this concept does it? If so it probably doesn't even
>>>> make sense to show scope mappers for SAML clients.
>>>>
>>>> I don't think that SAML has something like scope parameter. At least I
>>>> am not aware of that :-)
>>>>
>>>> However our SAML clients currently have "Scope" tab visible to map
>>>> which realm roles (or client roles) are allowed to be put into SAML
>>>> assertion. That works same like for OIDC clients and makes sense to keep. I
>>>> guess you meant to hide just the new sub-tab of the "Scope" tab for
>>>> configure scope parameter?
>>>>
>>>> Marek
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>
>>>>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>>>>
>>>>> Yes (see above)
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda at redhat.com>
>>>>> mposolda at redhat.com> wrote:
>>>>>
>>>>>> Ok, I wasn't also 100% keen about using role.
>>>>>>
>>>>>> Thinking also about what Pedro mentioned before about protocol
>>>>>> mappers. So I wonder that instead of introduce new "scope" concept, we just
>>>>>> reuse protocolMappers SPI and have special impl of protocolMapper, which is
>>>>>> able to deal with scope parameter and aggregate other "children"
>>>>>> protocolMappers and roles?
>>>>>>
>>>>>> Something like this:
>>>>>> - There will be new ProtocolMapper implementation like
>>>>>> ScopeAggregatorProtocolMapper.  You will define value of scope
>>>>>> parameter (eg. "photo" ) in the configuration of this protocolMapper.
>>>>>> Mapper will be ignored if scope parameter value with this name was not used.
>>>>>>
>>>>>> - You will be able to define "children" protocolMappers and
>>>>>> "children" roles in ScopeAggregatorProtocolMapper.
>>>>>>
>>>>>> - For each client (and clientTemplate), we will have many defined
>>>>>> protocolMappers, but just some subset of them are "root" mappers, which are
>>>>>> applied by default. The rest of mappers will be used just as "children" of
>>>>>> root mappers. So in client model, we might have:
>>>>>> client.getDefinedProtocolMappers() // all defined
>>>>>> client.getProtocolMappers()    // just subset of defined (defacto
>>>>>> root mappers)
>>>>>>
>>>>>> - For example: client will have defined protocolMappers: firstName,
>>>>>> lastName, birthday, profile, email. Just "profile" and "email" will be root
>>>>>> mappers. And "profile" is ScopeAggregatorMapper for scope value "profile"
>>>>>> and it's children mappers are : firstName, lastName, birthday.
>>>>>>
>>>>>> So then:
>>>>>> -- user will send "scope=profile" . Then defacto all of "firstName",
>>>>>> "lastName", "birthday", "email" claims will be included in token. On
>>>>>> consent screen will be just "Profile" and "Email"
>>>>>> -- user won't send "scope=profile" . Then defacto just "email" claim
>>>>>> will be included (So for this example, email is always included even if not
>>>>>> specified by scope parameter).
>>>>>>
>>>>>> - With this concept, we are able to aggregate many various claims
>>>>>> into single value of "scope" and on the consent screen have just the roots.
>>>>>> This would fit well for the default scope values mentioned by OIDC specs.
>>>>>> We are also able to define mappers (claims), which will be always available
>>>>>> even if not specified by scope parameter.
>>>>>>
>>>>>> - For the roles, I am not 100% sure whether to include them into the
>>>>>> concept or not? However it seems to me that rather yes. The particular role
>>>>>> will be applied into token just if all of those 3 conditions are met:
>>>>>> 1) user is member of the role
>>>>>> 2) client has scope for the role (so current "scope" tab in clients
>>>>>> will remain as is)
>>>>>> 3) if role has scopePAramRequired=true, then it must be included in
>>>>>> some mapper (in other words, those roles are not included directly in
>>>>>> clientSession.getRoles , but it's the responsibility of
>>>>>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
>>>>>> met).
>>>>>>
>>>>>> So again, user won't see all children roles on consent screen. Just
>>>>>> the parent protocolMapper.
>>>>>>
>>>>>> This will work fine with "scope=offline_access" . There will be
>>>>>> protocolMapper for "offline_access" parameter, which will aggregate just
>>>>>> one children role (the current realm role "offline_access"). The offline
>>>>>> token will be issued just if accessToken will have "offline_access"
>>>>>> permission. So if some client, doesn't need offline tokens, it can just
>>>>>> remove "offline_access" protocolMapper. Also if some user shouldn't be
>>>>>> allowed to request offline tokens, admin can remove him from the
>>>>>> "offline_access" role.
>>>>>>
>>>>>> - If some scope parameter is applicable for more clients, it can be
>>>>>> defined on clientTemplate.
>>>>>>
>>>>>>
>>>>>> PS: I will be on holidays and back on next Thursday 7th July. So
>>>>>> sorry if I won't reply immediately to next mails.
>>>>>>
>>>>>> Mare
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>>>>>
>>>>>>> Reading all of this makes me think it would be cleaner to introduce a
>>>>>>>> separate scope concept ;)
>>>>>>>>
>>>>>>>> A user doesn't have a scope - a user has roles and attributes.
>>>>>>>> Re-using roles
>>>>>>>> concept for the scope just makes it feel awkward and retrofitted.
>>>>>>>>
>>>>>>> +10000
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From mposolda at redhat.com  Wed Jun 21 04:42:58 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 21 Jun 2017 10:42:58 +0200
Subject: [keycloak-dev] no stack trace in testsuite failed run
In-Reply-To: <ac315077-e6d7-a1a2-2740-3be45a1e18f6@redhat.com>
References: <ac315077-e6d7-a1a2-2740-3be45a1e18f6@redhat.com>
Message-ID: <f6793956-d588-cd83-d51f-24d344dcdc10@redhat.com>

I've just had similar (or probably same) issue in ComponentsTest.

TestCleanup class was using thread-unsafe LinkedList under the covers. 
So some concurrency tests had issues, as they updated LinkedList from 
more threads and then this NPE can happen when iterating through LinkedList:

java.lang.NullPointerException
     at java.util.LinkedList$ListItr.next(LinkedList.java:893)
     at 
org.keycloak.testsuite.util.TestCleanup.executeCleanup(TestCleanup.java:143)
     at 
org.keycloak.testsuite.AbstractKeycloakTest.afterAbstractKeycloakTest(AbstractKeycloakTest.java:178)

When this happened, I saw the other test methods fail with empty NPE 
like for you.

I've fixed it in latest master by making the class TestCleanup 
thread-safe. Hopefully this will fix your issue too. Sorry for troubles 
as thread-unsafe TestCleanup was my fault :(

BTV. Some concurrency tests like BruteForceTest or ComponentsTest still 
have issues because of H2 locks. I can sometimes simulate on my laptop 
and seeing that they sometime fails on travis too. But that's separate 
issue and hopefully it's just specific to H2.

Marek


On 16/06/17 23:36, Bill Burke wrote:
> I performed the following in integration-arquillian testsuite
>
> mvn -Dkeycloak.logging.level=debug clean install > out.txt 2>&1
>
> My test is failing in AbstractKeycloakTest.afterAbstractKeycloakTest
> while running TestCleanup loop.  I'm getting a NullPointerException but
> I can't seem to get the testsuite to output the stack trace.  I do see
> info level logs from this class, but no stack trace.  Even if I add a
> exception.printStackTrace(). The stack trace is empty.
>
> Any ideas?  This popped up before but just magically disappeared.  Now
> its back.  The test failure only comes up in a full maven build.  Can't
> reproduce in IDE.
>
> Thanks,
>
> Bill
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From hfernand at redhat.com  Wed Jun 21 08:19:22 2017
From: hfernand at redhat.com (Hector Fernandez)
Date: Wed, 21 Jun 2017 14:19:22 +0200
Subject: [keycloak-dev] Assign existing roles to clients using a realm json
	file
Message-ID: <CAHxsJpEfi08JQpmVe+aCE61anf=yE=mvUhf=4zXhDuSQcpKtkg@mail.gmail.com>

Hi guys,

We want to assign roles to existing clients whenever we import the realm
json file. I tried several ways and checked your code looking for potential
json elements without any success.


I tried to define them using clientScopeMappings but it seems to be ignored:
```
"clientScopeMappings": {
        "realm-management": [
            {
                "client": "hector-online-platform",
                "roles": ["view-users"]
            },
            {
                "client": "hector-online-platform",
                "roles": ["manage-authorization"]
            }
        ],
        "broker": [
            {
                "client": "hector-online-platform",
                "roles": ["read-token"]
            }
        ]
      }
```

I even tried to use the client element from the roles section in the realm.
But it fails whenever a role exists how it happens with the read-token.

```
"roles": {
   "client": {
      "broker": { "name": "read-token"},
       ...
    }
```

In other words, we want to emulate what we do via admin console -- Clients
-> Choose a client --> Service Account Roles --> Choose a client then
assign a role like for broker the role read-token.


-- 
*<hector/>*

From hmlnarik at redhat.com  Wed Jun 21 11:45:46 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 21 Jun 2017 17:45:46 +0200
Subject: [keycloak-dev] no stack trace in testsuite failed run
In-Reply-To: <f6793956-d588-cd83-d51f-24d344dcdc10@redhat.com>
References: <ac315077-e6d7-a1a2-2740-3be45a1e18f6@redhat.com>
	<f6793956-d588-cd83-d51f-24d344dcdc10@redhat.com>
Message-ID: <CAMvXD=GGSf-SZ4xE9G-_zRzANfdeNaoMftyHxfyTwRQym6RipQ@mail.gmail.com>

The H2 issues should hopefully be fixed by
https://github.com/keycloak/keycloak/pull/4246

--Hynek

On Wed, Jun 21, 2017 at 10:42 AM, Marek Posolda <mposolda at redhat.com> wrote:
> I've just had similar (or probably same) issue in ComponentsTest.
>
> TestCleanup class was using thread-unsafe LinkedList under the covers.
> So some concurrency tests had issues, as they updated LinkedList from
> more threads and then this NPE can happen when iterating through LinkedList:
>
> java.lang.NullPointerException
>      at java.util.LinkedList$ListItr.next(LinkedList.java:893)
>      at
> org.keycloak.testsuite.util.TestCleanup.executeCleanup(TestCleanup.java:143)
>      at
> org.keycloak.testsuite.AbstractKeycloakTest.afterAbstractKeycloakTest(AbstractKeycloakTest.java:178)
>
> When this happened, I saw the other test methods fail with empty NPE
> like for you.
>
> I've fixed it in latest master by making the class TestCleanup
> thread-safe. Hopefully this will fix your issue too. Sorry for troubles
> as thread-unsafe TestCleanup was my fault :(
>
> BTV. Some concurrency tests like BruteForceTest or ComponentsTest still
> have issues because of H2 locks. I can sometimes simulate on my laptop
> and seeing that they sometime fails on travis too. But that's separate
> issue and hopefully it's just specific to H2.
>
> Marek
>
>
> On 16/06/17 23:36, Bill Burke wrote:
>> I performed the following in integration-arquillian testsuite
>>
>> mvn -Dkeycloak.logging.level=debug clean install > out.txt 2>&1
>>
>> My test is failing in AbstractKeycloakTest.afterAbstractKeycloakTest
>> while running TestCleanup loop.  I'm getting a NullPointerException but
>> I can't seem to get the testsuite to output the stack trace.  I do see
>> info level logs from this class, but no stack trace.  Even if I add a
>> exception.printStackTrace(). The stack trace is empty.
>>
>> Any ideas?  This popped up before but just magically disappeared.  Now
>> its back.  The test failure only comes up in a full maven build.  Can't
>> reproduce in IDE.
>>
>> 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



-- 

--Hynek

From john.d.ament at gmail.com  Wed Jun 21 14:03:51 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 21 Jun 2017 18:03:51 +0000
Subject: [keycloak-dev] Timeframe for 3.2?
Message-ID: <CAOqetn__yqP68kpwdkg_Emz8K+biedqsQw-WswRzgErv4qz+EQ@mail.gmail.com>

Hi,

According to JIRA, 3.2 was supposed to be out 6/14.  It seems like this may
be blocked on Wildfly 11's release which doesn't seem to have any dates.

I was wondering, would it be possible to have a 3.2 that didn't depend on
WF11?

John

From mposolda at redhat.com  Wed Jun 21 16:17:39 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 21 Jun 2017 22:17:39 +0200
Subject: [keycloak-dev] no stack trace in testsuite failed run
In-Reply-To: <CAMvXD=GGSf-SZ4xE9G-_zRzANfdeNaoMftyHxfyTwRQym6RipQ@mail.gmail.com>
References: <ac315077-e6d7-a1a2-2740-3be45a1e18f6@redhat.com>
	<f6793956-d588-cd83-d51f-24d344dcdc10@redhat.com>
	<CAMvXD=GGSf-SZ4xE9G-_zRzANfdeNaoMftyHxfyTwRQym6RipQ@mail.gmail.com>
Message-ID: <d22a454a-76c5-c549-49cc-cd759527a0f7@redhat.com>

Cool! It's in master now.

Marek

On 21/06/17 17:45, Hynek Mlnarik wrote:
> The H2 issues should hopefully be fixed by
> https://github.com/keycloak/keycloak/pull/4246
>
> --Hynek
>
> On Wed, Jun 21, 2017 at 10:42 AM, Marek Posolda <mposolda at redhat.com> wrote:
>> I've just had similar (or probably same) issue in ComponentsTest.
>>
>> TestCleanup class was using thread-unsafe LinkedList under the covers.
>> So some concurrency tests had issues, as they updated LinkedList from
>> more threads and then this NPE can happen when iterating through LinkedList:
>>
>> java.lang.NullPointerException
>>       at java.util.LinkedList$ListItr.next(LinkedList.java:893)
>>       at
>> org.keycloak.testsuite.util.TestCleanup.executeCleanup(TestCleanup.java:143)
>>       at
>> org.keycloak.testsuite.AbstractKeycloakTest.afterAbstractKeycloakTest(AbstractKeycloakTest.java:178)
>>
>> When this happened, I saw the other test methods fail with empty NPE
>> like for you.
>>
>> I've fixed it in latest master by making the class TestCleanup
>> thread-safe. Hopefully this will fix your issue too. Sorry for troubles
>> as thread-unsafe TestCleanup was my fault :(
>>
>> BTV. Some concurrency tests like BruteForceTest or ComponentsTest still
>> have issues because of H2 locks. I can sometimes simulate on my laptop
>> and seeing that they sometime fails on travis too. But that's separate
>> issue and hopefully it's just specific to H2.
>>
>> Marek
>>
>>
>> On 16/06/17 23:36, Bill Burke wrote:
>>> I performed the following in integration-arquillian testsuite
>>>
>>> mvn -Dkeycloak.logging.level=debug clean install > out.txt 2>&1
>>>
>>> My test is failing in AbstractKeycloakTest.afterAbstractKeycloakTest
>>> while running TestCleanup loop.  I'm getting a NullPointerException but
>>> I can't seem to get the testsuite to output the stack trace.  I do see
>>> info level logs from this class, but no stack trace.  Even if I add a
>>> exception.printStackTrace(). The stack trace is empty.
>>>
>>> Any ideas?  This popped up before but just magically disappeared.  Now
>>> its back.  The test failure only comes up in a full maven build.  Can't
>>> reproduce in IDE.
>>>
>>> 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 mposolda at redhat.com  Wed Jun 21 16:32:52 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 21 Jun 2017 22:32:52 +0200
Subject: [keycloak-dev] Moving ClientInitialAccessModel from infinispan to db
Message-ID: <1b80c983-cb0a-69a8-e237-70aca646e0b8@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/4248 for move 
ClientInitialAccessModel from userSessionProvider (infinispan) to realm 
model (db). This has advantages like:

- Client initial access tokens will remain persistent among server restarts
- There won't be issues in cross-dc environment

Regarding functionality, nothing is changed. Admin console and admin 
REST endpoints are still the same behaviour. There is still decrease of 
remainingCount during each client registration like was before. Only 
change is, that server restarts will just work :)

I didn't add support for export/import of client initial access token 
models. Was thinking about possible issues like:
- admin creates the initial token with 3 counters
- Export is done
- Then token is used to register 3 clients, which defacto make the token 
expired
- After realm re-import, the token will be back again with 3 attempts, 
which is likely not what admin wants.

Also I didn't add support for caching. Reason is, that there is just 
small amount of tokens. Also there is almost same amount of writes and 
reads to ClientInitialAccessModel as every client registration needs to 
decrease counter and update DB. With caching enabled, there will be lots 
of additional overhead needed to send invalidation message to all 
cluster nodes in all DCs during every write, which likely won't help 
with performance, but rather the opposite.

WDYT?

Marek


From sthorger at redhat.com  Thu Jun 22 02:13:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 22 Jun 2017 08:13:29 +0200
Subject: [keycloak-dev] Timeframe for 3.2?
In-Reply-To: <CAOqetn__yqP68kpwdkg_Emz8K+biedqsQw-WswRzgErv4qz+EQ@mail.gmail.com>
References: <CAOqetn__yqP68kpwdkg_Emz8K+biedqsQw-WswRzgErv4qz+EQ@mail.gmail.com>
Message-ID: <CAJgngAc0x5FjuR3Bs_Z_3Bje7+aL=jGB=F1Hv-kWM3W+nmcaiw@mail.gmail.com>

We're not waiting for WF 11. KC 3.2 will be next week or the following week.

On 21 June 2017 at 20:03, John D. Ament <john.d.ament at gmail.com> wrote:

> Hi,
>
> According to JIRA, 3.2 was supposed to be out 6/14.  It seems like this may
> be blocked on Wildfly 11's release which doesn't seem to have any dates.
>
> I was wondering, would it be possible to have a 3.2 that didn't depend on
> WF11?
>
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Jun 22 02:41:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 22 Jun 2017 08:41:43 +0200
Subject: [keycloak-dev] no stack trace in testsuite failed run
In-Reply-To: <CAMvXD=GGSf-SZ4xE9G-_zRzANfdeNaoMftyHxfyTwRQym6RipQ@mail.gmail.com>
References: <ac315077-e6d7-a1a2-2740-3be45a1e18f6@redhat.com>
	<f6793956-d588-cd83-d51f-24d344dcdc10@redhat.com>
	<CAMvXD=GGSf-SZ4xE9G-_zRzANfdeNaoMftyHxfyTwRQym6RipQ@mail.gmail.com>
Message-ID: <CAJgngAcXLW3HLpA1sk7-=zOhCkix2hU9YsvjaqEe_xmj7ziOxQ@mail.gmail.com>

Awesome - thanks for sorting this out Hynek :)

On 21 June 2017 at 17:45, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> The H2 issues should hopefully be fixed by
> https://github.com/keycloak/keycloak/pull/4246
>
> --Hynek
>
> On Wed, Jun 21, 2017 at 10:42 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
> > I've just had similar (or probably same) issue in ComponentsTest.
> >
> > TestCleanup class was using thread-unsafe LinkedList under the covers.
> > So some concurrency tests had issues, as they updated LinkedList from
> > more threads and then this NPE can happen when iterating through
> LinkedList:
> >
> > java.lang.NullPointerException
> >      at java.util.LinkedList$ListItr.next(LinkedList.java:893)
> >      at
> > org.keycloak.testsuite.util.TestCleanup.executeCleanup(
> TestCleanup.java:143)
> >      at
> > org.keycloak.testsuite.AbstractKeycloakTest.afterAbstractKeycloakTest(
> AbstractKeycloakTest.java:178)
> >
> > When this happened, I saw the other test methods fail with empty NPE
> > like for you.
> >
> > I've fixed it in latest master by making the class TestCleanup
> > thread-safe. Hopefully this will fix your issue too. Sorry for troubles
> > as thread-unsafe TestCleanup was my fault :(
> >
> > BTV. Some concurrency tests like BruteForceTest or ComponentsTest still
> > have issues because of H2 locks. I can sometimes simulate on my laptop
> > and seeing that they sometime fails on travis too. But that's separate
> > issue and hopefully it's just specific to H2.
> >
> > Marek
> >
> >
> > On 16/06/17 23:36, Bill Burke wrote:
> >> I performed the following in integration-arquillian testsuite
> >>
> >> mvn -Dkeycloak.logging.level=debug clean install > out.txt 2>&1
> >>
> >> My test is failing in AbstractKeycloakTest.afterAbstractKeycloakTest
> >> while running TestCleanup loop.  I'm getting a NullPointerException but
> >> I can't seem to get the testsuite to output the stack trace.  I do see
> >> info level logs from this class, but no stack trace.  Even if I add a
> >> exception.printStackTrace(). The stack trace is empty.
> >>
> >> Any ideas?  This popped up before but just magically disappeared.  Now
> >> its back.  The test failure only comes up in a full maven build.  Can't
> >> reproduce in IDE.
> >>
> >> 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
>
>
>
> --
>
> --Hynek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Jun 22 02:58:07 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 22 Jun 2017 08:58:07 +0200
Subject: [keycloak-dev] Keycloak 3.2 release (and WildFly 11)
Message-ID: <CAJgngAcP+LVZRP4-0h7ZCzkx3BZi+xppzCDiF9tK_S2W5k6pUQ@mail.gmail.com>

The plan was to wait for WildFly 11, but it has been delayed significantly.
The new plan is to go back to WildFly 10 and release Keycloak 3.2 CR1 late
next week or early the following week.

From sjoerd.cranen at teampicnic.com  Fri Jun 23 09:08:34 2017
From: sjoerd.cranen at teampicnic.com (Sjoerd Cranen)
Date: Fri, 23 Jun 2017 15:08:34 +0200
Subject: [keycloak-dev] Cookie token storage for Spring Security
Message-ID: <CAMHuGfrfsXVpio6v=bN3L5fX_-cmkA4rp7m6QbxPJ22LtYFq9g@mail.gmail.com>

Hi all,

It seems that "token-store: cookie" is not implemented for the Spring
Security adapter. I would be happy to have a go at it, if nobody objects.

One thing I'm wondering is why the cookie path for the adapter state cookie
is always set to the context root in CookieTokenStore. In particular, it
would seem that if I change the Spring Security adapter in a
straightforward way to store the cookies, the cookie would always be set on
"/sso", which would not be very useful.

A second question I had is about the redirect after login. Currently the
redirect location is stored in the HTTP session. Since you would typically
enable "token-store: cookie" to get rid of HTTP sessions, that would also
have to change. I couldn't really figure out how other adapters were doing
this, and I don't have the time at the moment to experiment with the other
adapters to see what happens; if someone could give me some pointers then
that would be very helpful.

Best regards,
Sjoerd Cranen

From hmlnarik at redhat.com  Fri Jun 23 09:10:58 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 23 Jun 2017 15:10:58 +0200
Subject: [keycloak-dev] Rehash password after each login
Message-ID: <CAMvXD=Hxni4h9FSzo9Ob3mwrb2D+GhjH_QGt2M4N62EqpgX3zQ@mail.gmail.com>

The o.k.credential.PasswordCredentialProvider.isValid() method in its
end [1] rehashes and stores the credentials upon successful
authentication. This has benefits in that whenever hashing algorithm
or policy changes (e.g. number of iterations), after a login the user
password would be stored again. If nothing changes, the password is at
least rehashed with another salt. Actually, as the password
policy/algorithm usually does not change too often, it also induces
unnecessary network traffic: because a user invalidation sent to other
nodes in cluster (and other DCs) after each successful login.

One way to mitigate the issue is to invalidate the current encoded
password only if the variant encoded using the same salt as original
password and current password policy is different to the stored one.
If occasional rehashing would be a must, it would be possible to
update credentials after login with new hash only once in a given
period of time (e.g. at most weekly, this can be determined from the
password created date).

WDYT?

--Hynek

[1] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/credential/PasswordCredentialProvider.java#L210-L215

From grossws at gmail.com  Fri Jun 23 12:08:40 2017
From: grossws at gmail.com (Konstantin Gribov)
Date: Fri, 23 Jun 2017 16:08:40 +0000
Subject: [keycloak-dev] Cookie token storage for Spring Security
In-Reply-To: <CAMHuGfrfsXVpio6v=bN3L5fX_-cmkA4rp7m6QbxPJ22LtYFq9g@mail.gmail.com>
References: <CAMHuGfrfsXVpio6v=bN3L5fX_-cmkA4rp7m6QbxPJ22LtYFq9g@mail.gmail.com>
Message-ID: <CALvb29z895yGf0wk9-PNV78uxxv9oR8Um6XKPVEPeMbpuSJn+A@mail.gmail.com>

On Fri, Jun 23, 2017 at 4:46 PM Sjoerd Cranen <sjoerd.cranen at teampicnic.com>
wrote:

> One thing I'm wondering is why the cookie path for the adapter state cookie
> is always set to the context root in CookieTokenStore. In particular, it
> would seem that if I change the Spring Security adapter in a
> straightforward way to store the cookies, the cookie would always be set on
> "/sso", which would not be very useful.
>
Same applies for Jetty adapter. But it doesn't work now (see KEYCLOAK-2514).

-- 

Best regards,
Konstantin Gribov

From sthorger at redhat.com  Mon Jun 26 02:28:30 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jun 2017 08:28:30 +0200
Subject: [keycloak-dev] Rehash password after each login
In-Reply-To: <CAMvXD=Hxni4h9FSzo9Ob3mwrb2D+GhjH_QGt2M4N62EqpgX3zQ@mail.gmail.com>
References: <CAMvXD=Hxni4h9FSzo9Ob3mwrb2D+GhjH_QGt2M4N62EqpgX3zQ@mail.gmail.com>
Message-ID: <CAJgngAdW966StGAAwob1Ctg=NO95MvPiZTGGxebEHRNhmST=fg@mail.gmail.com>

Passwords should only be rehashed if the algorithm or hashing iterations
change. They should not be re-hashed periodically and certainly for every
login. This is a bug.

On 23 June 2017 at 15:10, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> The o.k.credential.PasswordCredentialProvider.isValid() method in its
> end [1] rehashes and stores the credentials upon successful
> authentication. This has benefits in that whenever hashing algorithm
> or policy changes (e.g. number of iterations), after a login the user
> password would be stored again. If nothing changes, the password is at
> least rehashed with another salt. Actually, as the password
> policy/algorithm usually does not change too often, it also induces
> unnecessary network traffic: because a user invalidation sent to other
> nodes in cluster (and other DCs) after each successful login.
>
> One way to mitigate the issue is to invalidate the current encoded
> password only if the variant encoded using the same salt as original
> password and current password policy is different to the stored one.
> If occasional rehashing would be a must, it would be possible to
> update credentials after login with new hash only once in a given
> period of time (e.g. at most weekly, this can be determined from the
> password created date).
>
> WDYT?
>
> --Hynek
>
> [1] https://github.com/keycloak/keycloak/blob/master/services/
> src/main/java/org/keycloak/credential/PasswordCredentialProvider.
> java#L210-L215
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Jun 26 02:30:12 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jun 2017 08:30:12 +0200
Subject: [keycloak-dev] Moving ClientInitialAccessModel from infinispan
	to db
In-Reply-To: <1b80c983-cb0a-69a8-e237-70aca646e0b8@redhat.com>
References: <1b80c983-cb0a-69a8-e237-70aca646e0b8@redhat.com>
Message-ID: <CAJgngAej2ku_g2auqc==-zcNvtnQhGy9+_ZnaNR=8fhmb0wGDA@mail.gmail.com>

Sounds good

+1 To not import/export and no caching. We can re-consider import/export if
anyone asks about it.

On 21 June 2017 at 22:32, Marek Posolda <mposolda at redhat.com> wrote:

> I've sent PR https://github.com/keycloak/keycloak/pull/4248 for move
> ClientInitialAccessModel from userSessionProvider (infinispan) to realm
> model (db). This has advantages like:
>
> - Client initial access tokens will remain persistent among server restarts
> - There won't be issues in cross-dc environment
>
> Regarding functionality, nothing is changed. Admin console and admin
> REST endpoints are still the same behaviour. There is still decrease of
> remainingCount during each client registration like was before. Only
> change is, that server restarts will just work :)
>
> I didn't add support for export/import of client initial access token
> models. Was thinking about possible issues like:
> - admin creates the initial token with 3 counters
> - Export is done
> - Then token is used to register 3 clients, which defacto make the token
> expired
> - After realm re-import, the token will be back again with 3 attempts,
> which is likely not what admin wants.
>
> Also I didn't add support for caching. Reason is, that there is just
> small amount of tokens. Also there is almost same amount of writes and
> reads to ClientInitialAccessModel as every client registration needs to
> decrease counter and update DB. With caching enabled, there will be lots
> of additional overhead needed to send invalidation message to all
> cluster nodes in all DCs during every write, which likely won't help
> with performance, but rather the opposite.


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

From hmlnarik at redhat.com  Mon Jun 26 06:03:36 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 26 Jun 2017 12:03:36 +0200
Subject: [keycloak-dev] Rehash password after each login
In-Reply-To: <CAJgngAdW966StGAAwob1Ctg=NO95MvPiZTGGxebEHRNhmST=fg@mail.gmail.com>
References: <CAMvXD=Hxni4h9FSzo9Ob3mwrb2D+GhjH_QGt2M4N62EqpgX3zQ@mail.gmail.com>
	<CAJgngAdW966StGAAwob1Ctg=NO95MvPiZTGGxebEHRNhmST=fg@mail.gmail.com>
Message-ID: <CAMvXD=G+xs0UJ4kqH2mqCy_3oMB-z9VydiGNjsCjv8rm5HGN+A@mail.gmail.com>

Created https://issues.jboss.org/browse/KEYCLOAK-5090

On Mon, Jun 26, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Passwords should only be rehashed if the algorithm or hashing iterations
> change. They should not be re-hashed periodically and certainly for every
> login. This is a bug.
>
> On 23 June 2017 at 15:10, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> The o.k.credential.PasswordCredentialProvider.isValid() method in its
>> end [1] rehashes and stores the credentials upon successful
>> authentication. This has benefits in that whenever hashing algorithm
>> or policy changes (e.g. number of iterations), after a login the user
>> password would be stored again. If nothing changes, the password is at
>> least rehashed with another salt. Actually, as the password
>> policy/algorithm usually does not change too often, it also induces
>> unnecessary network traffic: because a user invalidation sent to other
>> nodes in cluster (and other DCs) after each successful login.
>>
>> One way to mitigate the issue is to invalidate the current encoded
>> password only if the variant encoded using the same salt as original
>> password and current password policy is different to the stored one.
>> If occasional rehashing would be a must, it would be possible to
>> update credentials after login with new hash only once in a given
>> period of time (e.g. at most weekly, this can be determined from the
>> password created date).
>>
>> WDYT?
>>
>> --Hynek
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/credential/PasswordCredentialProvider.java#L210-L215
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 

--Hynek

From Sebastian.Schuster at bosch-si.com  Mon Jun 26 07:41:39 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Mon, 26 Jun 2017 11:41:39 +0000
Subject: [keycloak-dev] Usage of "aud" claim in access tokens
Message-ID: <e731c23445a149569220dc7011432630@FE-MBX1028.de.bosch.com>

Hi everybody,

While playing around with the authorization api and the photoz example I noticed the aud claim in the access token contained the client_id of the RP similar to the ID token. This was not quite what I expected. The client is the intended consumer of the ID token as per spec: ?Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.? So everything is fine here.

The consumer of the access token is in my opinion the resource server granting access based on content of the access token (in the case of opaque tokens, the client can?t even read the access token). Per JWT spec: ?The "aud" (audience) claim identifies the recipients that the JWT is intended for.  Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim then this claim is present, then the JWT MUST be rejected.?

Therefore, for my access token of the photos example having the client id in the ?aud? claim:
{
  "jti": "ad02bc48-ee9c-4480-b8d2-ca57547c8026",
  "exp": 1498475985,
  "nbf": 0,
  "iat": 1498475685,
  "iss": "http://localhost:8180/auth/realms/photoz",
  "aud": "photoz-html5-client",
  "sub": "73c303f1-7088-4f09-85c3-bd39a736c833",
  "typ": "Bearer",
  "azp": "photoz-html5-client",
  "nonce": "02df304b-199b-4dd8-923d-9cf470d1129a",
  "auth_time": 1498475685,
  "session_state": "e202b205-15bd-43c8-9fbd-cd602d0708f0",
  "acr": "1",
  "allowed-origins": [
    "*"
  ],
  "realm_access": {
    "roles": [
      "uma_authorization",
      "user"
    ]
  },
  "resource_access": {
    "photoz-restful-api": {
      "roles": [
        "manage-albums"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "name": "Alice In Chains",
  "preferred_username": "alice",
  "given_name": "Alice",
  "family_name": "In Chains",
  "email": "alice at keycloak.org"
}

I would have expected an audience claim like ?aud?:[?photoz-restful-api?, ?account?, ?http://localhost:8180/auth/realms/photoz?] (the first two for the resource servers defining the roles, the last one for the entire realm and the realm roles).

What do you think?

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 | 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 pnalyvayko at agi.com  Mon Jun 26 11:13:30 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Mon, 26 Jun 2017 15:13:30 +0000
Subject: [keycloak-dev] Usage of "aud" claim in access tokens
In-Reply-To: <e731c23445a149569220dc7011432630@FE-MBX1028.de.bosch.com>
References: <e731c23445a149569220dc7011432630@FE-MBX1028.de.bosch.com>
Message-ID: <DM5PR07MB2937BBB928AC481F607C3107DADF0@DM5PR07MB2937.namprd07.prod.outlook.com>

Hey Sebastian,

According to OIDC spec (http://openid.net/specs/openid-connect-core-1_0.html):

ID Token
  aud
     REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.
"
Unless I am misinterpreting the spec, the "aud" claim is expected to contain the client_id, no?

Regards,
Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Schuster Sebastian (INST/ESY1) [Sebastian.Schuster at bosch-si.com]
Sent: Monday, June 26, 2017 7:41 AM
To: keycloak-dev
Subject: [keycloak-dev] Usage of "aud" claim in access tokens

Hi everybody,

While playing around with the authorization api and the photoz example I noticed the aud claim in the access token contained the client_id of the RP similar to the ID token. This was not quite what I expected. The client is the intended consumer of the ID token as per spec: ?Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.? So everything is fine here.

The consumer of the access token is in my opinion the resource server granting access based on content of the access token (in the case of opaque tokens, the client can?t even read the access token). Per JWT spec: ?The "aud" (audience) claim identifies the recipients that the JWT is intended for.  Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim then this claim is present, then the JWT MUST be rejected.?

Therefore, for my access token of the photos example having the client id in the ?aud? claim:
{
  "jti": "ad02bc48-ee9c-4480-b8d2-ca57547c8026",
  "exp": 1498475985,
  "nbf": 0,
  "iat": 1498475685,
  "iss": "http://localhost:8180/auth/realms/photoz",
  "aud": "photoz-html5-client",
  "sub": "73c303f1-7088-4f09-85c3-bd39a736c833",
  "typ": "Bearer",
  "azp": "photoz-html5-client",
  "nonce": "02df304b-199b-4dd8-923d-9cf470d1129a",
  "auth_time": 1498475685,
  "session_state": "e202b205-15bd-43c8-9fbd-cd602d0708f0",
  "acr": "1",
  "allowed-origins": [
    "*"
  ],
  "realm_access": {
    "roles": [
      "uma_authorization",
      "user"
    ]
  },
  "resource_access": {
    "photoz-restful-api": {
      "roles": [
        "manage-albums"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "name": "Alice In Chains",
  "preferred_username": "alice",
  "given_name": "Alice",
  "family_name": "In Chains",
  "email": "alice at keycloak.org"
}

I would have expected an audience claim like ?aud?:[?photoz-restful-api?, ?account?, ?http://localhost:8180/auth/realms/photoz?] (the first two for the resource servers defining the roles, the last one for the entire realm and the realm roles).

What do you think?

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 | 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



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


From pnalyvayko at agi.com  Mon Jun 26 11:14:55 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Mon, 26 Jun 2017 15:14:55 +0000
Subject: [keycloak-dev] Usage of "aud" claim in access tokens
In-Reply-To: <DM5PR07MB2937BBB928AC481F607C3107DADF0@DM5PR07MB2937.namprd07.prod.outlook.com>
References: <e731c23445a149569220dc7011432630@FE-MBX1028.de.bosch.com>,
	<DM5PR07MB2937BBB928AC481F607C3107DADF0@DM5PR07MB2937.namprd07.prod.outlook.com>
Message-ID: <DM5PR07MB2937D33B328BB479356B7078DADF0@DM5PR07MB2937.namprd07.prod.outlook.com>

Never mind, you did mention the ID token
________________________________________
From: Nalyvayko, Peter
Sent: Monday, June 26, 2017 11:13 AM
To: Schuster Sebastian (INST/ESY1); keycloak-dev
Subject: RE: Usage of "aud" claim in access tokens

Hey Sebastian,

According to OIDC spec (http://openid.net/specs/openid-connect-core-1_0.html):

ID Token
  aud
     REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.
"
Unless I am misinterpreting the spec, the "aud" claim is expected to contain the client_id, no?

Regards,
Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Schuster Sebastian (INST/ESY1) [Sebastian.Schuster at bosch-si.com]
Sent: Monday, June 26, 2017 7:41 AM
To: keycloak-dev
Subject: [keycloak-dev] Usage of "aud" claim in access tokens

Hi everybody,

While playing around with the authorization api and the photoz example I noticed the aud claim in the access token contained the client_id of the RP similar to the ID token. This was not quite what I expected. The client is the intended consumer of the ID token as per spec: ?Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value.? So everything is fine here.

The consumer of the access token is in my opinion the resource server granting access based on content of the access token (in the case of opaque tokens, the client can?t even read the access token). Per JWT spec: ?The "aud" (audience) claim identifies the recipients that the JWT is intended for.  Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim then this claim is present, then the JWT MUST be rejected.?

Therefore, for my access token of the photos example having the client id in the ?aud? claim:
{
  "jti": "ad02bc48-ee9c-4480-b8d2-ca57547c8026",
  "exp": 1498475985,
  "nbf": 0,
  "iat": 1498475685,
  "iss": "http://localhost:8180/auth/realms/photoz",
  "aud": "photoz-html5-client",
  "sub": "73c303f1-7088-4f09-85c3-bd39a736c833",
  "typ": "Bearer",
  "azp": "photoz-html5-client",
  "nonce": "02df304b-199b-4dd8-923d-9cf470d1129a",
  "auth_time": 1498475685,
  "session_state": "e202b205-15bd-43c8-9fbd-cd602d0708f0",
  "acr": "1",
  "allowed-origins": [
    "*"
  ],
  "realm_access": {
    "roles": [
      "uma_authorization",
      "user"
    ]
  },
  "resource_access": {
    "photoz-restful-api": {
      "roles": [
        "manage-albums"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "name": "Alice In Chains",
  "preferred_username": "alice",
  "given_name": "Alice",
  "family_name": "In Chains",
  "email": "alice at keycloak.org"
}

I would have expected an audience claim like ?aud?:[?photoz-restful-api?, ?account?, ?http://localhost:8180/auth/realms/photoz?] (the first two for the resource servers defining the roles, the last one for the entire realm and the realm roles).

What do you think?

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 | 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



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


From bburke at redhat.com  Mon Jun 26 13:38:28 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jun 2017 13:38:28 -0400
Subject: [keycloak-dev] fine grain permissions merged
Message-ID: <35df17ff-a9d5-7aeb-74d9-42440071ad2c@redhat.com>

See

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


It its currently limited to single realm administration.  Can't define 
master realm fine grain permissions.  It was too much of a pain.  Also 
fixed the long standing issue of when admin with manage-users role could 
upgrade their management permissions. I'll be working on documentation 
in the next week or so and will get something in by 3.2 Final.

Regards,

Bill


From psilva at redhat.com  Mon Jun 26 13:43:29 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 26 Jun 2017 14:43:29 -0300
Subject: [keycloak-dev] Usage of "aud" claim in access tokens
In-Reply-To: <e731c23445a149569220dc7011432630@FE-MBX1028.de.bosch.com>
References: <e731c23445a149569220dc7011432630@FE-MBX1028.de.bosch.com>
Message-ID: <CAJrcDBeQAt1jGv5vBLk7rbCW244RAuQX9QnkqP7eSPAp7amPUg@mail.gmail.com>

+1. https://issues.jboss.org/browse/KEYCLOAK-5095.

On Mon, Jun 26, 2017 at 8:41 AM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi everybody,
>
> While playing around with the authorization api and the photoz example I
> noticed the aud claim in the access token contained the client_id of the RP
> similar to the ID token. This was not quite what I expected. The client is
> the intended consumer of the ID token as per spec: ?Audience(s) that this
> ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the
> Relying Party as an audience value.? So everything is fine here.
>
> The consumer of the access token is in my opinion the resource server
> granting access based on content of the access token (in the case of opaque
> tokens, the client can?t even read the access token). Per JWT spec: ?The
> "aud" (audience) claim identifies the recipients that the JWT is intended
> for.  Each principal intended to process the JWT MUST identify itself with
> a value in the audience claim. If the principal processing the claim does
> not identify itself with a value in the "aud" claim then this claim is
> present, then the JWT MUST be rejected.?
>
> Therefore, for my access token of the photos example having the client id
> in the ?aud? claim:
> {
>   "jti": "ad02bc48-ee9c-4480-b8d2-ca57547c8026",
>   "exp": 1498475985,
>   "nbf": 0,
>   "iat": 1498475685,
>   "iss": "http://localhost:8180/auth/realms/photoz",
>   "aud": "photoz-html5-client",
>   "sub": "73c303f1-7088-4f09-85c3-bd39a736c833",
>   "typ": "Bearer",
>   "azp": "photoz-html5-client",
>   "nonce": "02df304b-199b-4dd8-923d-9cf470d1129a",
>   "auth_time": 1498475685,
>   "session_state": "e202b205-15bd-43c8-9fbd-cd602d0708f0",
>   "acr": "1",
>   "allowed-origins": [
>     "*"
>   ],
>   "realm_access": {
>     "roles": [
>       "uma_authorization",
>       "user"
>     ]
>   },
>   "resource_access": {
>     "photoz-restful-api": {
>       "roles": [
>         "manage-albums"
>       ]
>     },
>     "account": {
>       "roles": [
>         "manage-account",
>         "manage-account-links",
>         "view-profile"
>       ]
>     }
>   },
>   "name": "Alice In Chains",
>   "preferred_username": "alice",
>   "given_name": "Alice",
>   "family_name": "In Chains",
>   "email": "alice at keycloak.org"
> }
>
> I would have expected an audience claim like ?aud?:[?photoz-restful-api?,
> ?account?, ?http://localhost:8180/auth/realms/photoz?] (the first two for
> the resource servers defining the roles, the last one for the entire realm
> and the realm roles).
>
> What do you think?
>
> 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 | 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
>
>
>
> _______________________________________________
> 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  Mon Jun 26 20:50:58 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 27 Jun 2017 00:50:58 +0000
Subject: [keycloak-dev] fine grain permissions merged
In-Reply-To: <35df17ff-a9d5-7aeb-74d9-42440071ad2c@redhat.com>
References: <35df17ff-a9d5-7aeb-74d9-42440071ad2c@redhat.com>
Message-ID: <CAOqetn8ePm+hSx42qQePDzarufv4pv9dOscfd2bqPurKJ+rvKw@mail.gmail.com>

Bill,

Just wondering, does this mean the performance issues previously identified
aren't included?

John

On Mon, Jun 26, 2017 at 8:18 PM Bill Burke <bburke at redhat.com> wrote:

> See
>
> https://issues.jboss.org/browse/KEYCLOAK-3444
>
>
> It its currently limited to single realm administration.  Can't define
> master realm fine grain permissions.  It was too much of a pain.  Also
> fixed the long standing issue of when admin with manage-users role could
> upgrade their management permissions. I'll be working on documentation
> in the next week or so and will get something in by 3.2 Final.
>
> Regards,
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Mon Jun 26 22:40:42 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jun 2017 22:40:42 -0400
Subject: [keycloak-dev] fine grain permissions merged
In-Reply-To: <CAOqetn8ePm+hSx42qQePDzarufv4pv9dOscfd2bqPurKJ+rvKw@mail.gmail.com>
References: <35df17ff-a9d5-7aeb-74d9-42440071ad2c@redhat.com>
	<CAOqetn8ePm+hSx42qQePDzarufv4pv9dOscfd2bqPurKJ+rvKw@mail.gmail.com>
Message-ID: <679b8f6d-3bf7-a86f-054e-ec1fed04b5ea@redhat.com>

NO idea what you're talking about.


On 6/26/17 8:50 PM, John D. Ament wrote:
> Bill,
>
> Just wondering, does this mean the performance issues previously 
> identified aren't included?
>
> John
>
> On Mon, Jun 26, 2017 at 8:18 PM Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     See
>
>     https://issues.jboss.org/browse/KEYCLOAK-3444
>
>
>     It its currently limited to single realm administration. Can't define
>     master realm fine grain permissions.  It was too much of a pain.  Also
>     fixed the long standing issue of when admin with manage-users role
>     could
>     upgrade their management permissions. I'll be working on documentation
>     in the next week or so and will get something in by 3.2 Final.
>
>     Regards,
>
>     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
>


From bburke at redhat.com  Mon Jun 26 22:43:01 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jun 2017 22:43:01 -0400
Subject: [keycloak-dev] fine grain permissions merged
In-Reply-To: <CAOqetn8ePm+hSx42qQePDzarufv4pv9dOscfd2bqPurKJ+rvKw@mail.gmail.com>
References: <35df17ff-a9d5-7aeb-74d9-42440071ad2c@redhat.com>
	<CAOqetn8ePm+hSx42qQePDzarufv4pv9dOscfd2bqPurKJ+rvKw@mail.gmail.com>
Message-ID: <b5c3db2b-f633-b1f2-c492-085e7f2d6b9f@redhat.com>

Oh yeah, I forgot one thing.  Tokens generated for admin_cli and 
security-admin-console no longer have any roles within them. Admin REST 
API now checks the "aud" claim and doesn't look in token for roles 
anymore if the "aud" is admin_cli or admin-console.  Don't know if 
that's what you mean.


On 6/26/17 8:50 PM, John D. Ament wrote:
> Bill,
>
> Just wondering, does this mean the performance issues previously 
> identified aren't included?
>
> John
>
> On Mon, Jun 26, 2017 at 8:18 PM Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     See
>
>     https://issues.jboss.org/browse/KEYCLOAK-3444
>
>
>     It its currently limited to single realm administration. Can't define
>     master realm fine grain permissions.  It was too much of a pain.  Also
>     fixed the long standing issue of when admin with manage-users role
>     could
>     upgrade their management permissions. I'll be working on documentation
>     in the next week or so and will get something in by 3.2 Final.
>
>     Regards,
>
>     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
>


From john.d.ament at gmail.com  Mon Jun 26 22:43:39 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 27 Jun 2017 02:43:39 +0000
Subject: [keycloak-dev] fine grain permissions merged
In-Reply-To: <679b8f6d-3bf7-a86f-054e-ec1fed04b5ea@redhat.com>
References: <35df17ff-a9d5-7aeb-74d9-42440071ad2c@redhat.com>
	<CAOqetn8ePm+hSx42qQePDzarufv4pv9dOscfd2bqPurKJ+rvKw@mail.gmail.com>
	<679b8f6d-3bf7-a86f-054e-ec1fed04b5ea@redhat.com>
Message-ID: <CAOqetn_b94JKU4iWCdpFP1A2K0KrqBr4sF-oL7sgBcG4O-dPJg@mail.gmail.com>

http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009468.html may help
jog your memory :-)



On Mon, Jun 26, 2017 at 10:40 PM Bill Burke <bburke at redhat.com> wrote:

> NO idea what you're talking about.
>
> On 6/26/17 8:50 PM, John D. Ament wrote:
>
> Bill,
>
> Just wondering, does this mean the performance issues previously
> identified aren't included?
>
> John
>
> On Mon, Jun 26, 2017 at 8:18 PM Bill Burke <bburke at redhat.com> wrote:
>
>> See
>>
>> https://issues.jboss.org/browse/KEYCLOAK-3444
>>
>>
>> It its currently limited to single realm administration.  Can't define
>> master realm fine grain permissions.  It was too much of a pain.  Also
>> fixed the long standing issue of when admin with manage-users role could
>> upgrade their management permissions. I'll be working on documentation
>> in the next week or so and will get something in by 3.2 Final.
>>
>> Regards,
>>
>> Bill
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Tue Jun 27 02:43:56 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 08:43:56 +0200
Subject: [keycloak-dev] Review Japanese PR
Message-ID: <CAJgngAcUGLbR-yA1GE_VfTYe87N_JzCqUrJY5QQT1ev0KpHYRg@mail.gmail.com>

There's a PR for fixes to the Japanese translations. Could someone review
it please?

https://github.com/keycloak/keycloak/pull/4245

From sthorger at redhat.com  Tue Jun 27 02:45:20 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 08:45:20 +0200
Subject: [keycloak-dev] Review German PR
Message-ID: <CAJgngAdwHZ-Cz4KMBoN6XbjnyvEkuMBybCN-r3u18K5+EDk9vQ@mail.gmail.com>

Can someone please review fixes to the German translations in PR
https://github.com/keycloak/keycloak/pull/4234?

From takashi.norimatsu.ws at hitachi.com  Tue Jun 27 02:54:37 2017
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Tue, 27 Jun 2017 06:54:37 +0000
Subject: [keycloak-dev] Proposal of using existing authentication server
 on behalf of keycloak browser-based authentication
In-Reply-To: <831D472326678942A9B4BB933AAA103D25F97452@GSjpTK1DCembx01.service.hitachi.net>
References: <831D472326678942A9B4BB933AAA103D25F97452@GSjpTK1DCembx01.service.hitachi.net>
Message-ID: <831D472326678942A9B4BB933AAA103D68C9439D@GSjpTK1DCembx01.service.hitachi.net>

Hello.

Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism.

I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260).
Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak.

Detailed description of this feature is mentioned below.
https://github.com/Hitachi/PoV-keycloak-authentication-delegation

I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem?

[Problem]
- I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases.

After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.


From wim.vandenhaute at gmail.com  Tue Jun 27 03:03:56 2017
From: wim.vandenhaute at gmail.com (Wim Vandenhaute)
Date: Tue, 27 Jun 2017 07:03:56 +0000
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin API
Message-ID: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>

Hello list,

Via an admin portal of a customer I am working for, they provide a feature
where an admin can edit the user's data, including setting a new password.

For the sake of atomicity, all update steps first go through a series of
validations for all modified data before actually committing the changes
and (if needed) updating the keycloak password

At the moment, there is no way to pre-update do a validity check of the
updated password against keycloak's configured password policy(ies)

Therefor I would propose to have a validate-password endpoint in the Admin
API.

I've made a pull request already here:
  *  https://github.com/keycloak/keycloak/pull/4229

Any thoughts on this?

Kind regards,
Wim

From sthorger at redhat.com  Tue Jun 27 04:43:36 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 10:43:36 +0200
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
	API
In-Reply-To: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
Message-ID: <CAJgngAdHy1tK08sKoQb5uHkqJnZSgHhTiGkgAQinNWb-80Q_ng@mail.gmail.com>

I think the flow of allowing admins to set the users passwords are a bit
broken in the first place. No-one should know a users password, but
themselves. A better flow would be to send a password-reset link to users
through email and let them set the initial password themselves.

However, I can see that might not work for everyone so I don't feel to
strongly about not accepting this change. Let's see what others think about
it.

On 27 June 2017 at 09:03, Wim Vandenhaute <wim.vandenhaute at gmail.com> wrote:

> Hello list,
>
> Via an admin portal of a customer I am working for, they provide a feature
> where an admin can edit the user's data, including setting a new password.
>
> For the sake of atomicity, all update steps first go through a series of
> validations for all modified data before actually committing the changes
> and (if needed) updating the keycloak password
>
> At the moment, there is no way to pre-update do a validity check of the
> updated password against keycloak's configured password policy(ies)
>
> Therefor I would propose to have a validate-password endpoint in the Admin
> API.
>
> I've made a pull request already here:
>   *  https://github.com/keycloak/keycloak/pull/4229
>
> Any thoughts on this?
>
> Kind regards,
> Wim
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Jun 27 04:51:49 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 10:51:49 +0200
Subject: [keycloak-dev] Proposal of using existing authentication server
 on behalf of keycloak browser-based authentication
In-Reply-To: <831D472326678942A9B4BB933AAA103D68C9439D@GSjpTK1DCembx01.service.hitachi.net>
References: <831D472326678942A9B4BB933AAA103D25F97452@GSjpTK1DCembx01.service.hitachi.net>
	<831D472326678942A9B4BB933AAA103D68C9439D@GSjpTK1DCembx01.service.hitachi.net>
Message-ID: <CAJgngAfVrn3fZkhLTdA_+9rEtq7=hxq8VQX2toGC880LFBE1cw@mail.gmail.com>

I'm not in favour of adding this. If it's using redirect based
authentication flows it should be done through identity brokering, not
authentication flows. It's also a very complex example that we don't want
to maintain. We've also in the process of moving all examples away from the
main Keycloak repository into a separate quickstart repository.

On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> Hello.
>
> Previously, I had proposed the feature of delegating authentication to an
> external authentication server on behalf of keycloak's browser-based
> authentication mechanism.
>
> I've integrated this feature to keycloak's "examples" packages and send PR
> (https://github.com/keycloak/keycloak/pull/4260).
> Hope this PR is reviewed and merged as an example for combining some
> providers to customize keycloak.
>
> Detailed description of this feature is mentioned below.
> https://github.com/Hitachi/PoV-keycloak-authentication-delegation
>
> I am now engaging in integrating this feature to keycloak as product-base
> default providers, but encounter technical problems about writing
> arquillian. Would someone tell me how to resolve this problem?
>
> [Problem]
> - I could not find how to run an external authentication
> server(application running on wildfly 10) during each arquillian test cases.
>
> After resolving this problem and writing and running arquillian test
> cases, I'll send PR for this feature as product-base default providers.
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mhatanak at redhat.com  Tue Jun 27 04:53:20 2017
From: mhatanak at redhat.com (Masanobu Hatanaka)
Date: Tue, 27 Jun 2017 17:53:20 +0900
Subject: [keycloak-dev] [keycloak-user] Review Japanese PR
In-Reply-To: <CAJgngAcUGLbR-yA1GE_VfTYe87N_JzCqUrJY5QQT1ev0KpHYRg@mail.gmail.com>
References: <CAJgngAcUGLbR-yA1GE_VfTYe87N_JzCqUrJY5QQT1ev0KpHYRg@mail.gmail.com>
Message-ID: <9f1782b6-1c64-edad-5f76-d65e646c0b0c@redhat.com>

I will check this request.

Thanks,
Masanobu Hatanaka

On 2017?06?27? 15:43, Stian Thorgersen wrote:
> There's a PR for fixes to the Japanese translations. Could someone review
> it please?
> 
> https://github.com/keycloak/keycloak/pull/4245
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 


From sthorger at redhat.com  Tue Jun 27 07:27:24 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 13:27:24 +0200
Subject: [keycloak-dev] [keycloak-user] Review Japanese PR
In-Reply-To: <9f1782b6-1c64-edad-5f76-d65e646c0b0c@redhat.com>
References: <CAJgngAcUGLbR-yA1GE_VfTYe87N_JzCqUrJY5QQT1ev0KpHYRg@mail.gmail.com>
	<9f1782b6-1c64-edad-5f76-d65e646c0b0c@redhat.com>
Message-ID: <CAJgngAfFxJxuPFn+m66J64Qb1k=FbLwRnkqzX=v+XkSh5aJnmg@mail.gmail.com>

Thanks. Just add a comment to the PR if it's OK or not.

On 27 June 2017 at 10:53, Masanobu Hatanaka <mhatanak at redhat.com> wrote:

> I will check this request.
>
> Thanks,
> Masanobu Hatanaka
>
> On 2017?06?27? 15:43, Stian Thorgersen wrote:
> > There's a PR for fixes to the Japanese translations. Could someone review
> > it please?
> >
> > https://github.com/keycloak/keycloak/pull/4245
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
>

From bruno at abstractj.org  Tue Jun 27 08:10:24 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 27 Jun 2017 09:10:24 -0300
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
 API
In-Reply-To: <CAJgngAdHy1tK08sKoQb5uHkqJnZSgHhTiGkgAQinNWb-80Q_ng@mail.gmail.com>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
	<CAJgngAdHy1tK08sKoQb5uHkqJnZSgHhTiGkgAQinNWb-80Q_ng@mail.gmail.com>
Message-ID: <20170627121024.GA10443@abstractj.org>

I'm 50/50 on this. And I fully agree that no one should know a users
password. On the other hand I understand that might not work for
everyone.

If we move forward with this, we might not just
be increasing the attack surface. But also would enabling people to
do creative things like, store user's password into their database in plain
text.

On 2017-06-27, Stian Thorgersen wrote:
> I think the flow of allowing admins to set the users passwords are a bit
> broken in the first place. No-one should know a users password, but
> themselves. A better flow would be to send a password-reset link to users
> through email and let them set the initial password themselves.
>
> However, I can see that might not work for everyone so I don't feel to
> strongly about not accepting this change. Let's see what others think about
> it.
>
> On 27 June 2017 at 09:03, Wim Vandenhaute <wim.vandenhaute at gmail.com> wrote:
>
> > Hello list,
> >
> > Via an admin portal of a customer I am working for, they provide a feature
> > where an admin can edit the user's data, including setting a new password.
> >
> > For the sake of atomicity, all update steps first go through a series of
> > validations for all modified data before actually committing the changes
> > and (if needed) updating the keycloak password
> >
> > At the moment, there is no way to pre-update do a validity check of the
> > updated password against keycloak's configured password policy(ies)
> >
> > Therefor I would propose to have a validate-password endpoint in the Admin
> > API.
> >
> > I've made a pull request already here:
> >   *  https://github.com/keycloak/keycloak/pull/4229
> >
> > Any thoughts on this?
> >
> > Kind regards,
> > Wim
> > _______________________________________________
> > 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

--

abstractj

From sthorger at redhat.com  Tue Jun 27 08:31:17 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 14:31:17 +0200
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
	API
In-Reply-To: <20170627121024.GA10443@abstractj.org>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
	<CAJgngAdHy1tK08sKoQb5uHkqJnZSgHhTiGkgAQinNWb-80Q_ng@mail.gmail.com>
	<20170627121024.GA10443@abstractj.org>
Message-ID: <CAJgngAcmotid3d-NFWaVgXgb-+4vQx3GAqZH6ZXoWnrG-Ta7MQ@mail.gmail.com>

All this does is allow checking if a password is accepted by the password
policies. That's it. I can't see how that increases any attack surface?

On 27 June 2017 at 14:10, Bruno Oliveira <bruno at abstractj.org> wrote:

> I'm 50/50 on this. And I fully agree that no one should know a users
> password. On the other hand I understand that might not work for
> everyone.
>
> If we move forward with this, we might not just
> be increasing the attack surface. But also would enabling people to
> do creative things like, store user's password into their database in plain
> text.
>
> On 2017-06-27, Stian Thorgersen wrote:
> > I think the flow of allowing admins to set the users passwords are a bit
> > broken in the first place. No-one should know a users password, but
> > themselves. A better flow would be to send a password-reset link to users
> > through email and let them set the initial password themselves.
> >
> > However, I can see that might not work for everyone so I don't feel to
> > strongly about not accepting this change. Let's see what others think
> about
> > it.
> >
> > On 27 June 2017 at 09:03, Wim Vandenhaute <wim.vandenhaute at gmail.com>
> wrote:
> >
> > > Hello list,
> > >
> > > Via an admin portal of a customer I am working for, they provide a
> feature
> > > where an admin can edit the user's data, including setting a new
> password.
> > >
> > > For the sake of atomicity, all update steps first go through a series
> of
> > > validations for all modified data before actually committing the
> changes
> > > and (if needed) updating the keycloak password
> > >
> > > At the moment, there is no way to pre-update do a validity check of the
> > > updated password against keycloak's configured password policy(ies)
> > >
> > > Therefor I would propose to have a validate-password endpoint in the
> Admin
> > > API.
> > >
> > > I've made a pull request already here:
> > >   *  https://github.com/keycloak/keycloak/pull/4229
> > >
> > > Any thoughts on this?
> > >
> > > Kind regards,
> > > Wim
> > > _______________________________________________
> > > 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
>
> --
>
> abstractj
>

From bruno at abstractj.org  Tue Jun 27 08:52:06 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 27 Jun 2017 12:52:06 +0000
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
	API
In-Reply-To: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
Message-ID: <CAM5SUC6w9UnT1CN=A-RCabwVQq4cMQi9MWb_AoYxJ0f1magykQ@mail.gmail.com>

If I understood correctly, the password could be provided here
https://github.com/keycloak/keycloak/pull/4229/files#diff-2d5026806b9f86138813c99521f40597R782,
right? If yes. I could implement my own password validator web app to
validate passwords and interact with KC. Now, instead of worry with the
call between the client and KC server, I could have a third server to worry
about or a shell script. Because it's possible.

Instead of targeting Keycloak only (which is built with security in mind),
now people could target my password validation app (not so concerned with
security). This is just an example, and I'm not saying this is the end of
the world. What I'm saying that this opens a new door for people to be
creative.

On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <wim.vandenhaute at gmail.com>
wrote:

> Hello list,
>
> Via an admin portal of a customer I am working for, they provide a feature
> where an admin can edit the user's data, including setting a new password.
>
> For the sake of atomicity, all update steps first go through a series of
> validations for all modified data before actually committing the changes
> and (if needed) updating the keycloak password
>
> At the moment, there is no way to pre-update do a validity check of the
> updated password against keycloak's configured password policy(ies)
>
> Therefor I would propose to have a validate-password endpoint in the Admin
> API.
>
> I've made a pull request already here:
>   *  https://github.com/keycloak/keycloak/pull/4229
>
> Any thoughts on this?
>
> Kind regards,
> Wim
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From wim.vandenhaute at gmail.com  Tue Jun 27 09:29:48 2017
From: wim.vandenhaute at gmail.com (Wim Vandenhaute)
Date: Tue, 27 Jun 2017 13:29:48 +0000
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
	API
In-Reply-To: <CAM5SUC6w9UnT1CN=A-RCabwVQq4cMQi9MWb_AoYxJ0f1magykQ@mail.gmail.com>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
	<CAM5SUC6w9UnT1CN=A-RCabwVQq4cMQi9MWb_AoYxJ0f1magykQ@mail.gmail.com>
Message-ID: <CAAmmoOqpChO5Mx8QvFBiQOf1KpcKfEJZwFF4wf5rc6mo+GB1hw@mail.gmail.com>

This does not validate the password as in checking if it is the same as the
user's current one but only checks if a new password might violate the
realm's password policies or not so I do not really see an issue here to be
honest.

On Tue, Jun 27, 2017 at 2:52 PM Bruno Oliveira <bruno at abstractj.org> wrote:

> If I understood correctly, the password could be provided here
> https://github.com/keycloak/keycloak/pull/4229/files#diff-2d5026806b9f86138813c99521f40597R782,
> right? If yes. I could implement my own password validator web app to
> validate passwords and interact with KC. Now, instead of worry with the
> call between the client and KC server, I could have a third server to worry
> about or a shell script. Because it's possible.
>
> Instead of targeting Keycloak only (which is built with security in mind),
> now people could target my password validation app (not so concerned with
> security). This is just an example, and I'm not saying this is the end of
> the world. What I'm saying that this opens a new door for people to be
> creative.
>
> On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <wim.vandenhaute at gmail.com>
> wrote:
>
>> Hello list,
>>
>> Via an admin portal of a customer I am working for, they provide a feature
>> where an admin can edit the user's data, including setting a new password.
>>
>> For the sake of atomicity, all update steps first go through a series of
>> validations for all modified data before actually committing the changes
>> and (if needed) updating the keycloak password
>>
>> At the moment, there is no way to pre-update do a validity check of the
>> updated password against keycloak's configured password policy(ies)
>>
>> Therefor I would propose to have a validate-password endpoint in the Admin
>> API.
>>
>> I've made a pull request already here:
>>   *  https://github.com/keycloak/keycloak/pull/4229
>>
>> Any thoughts on this?
>>
>> Kind regards,
>> Wim
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From sthorger at redhat.com  Tue Jun 27 10:00:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jun 2017 16:00:29 +0200
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
	API
In-Reply-To: <CAM5SUC6w9UnT1CN=A-RCabwVQq4cMQi9MWb_AoYxJ0f1magykQ@mail.gmail.com>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
	<CAM5SUC6w9UnT1CN=A-RCabwVQq4cMQi9MWb_AoYxJ0f1magykQ@mail.gmail.com>
Message-ID: <CAJgngAdAsJOZhO055WwxFQvc+uEaAvyor9qZvd5Dx3U8tX3P=w@mail.gmail.com>

I still don't see the door that is being opened. It's just validating if a
password supplied by the potential attacker is good enough to pass our
password policies. I.e. is it long enough and such. It doesn't give any
opportunity to check if it's a real password or update it or anything?

On 27 June 2017 at 14:52, Bruno Oliveira <bruno at abstractj.org> wrote:

> If I understood correctly, the password could be provided here
> https://github.com/keycloak/keycloak/pull/4229/files#diff-
> 2d5026806b9f86138813c99521f40597R782,
> right? If yes. I could implement my own password validator web app to
> validate passwords and interact with KC. Now, instead of worry with the
> call between the client and KC server, I could have a third server to worry
> about or a shell script. Because it's possible.
>
> Instead of targeting Keycloak only (which is built with security in mind),
> now people could target my password validation app (not so concerned with
> security). This is just an example, and I'm not saying this is the end of
> the world. What I'm saying that this opens a new door for people to be
> creative.
>
> On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <wim.vandenhaute at gmail.com
> >
> wrote:
>
> > Hello list,
> >
> > Via an admin portal of a customer I am working for, they provide a
> feature
> > where an admin can edit the user's data, including setting a new
> password.
> >
> > For the sake of atomicity, all update steps first go through a series of
> > validations for all modified data before actually committing the changes
> > and (if needed) updating the keycloak password
> >
> > At the moment, there is no way to pre-update do a validity check of the
> > updated password against keycloak's configured password policy(ies)
> >
> > Therefor I would propose to have a validate-password endpoint in the
> Admin
> > API.
> >
> > I've made a pull request already here:
> >   *  https://github.com/keycloak/keycloak/pull/4229
> >
> > Any thoughts on this?
> >
> > Kind regards,
> > Wim
> > _______________________________________________
> > 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  Tue Jun 27 15:30:15 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 27 Jun 2017 19:30:15 +0000
Subject: [keycloak-dev] Adding a validate password endpoint in the Admin
	API
In-Reply-To: <CAJgngAdAsJOZhO055WwxFQvc+uEaAvyor9qZvd5Dx3U8tX3P=w@mail.gmail.com>
References: <CAAmmoOpNT3LS06jcouZiD4B8uFuLLH3oz2+B-35k8V9hn-izXQ@mail.gmail.com>
	<CAM5SUC6w9UnT1CN=A-RCabwVQq4cMQi9MWb_AoYxJ0f1magykQ@mail.gmail.com>
	<CAJgngAdAsJOZhO055WwxFQvc+uEaAvyor9qZvd5Dx3U8tX3P=w@mail.gmail.com>
Message-ID: <CAM5SUC4ykf_VNS6hL1nbtvz0hDgRJbx1hr6iCR4pxesJ148xSA@mail.gmail.com>

Yep, I understand everything that you said. My argument is based on the
idea that someone could potentially leave this server unprotected (let's
call password validation server), and an attacker intercept/collect these
password to construct a dictionary attack for example. This is pretty much
why I said it increases the attack surface.

Anyways, that's only my 2 cents. Whatever is the best for all, I'm aboard.

On Tue, Jun 27, 2017 at 11:00 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> I still don't see the door that is being opened. It's just validating if a
> password supplied by the potential attacker is good enough to pass our
> password policies. I.e. is it long enough and such. It doesn't give any
> opportunity to check if it's a real password or update it or anything?
>
> On 27 June 2017 at 14:52, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> If I understood correctly, the password could be provided here
>>
>> https://github.com/keycloak/keycloak/pull/4229/files#diff-2d5026806b9f86138813c99521f40597R782
>> ,
>> right? If yes. I could implement my own password validator web app to
>> validate passwords and interact with KC. Now, instead of worry with the
>> call between the client and KC server, I could have a third server to
>> worry
>> about or a shell script. Because it's possible.
>>
>> Instead of targeting Keycloak only (which is built with security in mind),
>> now people could target my password validation app (not so concerned with
>> security). This is just an example, and I'm not saying this is the end of
>> the world. What I'm saying that this opens a new door for people to be
>> creative.
>>
>> On Tue, Jun 27, 2017 at 4:51 AM Wim Vandenhaute <
>> wim.vandenhaute at gmail.com>
>> wrote:
>>
>> > Hello list,
>> >
>> > Via an admin portal of a customer I am working for, they provide a
>> feature
>> > where an admin can edit the user's data, including setting a new
>> password.
>> >
>> > For the sake of atomicity, all update steps first go through a series of
>> > validations for all modified data before actually committing the changes
>> > and (if needed) updating the keycloak password
>> >
>> > At the moment, there is no way to pre-update do a validity check of the
>> > updated password against keycloak's configured password policy(ies)
>> >
>> > Therefor I would propose to have a validate-password endpoint in the
>> Admin
>> > API.
>> >
>> > I've made a pull request already here:
>> >   *  https://github.com/keycloak/keycloak/pull/4229
>> >
>> > Any thoughts on this?
>> >
>> > Kind regards,
>> > Wim
>> > _______________________________________________
>> > 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 Jun 28 02:34:21 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 28 Jun 2017 08:34:21 +0200
Subject: [keycloak-dev] Community extensions and examples
Message-ID: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>

At times there are extensions and examples that we don't want to include in
the main repository. This could be for several reasons, including:

* We don't have the resources to maintain and support it
* We don't believe it's generic enough
* Examples that are to complex

However, these can still be useful for some people. So I'm thinking about
how we can provide community maintained extensions and examples.

A very simple idea would be to add a page on our website that links to the
relevant repository and documentation. To contribute you would setup your
own Github repository, documentation and also a download if you want. Then
you'd send a PR to the website to add your extension or example.

Thoughts?

From mitya at cargosoft.ru  Wed Jun 28 17:31:28 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Thu, 29 Jun 2017 00:31:28 +0300
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
Message-ID: <1498685488.3089.1.camel@cargosoft.ru>

Hi,

Though I'm not a Keycloak dev, I hope the community member's 2? will be
useful nevertheless.

To me that sounds like a great initiative, I myself will be happy to
contribute BeerCloak, an example of how to build complete admin realm
resources while the corresponding SPI is not (yet) implemented.

Off the top of my head, I think we'll need some sort of separation
between examples and extensions because of their (generally) different
use cases. For examples, it's "check it out and hack on it"; for
extensions, "install & use it" (preferably skipping the "checkout" and
"build" phases).

Ideally, there should be something like Atlassian Marketplace, a
registry/repository of extensions (including commercial ones) with one-
click installation. I clearly understand that wouldn't be a top
priority - just sharing my vision.

BTW, speaking about commercial extensions, can we hope on our products
being mentioned somewhere too? I think such a disclosure can make
Keycloak/RHSSO look more valuable in the eyes of potential users and
customers. Our flagship product provides Keycloak support for hardware
OTP tokens with full lifecycle, like bulk import, enrollment,
revocation, audit etc.

The other stuff being developed is:
* HRM integration (sync Keycloak with employee database from HRMs);
* advanced monitoring (collect different Keycloak-specific metrics and
expose them as DMR/JMX);
* OpenID 2.0 (legacy) support;
* identity brokering for VK social network (this and the previous one
most likely will be opensourced).

There are even thoughts on integrating PKI functionality into Keycloak,
which becomes highly topical with the introduction of x509 client cert
auth (thanks Peter!)

Cheers,
Dmitry Telegin
CTO, CargoSoft LLC
http://cargosoft.ru/en/rm/about/

? Wed, 28/06/2017 ? 08:34 +0200, Stian Thorgersen ?????:
> At times there are extensions and examples that we don't want to
> include in
> the main repository. This could be for several reasons, including:
> 
> * We don't have the resources to maintain and support it
> * We don't believe it's generic enough
> * Examples that are to complex
> 
> However, these can still be useful for some people. So I'm thinking
> about
> how we can provide community maintained extensions and examples.
> 
> A very simple idea would be to add a page on our website that links
> to the
> relevant repository and documentation. To contribute you would setup
> your
> own Github repository, documentation and also a download if you want.
> Then
> you'd send a PR to the website to add your extension or example.
> 
> Thoughts?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From liam.maruff at gmail.com  Thu Jun 29 02:15:58 2017
From: liam.maruff at gmail.com (Liam Maruff)
Date: Thu, 29 Jun 2017 16:15:58 +1000
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
Message-ID: <CADh+9ZywCLozzySsAFeK9ZMSuF6LFCCcLUDLhfSDLzQLAjP=yA@mail.gmail.com>

This is a worthwhile discussion, and one I've been thinking about starting.

I'm working with Keycloak on two different projects at the moment. While
doing so, I've written mechanisms for:

1. A REST based storage provider
2. A client-certificate authentication provider, where SSL is terminated at
a reverse proxy and the certificate is provided in a user header. This
differs from the X/509 Validate Username Provider in that it supports an
'optional' mode whereby a user can still login without having provided a
certificate, but is not MFA'ed, and is prompted using a 'required action'.
3. A backup-codes mechanism (integrated with a lot of LDAP stuff that's
organisation specific, but my design have been well received by end users)
4. extensions to the profile application for (2) and (3)

Now, the problem is, in addition to my usual work, I don't have the time to
get involved in the Keycloak project and re-engineer these components so
that they are suitable for inclusion in the main project. However, feedback
from within my organisation and from our customers has led me to conclude
that my ideas are sound.

With a little work from an experienced contributor, I suspect that part of
these providers could be included in the main project. It would be great to
have some place to put these up where they could be given some exposure
and, potentially, scheduled for further work and inclusion by those of you
close to the project.

Regards,

LM


On Wed, Jun 28, 2017 at 4:34 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> At times there are extensions and examples that we don't want to include in
> the main repository. This could be for several reasons, including:
>
> * We don't have the resources to maintain and support it
> * We don't believe it's generic enough
> * Examples that are to complex
>
> However, these can still be useful for some people. So I'm thinking about
> how we can provide community maintained extensions and examples.
>
> A very simple idea would be to add a page on our website that links to the
> relevant repository and documentation. To contribute you would setup your
> own Github repository, documentation and also a download if you want. Then
> you'd send a PR to the website to add your extension or example.
>
> Thoughts?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From takashi.norimatsu.ws at hitachi.com  Thu Jun 29 04:51:54 2017
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Thu, 29 Jun 2017 08:51:54 +0000
Subject: [keycloak-dev] Proposal of using existing authentication server
 on behalf of keycloak browser-based authentication
Message-ID: <831D472326678942A9B4BB933AAA103D68C94D02@GSjpTK1DCembx01.service.hitachi.net>

I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, 
in order to integrate existing authentication system. 
(some commercial products supports such the case)

I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2.
https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html

Therefore, I realized it by using redirect based authentication flows.

Can identity Brokering can support such the case?

Aside from this, I'd like to contribute it to Community extensions and examples.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

---
From: Stian Thorgersen [mailto:sthorger at redhat.com] 
Sent: Tuesday, June 27, 2017 5:52 PM
To: ???? / NORIMATSU?TAKASHI
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication

I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository.

On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
Hello.

Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism.

I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260).
Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak.

Detailed description of this feature is mentioned below.
https://github.com/Hitachi/PoV-keycloak-authentication-delegation

I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem?

[Problem]
- I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases.

After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

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



From sthorger at redhat.com  Thu Jun 29 05:23:20 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jun 2017 11:23:20 +0200
Subject: [keycloak-dev] Proposal of using existing authentication server
 on behalf of keycloak browser-based authentication
In-Reply-To: <831D472326678942A9B4BB933AAA103D68C94D02@GSjpTK1DCembx01.service.hitachi.net>
References: <831D472326678942A9B4BB933AAA103D68C94D02@GSjpTK1DCembx01.service.hitachi.net>
Message-ID: <CAJgngAfTn+0v8WJdFekTR4QQeWyxm7DgT2wMzbyPoQMAhALF1w@mail.gmail.com>

There's an SPI to implement your own custom identity brokering provider [1].

[1]
https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/broker/provider/IdentityProvider.java

On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI <
takashi.norimatsu.ws at hitachi.com> wrote:

> I need to use the authentication server without OIDC/OAuth2/SAMLv2
> implementation as an external IdP,
> in order to integrate existing authentication system.
> (some commercial products supports such the case)
>
> I consulted identity broker's section in keycloak's manual below and found
> that if I use this feature the external IdP must support OIDC or SAMLv2.
> https://keycloak.gitbooks.io/documentation/server_admin/
> topics/identity-broker.html
>
> Therefore, I realized it by using redirect based authentication flows.
>
> Can identity Brokering can support such the case?
>
> Aside from this, I'd like to contribute it to Community extensions and
> examples.
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> ---
> From: Stian Thorgersen [mailto:sthorger at redhat.com]
> Sent: Tuesday, June 27, 2017 5:52 PM
> To: ???? / NORIMATSU?TAKASHI
> Cc: keycloak-dev at lists.jboss.org
> Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication
> server on behalf of keycloak browser-based authentication
>
> I'm not in favour of adding this. If it's using redirect based
> authentication flows it should be done through identity brokering, not
> authentication flows. It's also a very complex example that we don't want
> to maintain. We've also in the process of moving all examples away from the
> main Keycloak repository into a separate quickstart repository.
>
> On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI <
> takashi.norimatsu.ws at hitachi.com> wrote:
> Hello.
>
> Previously, I had proposed the feature of delegating authentication to an
> external authentication server on behalf of keycloak's browser-based
> authentication mechanism.
>
> I've integrated this feature to keycloak's "examples" packages and send PR
> (https://github.com/keycloak/keycloak/pull/4260).
> Hope this PR is reviewed and merged as an example for combining some
> providers to customize keycloak.
>
> Detailed description of this feature is mentioned below.
> https://github.com/Hitachi/PoV-keycloak-authentication-delegation
>
> I am now engaging in integrating this feature to keycloak as product-base
> default providers, but encounter technical problems about writing
> arquillian. Would someone tell me how to resolve this problem?
>
> [Problem]
> - I could not find how to run an external authentication
> server(application running on wildfly 10) during each arquillian test cases.
>
> After resolving this problem and writing and running arquillian test
> cases, I'll send PR for this feature as product-base default providers.
>
> Best Regards
> Takashi Norimatsu
> Hitachi, Ltd.
>
> _______________________________________________
> 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  Thu Jun 29 05:44:39 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 29 Jun 2017 06:44:39 -0300
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
Message-ID: <20170629094439.GD23375@abstractj.org>

+1 that would be great

On 2017-06-28, Stian Thorgersen wrote:
> At times there are extensions and examples that we don't want to include in
> the main repository. This could be for several reasons, including:
>
> * We don't have the resources to maintain and support it
> * We don't believe it's generic enough
> * Examples that are to complex
>
> However, these can still be useful for some people. So I'm thinking about
> how we can provide community maintained extensions and examples.
>
> A very simple idea would be to add a page on our website that links to the
> relevant repository and documentation. To contribute you would setup your
> own Github repository, documentation and also a download if you want. Then
> you'd send a PR to the website to add your extension or example.
>
> Thoughts?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From mmo at semmle.com  Thu Jun 29 11:31:39 2017
From: mmo at semmle.com (Man Yue Mo)
Date: Thu, 29 Jun 2017 16:31:39 +0100
Subject: [keycloak-dev] Various null pointer issues
Message-ID: <CAOP_0_6WR0f5w8UL2Zys0uP5Pr7Efq-MvJTMLMjNOccjyTL96w@mail.gmail.com>

Hi,

There are various dereferencing of null pointer issues flagged up by the
website lgtm.com (Dereferencing variable is always null):

https://lgtm.com/projects/g/keycloak/keycloak/alerts/

It is quite obvious that these will cause NPE whenever the code is
executed. Thanks.

Best regards,

Man Yue Mo

From sthorger at redhat.com  Thu Jun 29 14:01:59 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jun 2017 20:01:59 +0200
Subject: [keycloak-dev] Review Chinese translations
Message-ID: <CAJgngAds0SEx+x1BZAxbEK9UH5+8NrX7G1BeuMG4f6Nq9aeF_g@mail.gmail.com>

Can someone please review PR for Chinese translations:
https://github.com/keycloak/keycloak/pull/4251

From bburke at redhat.com  Thu Jun 29 17:39:18 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 Jun 2017 17:39:18 -0400
Subject: [keycloak-dev] Various null pointer issues
In-Reply-To: <CAOP_0_6WR0f5w8UL2Zys0uP5Pr7Efq-MvJTMLMjNOccjyTL96w@mail.gmail.com>
References: <CAOP_0_6WR0f5w8UL2Zys0uP5Pr7Efq-MvJTMLMjNOccjyTL96w@mail.gmail.com>
Message-ID: <5d4145e9-672b-f699-551f-e4e54e9ebd12@redhat.com>

Awesome tool.  PR sent.  Amazing how stupid one can be sometimes.


On 6/29/17 11:31 AM, Man Yue Mo wrote:
> Hi,
>
> There are various dereferencing of null pointer issues flagged up by the
> website lgtm.com (Dereferencing variable is always null):
>
> https://lgtm.com/projects/g/keycloak/keycloak/alerts/
>
> It is quite obvious that these will cause NPE whenever the code is
> executed. Thanks.
>
> Best regards,
>
> Man Yue Mo
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Jun 29 17:45:43 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 Jun 2017 17:45:43 -0400
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <20170629094439.GD23375@abstractj.org>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
	<20170629094439.GD23375@abstractj.org>
Message-ID: <9584ff6b-1349-1a05-f6ff-5b534a02fc1b@redhat.com>

-1000.  But you've already done this with the quickstarts against my 
wishes.  You know why, but I'll rehash anyways:

* Examples will get out of sync

* Examples will end up not working

* Examples need to be tied to a specific release as APIs and SPIs change

* Users won't know they exist

* Examples won't pick up IDE refactorings of our SPIs and APIs because 
people will forget to include them.

There's really no good reason to have quickstarts and examples in a  
separate repo and a separate build other than "Wildlfy does it."


On 6/29/17 5:44 AM, Bruno Oliveira wrote:
> +1 that would be great
>
> On 2017-06-28, Stian Thorgersen wrote:
>> At times there are extensions and examples that we don't want to include in
>> the main repository. This could be for several reasons, including:
>>
>> * We don't have the resources to maintain and support it
>> * We don't believe it's generic enough
>> * Examples that are to complex
>>
>> However, these can still be useful for some people. So I'm thinking about
>> how we can provide community maintained extensions and examples.
>>
>> A very simple idea would be to add a page on our website that links to the
>> relevant repository and documentation. To contribute you would setup your
>> own Github repository, documentation and also a download if you want. Then
>> you'd send a PR to the website to add your extension or example.
>>
>> Thoughts?
>> _______________________________________________
>> 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 bburke at redhat.com  Thu Jun 29 17:50:11 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 29 Jun 2017 17:50:11 -0400
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <9584ff6b-1349-1a05-f6ff-5b534a02fc1b@redhat.com>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
	<20170629094439.GD23375@abstractj.org>
	<9584ff6b-1349-1a05-f6ff-5b534a02fc1b@redhat.com>
Message-ID: <f5ed8f32-fc93-f0a8-3f08-8570554a8e33@redhat.com>

One more thing:

Broken examples are akin to documentation that is incorrect.   It pisses 
people off and makes Keycloak look bad.  Moving examples to a different 
repo that is only maintained by community won't get maintained.  That's 
a fact.


On 6/29/17 5:45 PM, Bill Burke wrote:
> -1000. But you've already done this with the quickstarts against my 
> wishes.  You know why, but I'll rehash anyways:
>
> * Examples will get out of sync
>
> * Examples will end up not working
>
> * Examples need to be tied to a specific release as APIs and SPIs change
>
> * Users won't know they exist
>
> * Examples won't pick up IDE refactorings of our SPIs and APIs because 
> people will forget to include them.
>
> There's really no good reason to have quickstarts and examples in a  
> separate repo and a separate build other than "Wildlfy does it."
>
>
> On 6/29/17 5:44 AM, Bruno Oliveira wrote:
>> +1 that would be great
>>
>> On 2017-06-28, Stian Thorgersen wrote:
>>> At times there are extensions and examples that we don't want to 
>>> include in
>>> the main repository. This could be for several reasons, including:
>>>
>>> * We don't have the resources to maintain and support it
>>> * We don't believe it's generic enough
>>> * Examples that are to complex
>>>
>>> However, these can still be useful for some people. So I'm thinking 
>>> about
>>> how we can provide community maintained extensions and examples.
>>>
>>> A very simple idea would be to add a page on our website that links 
>>> to the
>>> relevant repository and documentation. To contribute you would setup 
>>> your
>>> own Github repository, documentation and also a download if you 
>>> want. Then
>>> you'd send a PR to the website to add your extension or example.
>>>
>>> Thoughts?
>>> _______________________________________________
>>> 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 asaldanha1947 at gmail.com  Thu Jun 29 20:53:55 2017
From: asaldanha1947 at gmail.com (Anil Saldanha)
Date: Thu, 29 Jun 2017 19:53:55 -0500
Subject: [keycloak-dev] Various null pointer issues
In-Reply-To: <5d4145e9-672b-f699-551f-e4e54e9ebd12@redhat.com>
References: <CAOP_0_6WR0f5w8UL2Zys0uP5Pr7Efq-MvJTMLMjNOccjyTL96w@mail.gmail.com>
	<5d4145e9-672b-f699-551f-e4e54e9ebd12@redhat.com>
Message-ID: <170562FE-776E-4E7E-AA14-4A31B2D68B37@gmail.com>

Bill - not sure if you have integrated SonarQube into your Jenkins builds.
It shows an amazing amount of code quality metrics and issues that a perfectionist can spend a lifetime on.
https://en.m.wikipedia.org/wiki/SonarQube

> On Jun 29, 2017, at 4:39 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> Awesome tool.  PR sent.  Amazing how stupid one can be sometimes.
> 
> 
>> On 6/29/17 11:31 AM, Man Yue Mo wrote:
>> Hi,
>> 
>> There are various dereferencing of null pointer issues flagged up by the
>> website lgtm.com (Dereferencing variable is always null):
>> 
>> https://lgtm.com/projects/g/keycloak/keycloak/alerts/
>> 
>> It is quite obvious that these will cause NPE whenever the code is
>> executed. Thanks.
>> 
>> Best regards,
>> 
>> Man Yue Mo
>> _______________________________________________
>> 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 Jun 30 00:55:48 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jun 2017 06:55:48 +0200
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <f5ed8f32-fc93-f0a8-3f08-8570554a8e33@redhat.com>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
	<20170629094439.GD23375@abstractj.org>
	<9584ff6b-1349-1a05-f6ff-5b534a02fc1b@redhat.com>
	<f5ed8f32-fc93-f0a8-3f08-8570554a8e33@redhat.com>
Message-ID: <CAJgngAcY_apFr0gfneChXy4bm6Z3Ytt+EGWysEB6CZTn79vjAA@mail.gmail.com>

Broken examples have nothing to do with where they are. It's down to lack
of automated tests. The examples in the same repo have been broken
countless amount of times in the past and we used to manually test it. The
new quickstarts have full automated testing and as part of a release we are
setting up CI jobs that check the quickstarts against the latests Keycloak.

Examples should not be tied to a specific API we need to be backwards
compatible. In fact moving to a separate repo makes it more obvious when we
break API compatibility. That might be awkward for us, but it's a good
thing for our users.

Whether or not users find them or not has also nothing to do with them
being in the same repo. There's a download for the examples of the website
and it doesn't matter what repository that comes from.

We also where required to have quickstarts in a separate repo for product.
So we would have had to have separate examples for Keycloak and RH-SSO if
they where going to be in the same repo.

That's a completely different thing to what this discussion was about
though. This discussion was purely about extensions and examples that we
are not able to maintain so we can't accept them to the main repo.

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

> One more thing:
>
> Broken examples are akin to documentation that is incorrect.   It pisses
> people off and makes Keycloak look bad.  Moving examples to a different
> repo that is only maintained by community won't get maintained.  That's
> a fact.
>
>
> On 6/29/17 5:45 PM, Bill Burke wrote:
> > -1000. But you've already done this with the quickstarts against my
> > wishes.  You know why, but I'll rehash anyways:
> >
> > * Examples will get out of sync
> >
> > * Examples will end up not working
> >
> > * Examples need to be tied to a specific release as APIs and SPIs change
> >
> > * Users won't know they exist
> >
> > * Examples won't pick up IDE refactorings of our SPIs and APIs because
> > people will forget to include them.
> >
> > There's really no good reason to have quickstarts and examples in a
> > separate repo and a separate build other than "Wildlfy does it."
> >
> >
> > On 6/29/17 5:44 AM, Bruno Oliveira wrote:
> >> +1 that would be great
> >>
> >> On 2017-06-28, Stian Thorgersen wrote:
> >>> At times there are extensions and examples that we don't want to
> >>> include in
> >>> the main repository. This could be for several reasons, including:
> >>>
> >>> * We don't have the resources to maintain and support it
> >>> * We don't believe it's generic enough
> >>> * Examples that are to complex
> >>>
> >>> However, these can still be useful for some people. So I'm thinking
> >>> about
> >>> how we can provide community maintained extensions and examples.
> >>>
> >>> A very simple idea would be to add a page on our website that links
> >>> to the
> >>> relevant repository and documentation. To contribute you would setup
> >>> your
> >>> own Github repository, documentation and also a download if you
> >>> want. Then
> >>> you'd send a PR to the website to add your extension or example.
> >>>
> >>> Thoughts?
> >>> _______________________________________________
> >>> 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 sblanc at redhat.com  Fri Jun 30 02:40:01 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 30 Jun 2017 08:40:01 +0200
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <1498685488.3089.1.camel@cargosoft.ru>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
	<1498685488.3089.1.camel@cargosoft.ru>
Message-ID: <CAMZCGg8b4+1OtCwbGm9WYqp_Qf7AD0LQfqrm+yJ5J2bJwFWwVA@mail.gmail.com>

On Wed, Jun 28, 2017 at 11:31 PM, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> Hi,
>
> Though I'm not a Keycloak dev, I hope the community member's 2? will be
> useful nevertheless.
>
> To me that sounds like a great initiative, I myself will be happy to
> contribute BeerCloak, an example of how to build complete admin realm
> resources while the corresponding SPI is not (yet) implemented.
>
> Off the top of my head, I think we'll need some sort of separation
> between examples and extensions because of their (generally) different
> use cases. For examples, it's "check it out and hack on it"; for
> extensions, "install & use it" (preferably skipping the "checkout" and
> "build" phases).
>
> Ideally, there should be something like Atlassian Marketplace, a
> registry/repository of extensions (including commercial ones) with one-
> click installation. I clearly understand that wouldn't be a top
> priority - just sharing my vision.
>

Putting the commercial extensions aside, I like the concept of a
"Marketplace", in fact I like what Forge does for its addons :
https://forge.jboss.org/addons . Each Extension should start with the same
"blueprint" and yes it would be nice to have a :
- A registry.
- A standard way of installing them.

>
> BTW, speaking about commercial extensions, can we hope on our products
> being mentioned somewhere too? I think such a disclosure can make
> Keycloak/RHSSO look more valuable in the eyes of potential users and
> customers. Our flagship product provides Keycloak support for hardware
> OTP tokens with full lifecycle, like bulk import, enrollment,
> revocation, audit etc.
>
> The other stuff being developed is:
> * HRM integration (sync Keycloak with employee database from HRMs);
> * advanced monitoring (collect different Keycloak-specific metrics and
> expose them as DMR/JMX);
> * OpenID 2.0 (legacy) support;
> * identity brokering for VK social network (this and the previous one
> most likely will be opensourced).
>
> There are even thoughts on integrating PKI functionality into Keycloak,
> which becomes highly topical with the introduction of x509 client cert
> auth (thanks Peter!)
>
> Cheers,
> Dmitry Telegin
> CTO, CargoSoft LLC
> http://cargosoft.ru/en/rm/about/
>
> ? Wed, 28/06/2017 ? 08:34 +0200, Stian Thorgersen ?????:
> > At times there are extensions and examples that we don't want to
> > include in
> > the main repository. This could be for several reasons, including:
> >
> > * We don't have the resources to maintain and support it
> > * We don't believe it's generic enough
> > * Examples that are to complex
> >
> > However, these can still be useful for some people. So I'm thinking
> > about
> > how we can provide community maintained extensions and examples.
> >
> > A very simple idea would be to add a page on our website that links
> > to the
> > relevant repository and documentation. To contribute you would setup
> > your
> > own Github repository, documentation and also a download if you want.
> > Then
> > you'd send a PR to the website to add your extension or example.
> >
> > Thoughts?
> > _______________________________________________
> > 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 Jun 30 03:06:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jun 2017 09:06:43 +0200
Subject: [keycloak-dev] Community extensions and examples
In-Reply-To: <CAMZCGg8b4+1OtCwbGm9WYqp_Qf7AD0LQfqrm+yJ5J2bJwFWwVA@mail.gmail.com>
References: <CAJgngAcSJd-94D9vdpNaY-1R3JrHifedrykNvy9fqyV9Cb3vkA@mail.gmail.com>
	<1498685488.3089.1.camel@cargosoft.ru>
	<CAMZCGg8b4+1OtCwbGm9WYqp_Qf7AD0LQfqrm+yJ5J2bJwFWwVA@mail.gmail.com>
Message-ID: <CAJgngAd=cQFVjZKE12GKiYV=ogtYFydRsiB8dCGNtL2nB76hgg@mail.gmail.com>

Extensions can already be easy to install on Keycloak. Just download and
drop into standalone/deployments. It's just a matter of having a page like
that where folks can discover things.

Then there's also community maintained adapters, blogs, examples, etc. we
could link to as well.

On 30 June 2017 at 08:40, Sebastien Blanc <sblanc at redhat.com> wrote:

>
>
> On Wed, Jun 28, 2017 at 11:31 PM, Dmitry Telegin <mitya at cargosoft.ru>
> wrote:
>
>> Hi,
>>
>> Though I'm not a Keycloak dev, I hope the community member's 2? will be
>> useful nevertheless.
>>
>> To me that sounds like a great initiative, I myself will be happy to
>> contribute BeerCloak, an example of how to build complete admin realm
>> resources while the corresponding SPI is not (yet) implemented.
>>
>> Off the top of my head, I think we'll need some sort of separation
>> between examples and extensions because of their (generally) different
>> use cases. For examples, it's "check it out and hack on it"; for
>> extensions, "install & use it" (preferably skipping the "checkout" and
>> "build" phases).
>>
>> Ideally, there should be something like Atlassian Marketplace, a
>> registry/repository of extensions (including commercial ones) with one-
>> click installation. I clearly understand that wouldn't be a top
>> priority - just sharing my vision.
>>
>
> Putting the commercial extensions aside, I like the concept of a
> "Marketplace", in fact I like what Forge does for its addons :
> https://forge.jboss.org/addons . Each Extension should start with the
> same "blueprint" and yes it would be nice to have a :
> - A registry.
> - A standard way of installing them.
>
>>
>> BTW, speaking about commercial extensions, can we hope on our products
>> being mentioned somewhere too? I think such a disclosure can make
>> Keycloak/RHSSO look more valuable in the eyes of potential users and
>> customers. Our flagship product provides Keycloak support for hardware
>> OTP tokens with full lifecycle, like bulk import, enrollment,
>> revocation, audit etc.
>>
>> The other stuff being developed is:
>> * HRM integration (sync Keycloak with employee database from HRMs);
>> * advanced monitoring (collect different Keycloak-specific metrics and
>> expose them as DMR/JMX);
>> * OpenID 2.0 (legacy) support;
>> * identity brokering for VK social network (this and the previous one
>> most likely will be opensourced).
>>
>> There are even thoughts on integrating PKI functionality into Keycloak,
>> which becomes highly topical with the introduction of x509 client cert
>> auth (thanks Peter!)
>>
>> Cheers,
>> Dmitry Telegin
>> CTO, CargoSoft LLC
>> http://cargosoft.ru/en/rm/about/
>>
>> ? Wed, 28/06/2017 ? 08:34 +0200, Stian Thorgersen ?????:
>> > At times there are extensions and examples that we don't want to
>> > include in
>> > the main repository. This could be for several reasons, including:
>> >
>> > * We don't have the resources to maintain and support it
>> > * We don't believe it's generic enough
>> > * Examples that are to complex
>> >
>> > However, these can still be useful for some people. So I'm thinking
>> > about
>> > how we can provide community maintained extensions and examples.
>> >
>> > A very simple idea would be to add a page on our website that links
>> > to the
>> > relevant repository and documentation. To contribute you would setup
>> > your
>> > own Github repository, documentation and also a download if you want.
>> > Then
>> > you'd send a PR to the website to add your extension or example.
>> >
>> > Thoughts?
>> > _______________________________________________
>> > 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 Jun 30 03:50:16 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jun 2017 09:50:16 +0200
Subject: [keycloak-dev] Master bumped to 3.3.0.CR1-SNAPSHOT
Message-ID: <CAJgngAf_DK+aBdJWsSX0J3CsERrf5OkdMAwKmnAitttCJbhzAw@mail.gmail.com>

I've started releasing 3.2 and master is ready for commits to 3.3.

From mmo at semmle.com  Fri Jun 30 06:12:29 2017
From: mmo at semmle.com (Man Yue Mo)
Date: Fri, 30 Jun 2017 11:12:29 +0100
Subject: [keycloak-dev] Possible bug in ResourceSetServlet may cause
	resources being overwritten
Message-ID: <CAOP_0_4wRe-x-KXjjcJXihE6vySQJqr4Upfp5pGRDoQab56uHw@mail.gmail.com>

Hi,

In the following:

https://lgtm.com/projects/g/keycloak/keycloak/snapshot/6b3b04f10f5a3ffd0efbec2fcdbe76b518ce8837/files/services/src/main/java/org/keycloak/authorization/admin/ResourceSetService.java#V105

because a string is compared to an enum in the last condition, the check
always returns false. In particular, if the resource already existed, then
it may overwrite the existing resource. Thanks.

Best Regards,

Man Yue Mo

From sthorger at redhat.com  Fri Jun 30 07:31:05 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jun 2017 13:31:05 +0200
Subject: [keycloak-dev] Keycloak 3.2.0.CR2 released
Message-ID: <CAJgngAc_1BDsTigOyv4iu3HYmT4t67Gfh0sq9q1Tsu0=tdp5wA@mail.gmail.com>

We've just released Keycloak 3.2.0.CR1.

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

This is something that we've wanted to add for a long time! Through our
authorization services it's now possible to finely tune permissions for
admins. This makes it possible to limit what clients, users, roles, etc.
admins have access to. Documentation is missing for this at the moment, but
will be added in time for 3.2.0.Final.
Docker Registry support

It's not possible to secure a Docker Registry with a standard OAuth or
OpenID Connect provider. For some strange reason they have only partially
followed the specifications and the Docker Registry maintainers refuse to
fix this! Fear not, thanks to cainj13 <https://github.com/cainj13> who
contributed this we now have a special Docker Registry protocol that can be
enabled in Keycloak.
Authentication sessions and access tokens

In the effort to provide support for running Keycloak in multiple data
centers we've done a large amount of work around user sessions. We've
introduced authentication sessions that are special sessions used primarily
during the authentication flows. There are two main reasons for this.
Authentication flows can fairly easily be fixed to a specific node within a
specific data center and there is no need to replicate this to other data
centers. They are also more write heavy than the user sessions. The
introduction of access tokens makes it possible to detach actions (for
example verify email) from a user session, which has a number of benefits.
More will come in future 3.x releases and by the end of the year we aim to
fully support replicating Keycloak cross multiple data centers.
Authorization Service improvements

There's been a lot of work done to the authorization services in this
release. Way to many to list here so check out JIRA
<https://issues.jboss.org/browse/KEYCLOAK-5072?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.2.0.CR1%20and%20component%20%3D%20Authorization>
for
details.
QuickStarts

We've introduced new QuickStarts with the aim to make it even simpler for
you to get started securing your applications and services with Keycloak.
The QuickStarts have proper tests as well, which can serve as a reference
on how to tests your own applications and services secured with Keycloak.
Check out the new QuickStarts in the keycloak-quickstarts GitHub repository
<https://github.com/keycloak/keycloak-quickstarts>.
Upgraded AngularJS and JQuery

We've upgraded the versions we use of AngularJS and JQuery as there where a
number of known vulnerabilities. We're fairly certain neither of the known
vulnerabilities affect Keycloak, but to be on the safe side we decided to
upgrade.
Updated Password Hashing Algorithms

We're still using PBKDF2, but we've added support for SHA256 and SHA512.
PBKDF2 is SHA256 is now used by default.
Spring Boot QuickStarter

We've added a new Spring Boot QuickStarter that makes it super simple to
get started securing your Spring Boot applications. For more details check
out the blog post about it
<http://blog.keycloak.org/2017/05/easily-secure-your-spring-boot.html>.
Loads more..

   - Partial export of realms in the admin console
   - Redirect URI rewrite rules for adapters
   - Test email settings in the admin console
   - Initial access tokens now persisted to the db

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.2.0.CR1>
.
Upgrading

Before you upgrade remember to backup your database and check the migration
guide
<https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>.
Release candidates are not recommended in production and we do not support
upgrading from release candidates.

From sthorger at redhat.com  Fri Jun 30 08:51:36 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jun 2017 14:51:36 +0200
Subject: [keycloak-dev] Renaming testsuite/integration to
	testsuite/integration-deprecated
In-Reply-To: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
References: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
Message-ID: <CAJgngAcWqFtgQkMmsofXN6dHzOg=3XXvOELvWnzFznH5XYTVVw@mail.gmail.com>

Unless someone objects I'm going start by renaming testsuite/integration to
testsuite/integration-deprecated. Created JIRA
https://issues.jboss.org/browse/KEYCLOAK-5123. Last chance to complain.

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

> I would like to rename testsuite/integration to testsuite/integration-deprecated.
> This is to make it clear to external contributors that the testsuite is
> deprecated and new tests should be added to testsuite/integration-
> arquillian.
>
> I would also like to rename testsuite/integration-arquillian
> to testsuite/integration.
>

From ryan.dawson at alfresco.com  Fri Jun 30 11:05:40 2017
From: ryan.dawson at alfresco.com (Ryan Dawson)
Date: Fri, 30 Jun 2017 15:05:40 +0000
Subject: [keycloak-dev] Spring boot 2 adapter?
In-Reply-To: <B70BF1C4-A91A-4677-A369-1BB75140FB92@alfresco.com>
References: <B70BF1C4-A91A-4677-A369-1BB75140FB92@alfresco.com>
Message-ID: <9B9456E4-ED19-4AB8-9995-99AA2D81005D@alfresco.com>

Hi All,

I?m looking to use key cloak with spring boot 2 (which is currently at 2.0.0M2). I realised that there wasn?t an adapter so I?ve written up a ticket and then submitted a PR (https://issues.jboss.org/browse/KEYCLOAK-5098). Apologies for not emailing the list first but better late than never. Presently it?s only working with the embedded jetty and undertow and not the embedded tomcat (the redirectUri fails to get decoded) but I don?t think that?s a problem with the adapter as such as the tomcat config does get applied. If anyone has any thoughts please let me know.

Ryan


From sblanc at redhat.com  Fri Jun 30 13:28:39 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 30 Jun 2017 17:28:39 +0000
Subject: [keycloak-dev] Spring boot 2 adapter?
In-Reply-To: <9B9456E4-ED19-4AB8-9995-99AA2D81005D@alfresco.com>
References: <B70BF1C4-A91A-4677-A369-1BB75140FB92@alfresco.com>
	<9B9456E4-ED19-4AB8-9995-99AA2D81005D@alfresco.com>
Message-ID: <CAMZCGg8_ihtmp+S-snvNmDY4ViYyed39jAxVRAXDnLrrqf3gOQ@mail.gmail.com>

This is great news ! Thanks for contributing on this.
Could you assign the ticket to me and I will review it next week.
Seb

Le ven. 30 juin 2017 ? 18:57, Ryan Dawson <ryan.dawson at alfresco.com> a
?crit :

> Hi All,
>
> I?m looking to use key cloak with spring boot 2 (which is currently at
> 2.0.0M2). I realised that there wasn?t an adapter so I?ve written up a
> ticket and then submitted a PR (
> https://issues.jboss.org/browse/KEYCLOAK-5098). Apologies for not
> emailing the list first but better late than never. Presently it?s only
> working with the embedded jetty and undertow and not the embedded tomcat
> (the redirectUri fails to get decoded) but I don?t think that?s a problem
> with the adapter as such as the tomcat config does get applied. If anyone
> has any thoughts please let me know.
>
> Ryan
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From thomas.darimont at googlemail.com  Fri Jun 30 15:03:11 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 30 Jun 2017 21:03:11 +0200
Subject: [keycloak-dev] Renaming testsuite/integration to
	testsuite/integration-deprecated
In-Reply-To: <CAJgngAcWqFtgQkMmsofXN6dHzOg=3XXvOELvWnzFznH5XYTVVw@mail.gmail.com>
References: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
	<CAJgngAcWqFtgQkMmsofXN6dHzOg=3XXvOELvWnzFznH5XYTVVw@mail.gmail.com>
Message-ID: <CAK-7U1j8cxq8JWNj7PEcwYaC9bg4KOq1ZwMv1LEvk+p=ZdYmkA@mail.gmail.com>

Will it still be possible to use the embedded KeycloakServer for testing?

I use this a lot for quickly trying out new Keycloak extensions /
customizations.

Cheers,
Thomas

2017-06-30 14:51 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> Unless someone objects I'm going start by renaming testsuite/integration to
> testsuite/integration-deprecated. Created JIRA
> https://issues.jboss.org/browse/KEYCLOAK-5123. Last chance to complain.
>
> On 8 June 2017 at 08:27, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> > I would like to rename testsuite/integration to testsuite/integration-
> deprecated.
> > This is to make it clear to external contributors that the testsuite is
> > deprecated and new tests should be added to testsuite/integration-
> > arquillian.
> >
> > I would also like to rename testsuite/integration-arquillian
> > to testsuite/integration.
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Fri Jun 30 15:57:17 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 30 Jun 2017 21:57:17 +0200
Subject: [keycloak-dev] Potential database connection leak in current master
 (3.3.0) in permissions tab
Message-ID: <CAK-7U1hnKmjKtWkeaqKxtpoAUA0zG0MJR-zzf9uYc7UXz7_SQw@mail.gmail.com>

Hello guys,

I just noticed that there seem to be connection leak somewhere triggered
by using the authorization / permissions tab in the admin console in the
current master.

It's a bit hard to trigger but I can reproduce the problem with the
following steps:

login as admin
goto the realm-management client
goto authorizations tab -> Authorization Scopes
click show details...
click hide details...

:view_and_edit_client_permissions

goto a client -> select the permissions tab
enable permissions (if not enabled)
on any permission click edit

Click the authorization in the breadcrumb
select the Authorization Scopes sub tab
click show details...
click hide details...

GOTO view_and_edit_client_permissions (2, or 3 times)

I ran the embedded org.keycloak.testsuite.KeycloakServer (from the soon to
be gone testsuite...)
with the following vm-options:

-Dkeycloak.bind.address=0.0.0.0
-Djava.net.preferIPv4Stack=true
-Dkeycloak.connectionsJpa.url=jdbc:postgresql://localhost:5432/idm_keycloak_3_3_0_master
-Dkeycloak.connectionsJpa.driver=org.postgresql.Driver
-Dkeycloak.connectionsJpa.driverDialect=org.hibernate.dialect.PostgreSQLDialect
-Dkeycloak.connectionsJpa.user=keycloak
-Dkeycloak.connectionsJpa.password=keycloak
-Dkeycloak.connectionsJpa.showSql=true
-Dkeycloak.connectionsJpa.formatSql=true


Before the PersistenceException I see a bunch of SQL statements executed
via hibernate:

...
Hibernate:
    select
        resourcese0_.ID as col_0_0_
    from
        RESOURCE_SERVER resourcese0_
    where
        resourcese0_.CLIENT_ID=?
Hibernate:
    select
        realmentit0_.ID as col_0_0_
    from
        REALM realmentit0_
Hibernate:
    select
        realmentit0_.ID as col_0_0_
    from
        REALM realmentit0_
Hibernate:
    select
        resourceen0_.ID as col_0_0_
    from
        RESOURCE_SERVER_RESOURCE resourceen0_
    where
        resourceen0_.RESOURCE_SERVER_ID=?
        and (
            resourceen0_.ID in (
                ?
            )
        )
    order by
        resourceen0_.NAME asc limit ?

StackTrace:

20:41:28,406 ERROR XNIO-1 task-55 [io.undertow.request] UT005023: Exception
handling request to
/auth/admin/realms/godemo/clients/04db0bbf-6417-41bf-99ed-e33f305e1d8e/authz/resource-server/scope/34f30b87-063b-4b04-9191-d9a8af321604/permissions
org.jboss.resteasy.spi.UnhandledException:
javax.persistence.PersistenceException:
org.hibernate.exception.GenericJDBCException: Error calling Driver#connect
    at
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
    at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
    at
org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471)
    at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:415)
    at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
    at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
    at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
    at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
    at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
    at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
    at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
    at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
    at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
    at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
    at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
    at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
    at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
    at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
    at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
    at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
    at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
    at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
    at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
    at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
    at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
    at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
    at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
    at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
    at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
    at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
    at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
    at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:748)
Caused by: javax.persistence.PersistenceException:
org.hibernate.exception.GenericJDBCException: Error calling Driver#connect
    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.internal.TransactionImpl.begin(TransactionImpl.java:48)
    at
org.keycloak.connections.jpa.JpaKeycloakTransaction.begin(JpaKeycloakTransaction.java:39)
    at
org.keycloak.services.DefaultKeycloakTransactionManager.enlist(DefaultKeycloakTransactionManager.java:52)
    at
org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:89)
    at
org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:56)
    at
org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:163)
    at
org.keycloak.authorization.jpa.store.JPAAuthorizationStoreFactory.getEntityManager(JPAAuthorizationStoreFactory.java:56)
    at
org.keycloak.authorization.jpa.store.JPAAuthorizationStoreFactory.create(JPAAuthorizationStoreFactory.java:37)
    at
org.keycloak.authorization.jpa.store.JPAAuthorizationStoreFactory.create(JPAAuthorizationStoreFactory.java:33)
    at
org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:163)
    at
org.keycloak.models.cache.infinispan.authorization.StoreFactoryCacheSession.getDelegate(StoreFactoryCacheSession.java:344)
    at
org.keycloak.models.cache.infinispan.authorization.StoreFactoryCacheSession$2.commit(StoreFactoryCacheSession.java:175)
    at
org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:136)
    at
org.keycloak.services.filters.KeycloakTransactionCommitter.filter(KeycloakTransactionCommitter.java:43)
    at
org.jboss.resteasy.core.ServerResponseWriter.executeFilters(ServerResponseWriter.java:121)
    at
org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:48)
    at
org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466)
    ... 38 more
Caused by: org.hibernate.exception.GenericJDBCException: Error calling
Driver#connect
    at
org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47)
    at
org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
    at
org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.convertSqlException(BasicConnectionCreator.java:118)
    at
org.hibernate.engine.jdbc.connections.internal.DriverConnectionCreator.makeConnection(DriverConnectionCreator.java:41)
    at
org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.createConnection(BasicConnectionCreator.java:58)
    at
org.hibernate.engine.jdbc.connections.internal.DriverManagerConnectionProviderImpl.getConnection(DriverManagerConnectionProviderImpl.java:189)
    at
org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:386)
    at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:87)
    at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:112)
    at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:230)
    at
org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:237)
    at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:214)
    at
org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:52)
    at
org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1512)
    at
org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:45)
    ... 54 more
Caused by: org.postgresql.util.PSQLException: FATAL: remaining connection
slots are reserved for non-replication superuser connections
    at
org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:572)
    at
org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:177)
    at
org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:64)
    at
org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:136)
    at
org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:29)
    at
org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:21)
    at
org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:31)
    at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24)
    at org.postgresql.Driver.makeConnection(Driver.java:410)
    at org.postgresql.Driver.connect(Driver.java:280)
    at
org.hibernate.engine.jdbc.connections.internal.DriverConnectionCreator.makeConnection(DriverConnectionCreator.java:38)
    ... 65 more