From sthorger at redhat.com  Thu May  2 04:19:22 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 2 May 2019 10:19:22 +0200
Subject: [keycloak-dev] Design Proposal: Implementation of OAuth 2.0 Device
	Authorization Grant
Message-ID: <CAJgngAe0a1MyoMttE72XB9dri267wenjQ4SKtB8a2KGJsw5Cmw@mail.gmail.com>

https://github.com/keycloak/keycloak-community/pull/6

From sthorger at redhat.com  Mon May  6 02:50:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 6 May 2019 08:50:35 +0200
Subject: [keycloak-dev] Application Initiated Action
Message-ID: <CAJgngAc+QmSm4h2zr6TeNNpWBDE9qfh_Zw6Z3NeFH7YDMPYt1g@mail.gmail.com>

Last chance to comment on Application Initiated Action design:

https://github.com/keycloak/keycloak-community/pull/7

From slaskawi at redhat.com  Mon May  6 03:17:56 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 6 May 2019 09:17:56 +0200
Subject: [keycloak-dev] HA mode with JDBC_PING shows warning in the logs
 after migration to 4.8.3 from 3.4.3
In-Reply-To: <CAJmz6fsi1HO=-MS=CuTtAj-8W_Mafw2kjHN2RS1K-r-tpoQTkg@mail.gmail.com>
References: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>
	<CAA9R9O5jCWQDCj3Ruf9w-kRwS9E_vK1x=dx6aLbeB5-7wESJjQ@mail.gmail.com>
	<CAJmz6fsi1HO=-MS=CuTtAj-8W_Mafw2kjHN2RS1K-r-tpoQTkg@mail.gmail.com>
Message-ID: <CAA9R9O6pgH3_E776Znb3hxAHBaThnnUSuEBL=kAshR3HyWGuBA@mail.gmail.com>

Adding +Bela Ban <bban at redhat.com>, just in case :)

Currently, JDBC_PING extends FILE_PING, which has some properties, that
works similarly to `clear_table_on_view_change`:
- remove_old_coords_on_view_change - If true, on a view change, the new
coordinator removes files from old coordinators
- remove_all_data_on_view_change - If true, on a view change, the new
coordinator removes all data except its own

It's also worth to mention, that the coordinator clears the table when
shutting down (being more specific, on `JDBC_PING#stop`. So unless your
cluster crashes a lot (by crashing I mean calling `kill -9` for example),
you should be fine.

Thanks,
Seb

On Mon, Apr 29, 2019 at 9:44 AM abhishek raghav <abhi.raghav007 at gmail.com>
wrote:

> Thanks Sebastian.
>
> I tried running the same setup with 5.0.0 of keycloak, I did not see any
> such errors which I reported in my first email. This was definitely a
> Wildfly issue and not keycloak.
>
> Regarding my 2nd question - i.e. support of "clear_table_on_view_change"
> property. I see that jgroups has removed support of this property. So lets
> say if JGROUPSPING table has lot stale entries, while keycloak starts
> booting up - each time keycloak node will try to JOIN with all the entries
> already present in the JGROUPSPING table and thus time taken for the
> service to start will be more. If that timeline is more than 300s, keycloak
> does not start and reports timeout error.
> This scenario is highly possible in cloud scenarios, since there the
> keycloak nodes can start on any available host/IP since no of nodes are not
> fixed.
>
> Can you suggest any workaround to fix this.
>
> *- Best Regards*
>    Abhishek Raghav
>
>
>
>
>
>
>
>
> On Fri, Apr 26, 2019 at 6:11 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> There was a bunch of fixed to JGroups a while ago, including changes in
>> JDBC_PING.
>>
>> Could you please rerun your setup with Keycloak >= 5.0.0? I believe some
>> of the issues (or maybe even all of them) should be fixed.
>>
>> On Thu, Apr 25, 2019 at 7:19 PM abhishek raghav <abhi.raghav007 at gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> After the migration of keycloak HA configurations from 3.4.3.Final to
>>> 4.8.3.Final, I am seeing some WARNINGS on one of the nodes of keycloak
>>> immediately after the keycloak is started with 2 nodes. This occurs after
>>> every time when the cluster is scaled up or whenever infinispan is trying
>>> to update the cluster member list.
>>> I am using JDBC_PING to achieve clustering in keycloak.
>>>
>>> Below is the stacktrace -
>>>
>>> 2019-04-24 12:20:43,687 WARN
>>> >> [org.infinispan.topology.ClusterTopologyManagerImpl]
>>> >> (transport-thread--p18-t2) [dcidqdcosagent08] KEYCLOAK DEV 1.5.RC
>>> >> ISPN000197: Error updating cluster member list:
>>> >> org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out
>>> >> waiting for responses for request 1 from dcidqdcosagent02
>>> >
>>> >                   at
>>> >>
>>> org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
>>> >
>>> >                   at
>>> >>
>>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
>>> >
>>> >                   at
>>> >>
>>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
>>> >
>>> >                   at
>>> >> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> >
>>> >                   at
>>> >>
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>> >
>>> >                   at
>>> >>
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>> >
>>> >                   at
>>> >>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> >
>>> >                   at
>>> >>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> >
>>> >                   at java.lang.Thread.run(Thread.java:748)
>>> >
>>> >                   Suppressed:
>>> org.infinispan.util.logging.TraceException
>>> >
>>> >                                     at
>>> >>
>>> org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
>>> >
>>> >                                     at
>>> >>
>>> org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
>>> >
>>> >                                     at
>>> >>
>>> org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
>>> >
>>> >
>>>
>>> Now after I searched, I really did not see anyone reported such error on
>>> keycloak but there is similar bug reported in WILDLFY 14 and is
>>> categorized
>>> as a blocker in WILDLFY 14.This bug is already fixed in WILDLFY 15.
>>> https://issues.jboss.org/browse/WFLY-10736?attachmentViewMode=list
>>>
>>> Now since keycloak 4.8 is also based on WILDLFY 14, these WARNINGS could
>>> be
>>> because of this blocker in WILDFLY 14.
>>>
>>> What should I do to get rid this error. Is this really a problem in
>>> keycloak 4.8.3.Final. Did anyone notice any such issue while running
>>> keycloak 4.8.3 in HA mode.
>>> Is there a workaround to fix this.
>>>
>>>
>>> One more thing we noticed is - It is regarding a property in JDBC_PING
>>> protocol we are using in our 3.4.3 setup i.e.
>>> "clear_table_on_view_change"
>>> but it is no more supported in 4.8 version. and thus the JGROUPSPING
>>> table
>>> is filled up with lot of stale entries. Is there a workaround to clear
>>> the
>>> table after view change in 4.8 also.
>>>
>>> Thanks
>>> Abhishek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

From sthorger at redhat.com  Tue May  7 04:16:55 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 May 2019 10:16:55 +0200
Subject: [keycloak-dev] Review Arabic translation
Message-ID: <CAJgngAe70y8hAKwW9Qxfz7-WO8ueTkTd7vjg8LY-o3y5hbytKA@mail.gmail.com>

We have an open contribution for Arabic translations, but need someone from
the community to review.

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

From abhi.raghav007 at gmail.com  Tue May  7 05:17:54 2019
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Tue, 7 May 2019 14:47:54 +0530
Subject: [keycloak-dev] HA mode with JDBC_PING shows warning in the logs
 after migration to 4.8.3 from 3.4.3
In-Reply-To: <CAA9R9O6pgH3_E776Znb3hxAHBaThnnUSuEBL=kAshR3HyWGuBA@mail.gmail.com>
References: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>
	<CAA9R9O5jCWQDCj3Ruf9w-kRwS9E_vK1x=dx6aLbeB5-7wESJjQ@mail.gmail.com>
	<CAJmz6fsi1HO=-MS=CuTtAj-8W_Mafw2kjHN2RS1K-r-tpoQTkg@mail.gmail.com>
	<CAA9R9O6pgH3_E776Znb3hxAHBaThnnUSuEBL=kAshR3HyWGuBA@mail.gmail.com>
Message-ID: <CAJmz6fvE77irE+4XoiRhDohXZG2-Ajp-ScaaPgWeiSDAEsqbew@mail.gmail.com>

Hi Sebastian,

Thanks for the response. I got it working with a clue in your last answer.
I am using docker based container orchestration framework which when I am
scaling down the service is actually force killing the docker containers
(something like kill -9), instead of a graceful shut down. So then, I
changed my docker-entrypoint (I am using my own docker-entrypoint and not
relying on default one which comes with keycloak image) and added *exec*
just before the start command. something like this as below -

exec /opt/jboss/keycloak/bin/standalone.sh --server-config
standalone-ha.xml -Djboss.bind.address=${privateaddress}.....

After adding  "exec", I noticed that keycloak is shutting down gracefully
when I am scaling down the nodes in the cluster and the respective entries
are also getting cleared off from JGROUPSPING table just as you mentioned.

Looks like this there should not be anymore stale entries until the cluster
crashes a lot.

Thanks a lot for your support.

- Best Regards
  Abhishek








On Mon, May 6, 2019 at 12:48 PM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Adding +Bela Ban <bban at redhat.com>, just in case :)
>
> Currently, JDBC_PING extends FILE_PING, which has some properties, that
> works similarly to `clear_table_on_view_change`:
> - remove_old_coords_on_view_change - If true, on a view change, the new
> coordinator removes files from old coordinators
> - remove_all_data_on_view_change - If true, on a view change, the new
> coordinator removes all data except its own
>
> It's also worth to mention, that the coordinator clears the table when
> shutting down (being more specific, on `JDBC_PING#stop`. So unless your
> cluster crashes a lot (by crashing I mean calling `kill -9` for example),
> you should be fine.
>
> Thanks,
> Seb
>
> On Mon, Apr 29, 2019 at 9:44 AM abhishek raghav <abhi.raghav007 at gmail.com>
> wrote:
>
>> Thanks Sebastian.
>>
>> I tried running the same setup with 5.0.0 of keycloak, I did not see any
>> such errors which I reported in my first email. This was definitely a
>> Wildfly issue and not keycloak.
>>
>> Regarding my 2nd question - i.e. support of "clear_table_on_view_change"
>> property. I see that jgroups has removed support of this property. So lets
>> say if JGROUPSPING table has lot stale entries, while keycloak starts
>> booting up - each time keycloak node will try to JOIN with all the entries
>> already present in the JGROUPSPING table and thus time taken for the
>> service to start will be more. If that timeline is more than 300s, keycloak
>> does not start and reports timeout error.
>> This scenario is highly possible in cloud scenarios, since there the
>> keycloak nodes can start on any available host/IP since no of nodes are not
>> fixed.
>>
>> Can you suggest any workaround to fix this.
>>
>> *- Best Regards*
>>    Abhishek Raghav
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 26, 2019 at 6:11 PM Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> There was a bunch of fixed to JGroups a while ago, including changes in
>>> JDBC_PING.
>>>
>>> Could you please rerun your setup with Keycloak >= 5.0.0? I believe some
>>> of the issues (or maybe even all of them) should be fixed.
>>>
>>> On Thu, Apr 25, 2019 at 7:19 PM abhishek raghav <
>>> abhi.raghav007 at gmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> After the migration of keycloak HA configurations from 3.4.3.Final to
>>>> 4.8.3.Final, I am seeing some WARNINGS on one of the nodes of keycloak
>>>> immediately after the keycloak is started with 2 nodes. This occurs
>>>> after
>>>> every time when the cluster is scaled up or whenever infinispan is
>>>> trying
>>>> to update the cluster member list.
>>>> I am using JDBC_PING to achieve clustering in keycloak.
>>>>
>>>> Below is the stacktrace -
>>>>
>>>> 2019-04-24 12:20:43,687 WARN
>>>> >> [org.infinispan.topology.ClusterTopologyManagerImpl]
>>>> >> (transport-thread--p18-t2) [dcidqdcosagent08] KEYCLOAK DEV 1.5.RC
>>>> >> ISPN000197: Error updating cluster member list:
>>>> >> org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed
>>>> out
>>>> >> waiting for responses for request 1 from dcidqdcosagent02
>>>> >
>>>> >                   at
>>>> >>
>>>> org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
>>>> >
>>>> >                   at
>>>> >>
>>>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
>>>> >
>>>> >                   at
>>>> >>
>>>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
>>>> >
>>>> >                   at
>>>> >> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> >
>>>> >                   at
>>>> >>
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> >
>>>> >                   at
>>>> >>
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> >
>>>> >                   at
>>>> >>
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> >
>>>> >                   at
>>>> >>
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> >
>>>> >                   at java.lang.Thread.run(Thread.java:748)
>>>> >
>>>> >                   Suppressed:
>>>> org.infinispan.util.logging.TraceException
>>>> >
>>>> >                                     at
>>>> >>
>>>> org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
>>>> >
>>>> >                                     at
>>>> >>
>>>> org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
>>>> >
>>>> >                                     at
>>>> >>
>>>> org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
>>>> >
>>>> >
>>>>
>>>> Now after I searched, I really did not see anyone reported such error on
>>>> keycloak but there is similar bug reported in WILDLFY 14 and is
>>>> categorized
>>>> as a blocker in WILDLFY 14.This bug is already fixed in WILDLFY 15.
>>>> https://issues.jboss.org/browse/WFLY-10736?attachmentViewMode=list
>>>>
>>>> Now since keycloak 4.8 is also based on WILDLFY 14, these WARNINGS
>>>> could be
>>>> because of this blocker in WILDFLY 14.
>>>>
>>>> What should I do to get rid this error. Is this really a problem in
>>>> keycloak 4.8.3.Final. Did anyone notice any such issue while running
>>>> keycloak 4.8.3 in HA mode.
>>>> Is there a workaround to fix this.
>>>>
>>>>
>>>> One more thing we noticed is - It is regarding a property in JDBC_PING
>>>> protocol we are using in our 3.4.3 setup i.e.
>>>> "clear_table_on_view_change"
>>>> but it is no more supported in 4.8 version. and thus the JGROUPSPING
>>>> table
>>>> is filled up with lot of stale entries. Is there a workaround to clear
>>>> the
>>>> table after view change in 4.8 also.
>>>>
>>>> Thanks
>>>> Abhishek
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>

From luke at code-house.org  Tue May  7 08:10:13 2019
From: luke at code-house.org (luke at code-house.org)
Date: Tue, 7 May 2019 14:10:13 +0200
Subject: [keycloak-dev] Further enhancements in token endpoint with SPI
Message-ID: <346E2769-7073-401C-9D40-3575A6F857BF@code-house.org>

Dear developers,
I follow mailing list and I been debugging some bits and pieces of Keycloak since several years. Lately I found a great contribution on device flow/auth which involves changes in Token endpoint.

As there are various grant types in OAuth 2 token endpoint is currently conjunction of several IF-ELSE statements. Would it perhaps make sense to separate actual handling of requests to smaller code units which will enable further plug-in ability in OAuth endpoints?
A name which reasonates for me now is TokenEndpointGrantHandlerSPI or similar.

Kind regards,
?ukasz
?
http://code-house.org

From sthorger at redhat.com  Wed May  8 03:38:43 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 May 2019 09:38:43 +0200
Subject: [keycloak-dev] Further enhancements in token endpoint with SPI
In-Reply-To: <346E2769-7073-401C-9D40-3575A6F857BF@code-house.org>
References: <346E2769-7073-401C-9D40-3575A6F857BF@code-house.org>
Message-ID: <CAJgngAdT_xgqYF21qWG7+pn4=eLtCRsS6nq25rDduD2LYzG7Qw@mail.gmail.com>

+1 The TokenEndpoint class is becoming a bit large and unmanageable

On Tue, 7 May 2019 at 14:12, <luke at code-house.org> wrote:

> Dear developers,
> I follow mailing list and I been debugging some bits and pieces of
> Keycloak since several years. Lately I found a great contribution on device
> flow/auth which involves changes in Token endpoint.
>
> As there are various grant types in OAuth 2 token endpoint is currently
> conjunction of several IF-ELSE statements. Would it perhaps make sense to
> separate actual handling of requests to smaller code units which will
> enable further plug-in ability in OAuth endpoints?
> A name which reasonates for me now is TokenEndpointGrantHandlerSPI or
> similar.
>
> Kind regards,
> ?ukasz
> ?
> http://code-house.org
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From slaskawi at redhat.com  Wed May  8 04:07:32 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 8 May 2019 10:07:32 +0200
Subject: [keycloak-dev] HA mode with JDBC_PING shows warning in the logs
 after migration to 4.8.3 from 3.4.3
In-Reply-To: <CAJmz6fvE77irE+4XoiRhDohXZG2-Ajp-ScaaPgWeiSDAEsqbew@mail.gmail.com>
References: <CAJmz6fvZdvj5ted0xtgnrHR4kW0Yay7SUkqO5q_FG6BQ5yxLOw@mail.gmail.com>
	<CAA9R9O5jCWQDCj3Ruf9w-kRwS9E_vK1x=dx6aLbeB5-7wESJjQ@mail.gmail.com>
	<CAJmz6fsi1HO=-MS=CuTtAj-8W_Mafw2kjHN2RS1K-r-tpoQTkg@mail.gmail.com>
	<CAA9R9O6pgH3_E776Znb3hxAHBaThnnUSuEBL=kAshR3HyWGuBA@mail.gmail.com>
	<CAJmz6fvE77irE+4XoiRhDohXZG2-Ajp-ScaaPgWeiSDAEsqbew@mail.gmail.com>
Message-ID: <CAA9R9O5h4DDfqDAbjd-AuEfoWpAntQpzxcO-+UG9XNGLwfqZCQ@mail.gmail.com>

I'm glad that worked for you. Thanks for a great feedback Abhishek!

On Tue, May 7, 2019 at 11:18 AM abhishek raghav <abhi.raghav007 at gmail.com>
wrote:

> Hi Sebastian,
>
> Thanks for the response. I got it working with a clue in your last answer.
> I am using docker based container orchestration framework which when I am
> scaling down the service is actually force killing the docker containers
> (something like kill -9), instead of a graceful shut down. So then, I
> changed my docker-entrypoint (I am using my own docker-entrypoint and not
> relying on default one which comes with keycloak image) and added *exec*
> just before the start command. something like this as below -
>
> exec /opt/jboss/keycloak/bin/standalone.sh --server-config
> standalone-ha.xml -Djboss.bind.address=${privateaddress}.....
>
> After adding  "exec", I noticed that keycloak is shutting down gracefully
> when I am scaling down the nodes in the cluster and the respective entries
> are also getting cleared off from JGROUPSPING table just as you mentioned.
>
> Looks like this there should not be anymore stale entries until the
> cluster crashes a lot.
>
> Thanks a lot for your support.
>
> - Best Regards
>   Abhishek
>
>
>
>
>
>
>
>
> On Mon, May 6, 2019 at 12:48 PM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Adding +Bela Ban <bban at redhat.com>, just in case :)
>>
>> Currently, JDBC_PING extends FILE_PING, which has some properties, that
>> works similarly to `clear_table_on_view_change`:
>> - remove_old_coords_on_view_change - If true, on a view change, the new
>> coordinator removes files from old coordinators
>> - remove_all_data_on_view_change - If true, on a view change, the new
>> coordinator removes all data except its own
>>
>> It's also worth to mention, that the coordinator clears the table when
>> shutting down (being more specific, on `JDBC_PING#stop`. So unless your
>> cluster crashes a lot (by crashing I mean calling `kill -9` for example),
>> you should be fine.
>>
>> Thanks,
>> Seb
>>
>> On Mon, Apr 29, 2019 at 9:44 AM abhishek raghav <abhi.raghav007 at gmail.com>
>> wrote:
>>
>>> Thanks Sebastian.
>>>
>>> I tried running the same setup with 5.0.0 of keycloak, I did not see any
>>> such errors which I reported in my first email. This was definitely a
>>> Wildfly issue and not keycloak.
>>>
>>> Regarding my 2nd question - i.e. support of "clear_table_on_view_change"
>>> property. I see that jgroups has removed support of this property. So lets
>>> say if JGROUPSPING table has lot stale entries, while keycloak starts
>>> booting up - each time keycloak node will try to JOIN with all the entries
>>> already present in the JGROUPSPING table and thus time taken for the
>>> service to start will be more. If that timeline is more than 300s, keycloak
>>> does not start and reports timeout error.
>>> This scenario is highly possible in cloud scenarios, since there the
>>> keycloak nodes can start on any available host/IP since no of nodes are not
>>> fixed.
>>>
>>> Can you suggest any workaround to fix this.
>>>
>>> *- Best Regards*
>>>    Abhishek Raghav
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 26, 2019 at 6:11 PM Sebastian Laskawiec <slaskawi at redhat.com>
>>> wrote:
>>>
>>>> There was a bunch of fixed to JGroups a while ago, including changes in
>>>> JDBC_PING.
>>>>
>>>> Could you please rerun your setup with Keycloak >= 5.0.0? I believe
>>>> some of the issues (or maybe even all of them) should be fixed.
>>>>
>>>> On Thu, Apr 25, 2019 at 7:19 PM abhishek raghav <
>>>> abhi.raghav007 at gmail.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> After the migration of keycloak HA configurations from 3.4.3.Final to
>>>>> 4.8.3.Final, I am seeing some WARNINGS on one of the nodes of keycloak
>>>>> immediately after the keycloak is started with 2 nodes. This occurs
>>>>> after
>>>>> every time when the cluster is scaled up or whenever infinispan is
>>>>> trying
>>>>> to update the cluster member list.
>>>>> I am using JDBC_PING to achieve clustering in keycloak.
>>>>>
>>>>> Below is the stacktrace -
>>>>>
>>>>> 2019-04-24 12:20:43,687 WARN
>>>>> >> [org.infinispan.topology.ClusterTopologyManagerImpl]
>>>>> >> (transport-thread--p18-t2) [dcidqdcosagent08] KEYCLOAK DEV 1.5.RC
>>>>> >> ISPN000197: Error updating cluster member list:
>>>>> >> org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed
>>>>> out
>>>>> >> waiting for responses for request 1 from dcidqdcosagent02
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
>>>>> >
>>>>> >                   at
>>>>> >> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>> >
>>>>> >                   at
>>>>> >>
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>> >
>>>>> >                   at java.lang.Thread.run(Thread.java:748)
>>>>> >
>>>>> >                   Suppressed:
>>>>> org.infinispan.util.logging.TraceException
>>>>> >
>>>>> >                                     at
>>>>> >>
>>>>> org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
>>>>> >
>>>>> >                                     at
>>>>> >>
>>>>> org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
>>>>> >
>>>>> >                                     at
>>>>> >>
>>>>> org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
>>>>> >
>>>>> >
>>>>>
>>>>> Now after I searched, I really did not see anyone reported such error
>>>>> on
>>>>> keycloak but there is similar bug reported in WILDLFY 14 and is
>>>>> categorized
>>>>> as a blocker in WILDLFY 14.This bug is already fixed in WILDLFY 15.
>>>>> https://issues.jboss.org/browse/WFLY-10736?attachmentViewMode=list
>>>>>
>>>>> Now since keycloak 4.8 is also based on WILDLFY 14, these WARNINGS
>>>>> could be
>>>>> because of this blocker in WILDFLY 14.
>>>>>
>>>>> What should I do to get rid this error. Is this really a problem in
>>>>> keycloak 4.8.3.Final. Did anyone notice any such issue while running
>>>>> keycloak 4.8.3 in HA mode.
>>>>> Is there a workaround to fix this.
>>>>>
>>>>>
>>>>> One more thing we noticed is - It is regarding a property in JDBC_PING
>>>>> protocol we are using in our 3.4.3 setup i.e.
>>>>> "clear_table_on_view_change"
>>>>> but it is no more supported in 4.8 version. and thus the JGROUPSPING
>>>>> table
>>>>> is filled up with lot of stale entries. Is there a workaround to clear
>>>>> the
>>>>> table after view change in 4.8 also.
>>>>>
>>>>> Thanks
>>>>> Abhishek
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>

From sthorger at redhat.com  Wed May  8 06:59:07 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 May 2019 12:59:07 +0200
Subject: [keycloak-dev] Moving container files from
 https://github.com/jboss-dockerfiles/keycloak to
 https://github.com/keycloak-containers
Message-ID: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>

I'm planning on moving https://github.com/jboss-dockerfiles/keycloak to
https://github.com/keycloak-containers.

From bruno at abstractj.org  Wed May  8 07:09:07 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 8 May 2019 08:09:07 -0300
Subject: [keycloak-dev] Moving container files from
 https://github.com/jboss-dockerfiles/keycloak to
 https://github.com/keycloak-containers
In-Reply-To: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>
References: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>
Message-ID: <CAM5SUC59odSzjnpU_aV2H9Rx0UFGCXzaGckJPo_Q5fvxVL7g7A@mail.gmail.com>

+1

On Wed, May 8, 2019 at 8:06 AM Stian Thorgersen <sthorger at redhat.com> wrote:
>
> I'm planning on moving https://github.com/jboss-dockerfiles/keycloak to
> https://github.com/keycloak-containers.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj

From slaskawi at redhat.com  Wed May  8 07:54:55 2019
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 8 May 2019 13:54:55 +0200
Subject: [keycloak-dev] Moving container files from
 https://github.com/jboss-dockerfiles/keycloak to
 https://github.com/keycloak-containers
In-Reply-To: <CAM5SUC59odSzjnpU_aV2H9Rx0UFGCXzaGckJPo_Q5fvxVL7g7A@mail.gmail.com>
References: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>
	<CAM5SUC59odSzjnpU_aV2H9Rx0UFGCXzaGckJPo_Q5fvxVL7g7A@mail.gmail.com>
Message-ID: <CAA9R9O5Q5RSY1OYUr_tQcpTNL4dyYY2qVcsSZXJ8mku1zu7XTg@mail.gmail.com>

Hey Stian,

I guess you mean ttps://github.com/keycloak/keycloak-containers
<https://github.com/keycloak-containers> (keycloak-containers repo under
keycloak organization)? If so, +1 from me.

Thanks,
Seb

On Wed, May 8, 2019 at 1:19 PM Bruno Oliveira <bruno at abstractj.org> wrote:

> +1
>
> On Wed, May 8, 2019 at 8:06 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> > I'm planning on moving https://github.com/jboss-dockerfiles/keycloak to
> > https://github.com/keycloak-containers.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> - abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed May  8 07:57:19 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 May 2019 13:57:19 +0200
Subject: [keycloak-dev] Moving container files from
 https://github.com/jboss-dockerfiles/keycloak to
 https://github.com/keycloak-containers
In-Reply-To: <CAA9R9O5Q5RSY1OYUr_tQcpTNL4dyYY2qVcsSZXJ8mku1zu7XTg@mail.gmail.com>
References: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>
	<CAM5SUC59odSzjnpU_aV2H9Rx0UFGCXzaGckJPo_Q5fvxVL7g7A@mail.gmail.com>
	<CAA9R9O5Q5RSY1OYUr_tQcpTNL4dyYY2qVcsSZXJ8mku1zu7XTg@mail.gmail.com>
Message-ID: <CAJgngAfqiXzyD91CxU9feVZczmxhufDoiyufn8+_=b3f+HmQLA@mail.gmail.com>

Yep, missed one keycloak in there ;)

On Wed, 8 May 2019 at 13:55, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey Stian,
>
> I guess you mean ttps://github.com/keycloak/keycloak-containers
> <https://github.com/keycloak-containers> (keycloak-containers repo under
> keycloak organization)? If so, +1 from me.
>
> Thanks,
> Seb
>
> On Wed, May 8, 2019 at 1:19 PM Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> +1
>>
>> On Wed, May 8, 2019 at 8:06 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> >
>> > I'm planning on moving https://github.com/jboss-dockerfiles/keycloak to
>> > https://github.com/keycloak-containers.
>> > _______________________________________________
>> > 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 demetrio at carretti.pro  Wed May  8 19:10:59 2019
From: demetrio at carretti.pro (Dmitry Telegin)
Date: Thu, 09 May 2019 02:10:59 +0300
Subject: [keycloak-dev] Proposal: Improvements to IdpUsernamePasswordForm
In-Reply-To: <2567518c-b341-27c9-b30d-8dd5fd5757a1@redhat.com>
References: <1553789204.3600.7.camel@carretti.pro>
	<664811e2-cad4-9b62-c168-39de1981afc3@redhat.com>
	<1554331537.4647.3.camel@carretti.pro>
	<d0e98de7-7825-68b2-3da6-f4cee56155ad@redhat.com>
	<1554415195.6328.1.camel@carretti.pro>
	<2567518c-b341-27c9-b30d-8dd5fd5757a1@redhat.com>
Message-ID: <1557357059.3565.13.camel@carretti.pro>

Hello Marek,

I've implemented a standalone PoC and currently in the process of
preparing a contribution.

https://github.com/eth-cscs/keycloak-link

Some points to consider:

- seems like providers cannot ship their own drop-in message bundles,
similar to theme-resources/templates, so if a provider needs to
introduce new messages, it would demand the use of a custom theme. Do
you think that could/should be improved?

- there is no way for a provider to override existing template, like
e.g. using theme-resources/templates/login.ftl - it will always be
taken from a theme. I know this is probably by design, but could we
improve that too? Currently, too much is hardwired to login.ftl, so if
you intend to modify/augment it, you'll end up copy-pasting the code.
Could the hierarchy look like this? base theme [lowest priority] ->?theme-resources [intermediate] -> custom theme [highest priority]

- LoginFormsProvider.USERNAME_EDIT_DISABLED form attribute is used
throughout the code for the following purposes:
1) disable editing the field proper;
2) hide "register" and "remember me" UI elements;
3) enable social provider filtering in LoginFormsUtil::filterIdentityProviders().

I'd suggest to split that into two, with USERNAME_EDIT_DISABLED controlling?
editability only, and some new attribute (like IDP_LINKING_MODE) responsible for the rest.

Please let me know what you think,
Dmitry

On Fri, 2019-04-05 at 08:07 +0200, Marek Posolda wrote:
> On 04/04/2019 23:59, Dmitry Telegin wrote:
> > Hi Marek,
> > 
> > On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
> > > Hi Dmitry,
> > > 
> > > On 04/04/2019 00:45, Dmitry Telegin wrote:
> > > > Hi Marek,
> > > > 
> > > > You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
> > > > - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
> > > 
> > > You're right. Small addition: The IdpUsernamePasswordForm displays
> > > social buttons, but just of those identity providers, which are already
> > > linked to specified user. In other words, if you want to link your
> > > account to broker-A and your account is already linked to broker-B, then
> > > broker-B is displayed on the form. This way, you have possibility to
> > > re-authenticate not just with your password, but alternatively by login
> > > to already linked broker-B, which is already linked to your account and
> > > hence "trusted" to be used for prove your identity.
> > > 
> > > It seems that with your proposal in case that username is unknown, we
> > > won't display any brokers on the screen and hence it will be mandatory
> > > to do re-authentication by username+password?
> > 
> > Yes, that's correct.
> > 
> > > > - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
> > > > 
> > > > federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
> > > > 
> > > > So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
> > > 
> > > I suggest to update IdpUsernamePasswordForm authenticator. In case that
> > > EXISTING_USER_INFO is not there, we can do the behaviour like:
> > > 
> > > - User will need to provide both username+password. Hence username field
> > > will need to be enabled
> > > - Social buttons won't be displayed on the login screen
> > > - Message will be bit different. For example just: Authenticate to link
> > > your account with {1}
> > > 
> > > For the case when EXISTING_USER_INFO is available, I would like to keep
> > > the same behaviour as currently is.
> > > 
> > > WDYT?
> > 
> > This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.
> 
> +1
> 
> Marek
> 
> > 
> > Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.
> > 
> > Dmitry
> > 
> > > Marek
> > > 
> > > > Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
> > > > 
> > > > Thanks!
> > > > Dmitry
> > > > 
> > > > On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
> > > > > On 28/03/2019 17:06, Dmitry Telegin wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I'm currently working to implement the following requirements:
> > > > > > - users are managed externally via LDAP, self-registrations disabled;
> > > > > > - there is an external IdP;
> > > > > > - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
> > > > > > - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
> > > > > > 
> > > > > > Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
> > > > > > However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
> > > > > > 
> > > > > > My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
> > > > > 
> > > > > I wonder if you can't already achieve something like this with the OOTB
> > > > > authenticator implementations, but just correctly configure them? For
> > > > > example in the "First Broker Login" flow used for your identity
> > > > > provider, you can just directly use the default browser-based
> > > > > authenticator ( UsernamePasswordForm ) instead of the
> > > > > IdpUsernamePasswordForm. That way, the username+password form will be
> > > > > always shown for "First Broker Login" and once user authenticates, his
> > > > > account will be linked with IdP account.
> > > > > 
> > > > > Marek
> > > > > 
> > > > > > Please let me know if you think it's worth having this in Keycloak. Regards,
> > > > > > Dmitry
> > > > > > 
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bruno at abstractj.org  Thu May  9 14:42:54 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 9 May 2019 15:42:54 -0300
Subject: [keycloak-dev] Typescript support for Node.js adapter
Message-ID: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>

Good morning, we have this PR opened long time ago
https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.
Before review it and probably update it I would like to ask.

Is Typescript something that we would like to support in the Node.js
adapter? If your answer is yes, why?

-- 
- abstractj

From chris.smith at cmfirstgroup.com  Fri May 10 03:29:40 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Fri, 10 May 2019 07:29:40 +0000
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <6592fef9-212c-ba25-4927-e7bb0bb80a75@redhat.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
	<BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>
	<6592fef9-212c-ba25-4927-e7bb0bb80a75@redhat.com>
Message-ID: <CY4PR22MB0248254EDC4DC99BC46D687E980C0@CY4PR22MB0248.namprd22.prod.outlook.com>

Well... if the build is not broken, then it is too darn persnickety.

I have a FRESH Ubuntu Server 18.04.2 VirtualBox VM
Only things installed are:
openssl
dkms
build-essential
VBOX guest additions
GIT
openjdk-8-jdk 
maven 

Only VBOX guest was not installed with apt

fresh checkout from github

run  mvn -e install --log-file ~/kc-build.txt

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[

The log can be found at https://gist.github.com/smitopher/16677dd8231869ab41527665f16e67d6

If you can't complete a build on a machine as generic and uncluttered as this, I would consider that a broken build.

Any suggestions about what I'm missing?


-----Original Message-----
From: Vlasta Ramik <vramik at redhat.com> 
Sent: Sunday, April 28, 2019 4:36 AM
To: Chris Smith <chris.smith at cmfirstgroup.com>
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] mvn install fails

 From quick look at the log, the first failed test is ClaimInformationPointProviderTest. The test fails when tries to start undertow on localhost:8989 [1] and the address is already used. Pls make sure there is nothing running on that port at you env and try to run it again.

V.

[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/client/authorization/ClaimInformationPointProviderTest.java#L79

On 4/27/19 10:21 AM, Chris Smith wrote:
> Here is a full build log 
> https://gist.github.com/smitopher/72b75e362fa6f8856b8ea1808809e918
>
>
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Wednesday, April 24, 2019 4:18 PM
> To: Chris Smith <chris.smith at cmfirstgroup.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] mvn install fails
>
> Looks like some test is failing, but you've not included the relevant part of the log that shows details of what test is failing.
>
> On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>> wrote:
> A fresh clone from Github and mvn install fails to complete.
> Any reason why?
>
> Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211
>
> [INFO] 
> ----------------------------------------------------------------------
> -- [INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
> [INFO]
> [INFO] Keycloak BOM Parent ................................ SUCCESS [ 
> 11.402 s] [INFO] Keycloak BOM for adapters .......................... 
> SUCCESS [  0.111 s] [INFO] Keycloak BOM for server extensions 
> ................. SUCCESS [  0.105 s] [INFO] Keycloak BOM utilities 
> for the quickstarts ......... SUCCESS [  0.098 s] [INFO] Keycloak 
> ........................................... SUCCESS [  1.655 s] [INFO] 
> Keycloak Common .................................... SUCCESS [ 15.064 
> s] [INFO] Keycloak Core ...................................... SUCCESS 
> [ 12.195 s] [INFO] Keycloak Dependencies Parent 
> ....................... SUCCESS [  0.130 s] [INFO] Keycloak Drools BOM 
> ................................ SUCCESS [  0.129 s] [INFO] Keycloak 
> Server SPI ................................ SUCCESS [  3.287 s] [INFO] 
> Keycloak Server Private SPI ........................ SUCCESS [  8.419 
> s] [INFO] Keycloak Kerberos Federation ....................... SUCCESS 
> [  0.910 s] [INFO] Keycloak LDAP UserStoreProvider 
> .................... SUCCESS [  7.065 s] [INFO] Keycloak SAML Core 
> Public API ...................... SUCCESS [  2.849 s] [INFO] Keycloak 
> SAML Core ................................. SUCCESS [  9.528 s] [INFO] 
> Keycloak REST Services ............................. SUCCESS [ 25.199 
> s] [INFO] Keycloak JS Integration ............................ SUCCESS 
> [  5.176 s] [INFO] Keycloak Themes 
> .................................... SUCCESS [  9.625 s] [INFO] 
> Keycloak Dependencies Server Min ................... SUCCESS [  0.139 
> s] [INFO] Keycloak Model Parent .............................. SUCCESS 
> [  0.139 s] [INFO] Keycloak Model JPA 
> ................................. SUCCESS [  7.185 s] [INFO] Keycloak 
> Model Infinispan .......................... SUCCESS [ 13.296 s] [INFO] 
> Keycloak SSSD Federation ........................... SUCCESS [  5.565 
> s] [INFO] KeyCloak Authz: Parent ............................. SUCCESS 
> [  0.222 s] [INFO] KeyCloak AuthZ: Provider Parent 
> .................... SUCCESS [  0.182 s] [INFO] KeyCloak AuthZ: Common 
> Policy Providers ............ SUCCESS [  2.537 s] [INFO] KeyCloak 
> AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s] [INFO] 
> Keycloak Dependencies Server All ................... SUCCESS [  0.195 
> s] [INFO] Keycloak Federation ................................ SUCCESS 
> [  0.220 s] [INFO] Keycloak Util Embedded LDAP 
> ........................ SUCCESS [  3.089 s] [INFO] Keycloak Util 
> Parent ............................... SUCCESS [  0.209 s] [INFO] 
> Keycloak WildFly Integration ....................... SUCCESS [  0.184 
> s] [INFO] Keycloak WildFly Add User Script ................... SUCCESS 
> [  1.151 s] [INFO] Keycloak WildFly Extensions 
> ........................ SUCCESS [  1.184 s] [INFO] Keycloak WildFly 
> Server Subsystem .................. SUCCESS [  8.763 s] [INFO] 
> Keycloak Integration ............................... SUCCESS [  0.133 
> s] [INFO] Keycloak Admin REST Client ......................... SUCCESS 
> [  1.111 s] [INFO] Keycloak Client Registration API 
> ................... SUCCESS [  0.736 s] [INFO] Keycloak Client CLI 
> ................................ SUCCESS [  0.133 s] [INFO] Keycloak 
> Client Registration CLI ................... SUCCESS [  6.737 s] [INFO] 
> Keycloak Admin CLI ................................. SUCCESS [  5.972 
> s] [INFO] Keycloak Client CLI Distribution ................... SUCCESS 
> [  3.475 s] [INFO] Keycloak Adapter SPI 
> ............................... SUCCESS [  0.939 s] [INFO] Keycloak 
> Tomcat Adapter SPI ........................ SUCCESS [  0.822 s] [INFO] 
> Keycloak Undertow Integration SPI .................. SUCCESS [  1.166 
> s] [INFO] Keycloak Servlet Integration ....................... SUCCESS 
> [  0.828 s] [INFO] Common JBoss/Wildfly Core Classes 
> .................. SUCCESS [  0.591 s] [INFO] Keycloak Jetty Adapter 
> SPI ......................... SUCCESS [  0.928 s] [INFO] Keycloak 
> Client Adapter SPI Modules ................ SUCCESS [  0.163 s] [INFO] 
> Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621 
> s] [INFO] Keycloak SAML Client Adapter Core .................. SUCCESS 
> [  5.196 s] [INFO] Keycloak Undertow SAML Adapter 
> ..................... SUCCESS [  1.009 s] [INFO] Keycloak SAML Tomcat 
> Integration ................... SUCCESS [  0.165 s] [INFO] Keycloak 
> Tomcat Core SAML Integration .............. SUCCESS [  0.839 s] [INFO] 
> Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743 
> s] [INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS 
> [  0.617 s] [INFO] Keycloak Tomcat 7 SAML Integration 
> ................. SUCCESS [  0.625 s] [INFO] Keycloak Wildfly SAML 
> Adapter ...................... SUCCESS [  0.999 s] [INFO] KeyCloak 
> Authz: Client API ......................... SUCCESS [  1.963 s] [INFO] 
> Keycloak Adapter Core .............................. SUCCESS [  6.558 
> s] [INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS 
> [  1.130 s] [INFO] Keycloak Wildfly SAML Adapter Subsystem 
> ............ SUCCESS [  7.527 s] [INFO] Keycloak SAML Wildfly 
> Integration .................. SUCCESS [  0.146 s] [INFO] Keycloak AS7 
> / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s] [INFO] 
> Keycloak AS7 SPI ................................... SUCCESS [  3.170 
> s] [INFO] Keycloak SAML EAP Integration ...................... SUCCESS 
> [  0.130 s] [INFO] Keycloak SAML AS7 Integration 
> ...................... SUCCESS [  1.062 s] [INFO] Keycloak SAML AS7 
> Subsystem ........................ SUCCESS [  5.323 s] [INFO] Keycloak 
> SAML Servlet Filter ....................... SUCCESS [  0.804 s] [INFO] 
> Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865 
> s] [INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS 
> [  0.820 s] [INFO] Keycloak Jetty 9.3.x SAML Integration 
> .............. SUCCESS [  0.894 s] [INFO] Keycloak Jetty 9.4.x SAML 
> Integration .............. SUCCESS [  1.066 s] [INFO] Keycloak SAML 
> Jetty Integration .................... SUCCESS [  0.144 s] [INFO] 
> Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132 
> s] [INFO] Keycloak Tomcat Integration ........................ SUCCESS 
> [  0.140 s] [INFO] Keycloak Tomcat Core Integration 
> ................... SUCCESS [  0.758 s] [INFO] Keycloak AS7 
> Integration ........................... SUCCESS [  0.906 s] [INFO] 
> Keycloak AS7 Subsystem ............................. SUCCESS [  4.368 
> s] [INFO] Keycloak Installed Application ..................... SUCCESS 
> [  1.609 s] [INFO] Keycloak Undertow Integration 
> ...................... SUCCESS [  2.295 s] [INFO] Keycloak Fuse 7.0 
> Integration ...................... SUCCESS [  0.161 s] [INFO] Keycloak 
> Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s] [INFO] 
> Keycloak OSGI Adapter .............................. SUCCESS [  3.531 
> s] [INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS 
> [  1.514 s] [INFO] Keycloak Jetty Core Integration 
> .................... SUCCESS [  1.175 s] [INFO] Keycloak Jetty 9.4.x 
> Integration ................... SUCCESS [  0.945 s] [INFO] Keycloak 
> Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s] [INFO] 
> Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767 
> s] [INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS 
> [  1.105 s] [INFO] Keycloak CLI SSO Framework 
> ......................... SUCCESS [  4.620 s] [INFO] Keycloak JAX-RS 
> OAuth Client ....................... SUCCESS [  1.314 s] [INFO] 
> Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142 
> s] [INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS 
> [  1.144 s] [INFO] Keycloak Jetty Integration 
> ......................... SUCCESS [  0.173 s] [INFO] Keycloak Servlet 
> Filter Adapter Integration ........ SUCCESS [  1.061 s] [INFO] 
> Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150 
> s] [INFO] spring-boot-container-bundle ....................... SUCCESS 
> [  1.761 s] [INFO] Keycloak Spring Security Integration 
> ............... SUCCESS [  8.449 s] [INFO] Keycloak Spring Boot 
> Adapter Core .................. SUCCESS [  1.759 s] [INFO] Keycloak 
> Spring Boot Integration ................... SUCCESS [  4.437 s] [INFO] 
> Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172 
> s] [INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS 
> [  0.689 s] [INFO] Keycloak Tomcat 7 Integration 
> ...................... SUCCESS [  0.761 s] [INFO] Keycloak Wildfly 
> Integration ....................... SUCCESS [  0.998 s] [INFO] 
> Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763 
> s] [INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS 
> [  8.862 s] [INFO] Keycloak Wildfly 8 Adapter Subsystem 
> ............... SUCCESS [  5.703 s] [INFO] Keycloak WildFly 
> Integration ....................... SUCCESS [  0.138 s] [INFO] 
> Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124 
> s] [INFO] Keycloak Adapters .................................. SUCCESS 
> [  0.130 s] [INFO] Keycloak Misc 
> ...................................... SUCCESS [  0.138 s] [INFO] 
> Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148 
> s] [INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS 
> [  0.371 s] [INFO] Keycloak :: Spring :: Boot 
> ......................... SUCCESS [  0.139 s] [INFO] Keycloak :: 
> Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s] 
> [INFO] keycloak-test-helper ............................... SUCCESS [  
> 0.937 s] [INFO] Keycloak TestSuite ................................. 
> SUCCESS [  0.128 s] [INFO] DB Allocator Plugin 
> ................................ SUCCESS [ 14.444 s] [INFO] Keycloak 
> Arquillian Integration TestSuite .......... SUCCESS [  0.212 s] [INFO] 
> Test apps .......................................... SUCCESS [  0.144 
> s] [INFO] Test apps distribution ............................. SUCCESS 
> [  7.201 s] [INFO] Keycloak Authz: PhotoZ  Test Parent 
> ................ SUCCESS [  0.145 s] [INFO] Keycloak Authz Test: 
> Photoz RESTful API ............ SUCCESS [  1.871 s] [INFO] Keycloak 
> Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s] [INFO] 
> Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442 
> s] [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS 
> [  0.406 s] [INFO] Keycloak Authz: Servlet Authorization Test 
> ......... SUCCESS [  0.577 s] [INFO] Keycloak Authz: Simple Servlet 
> App with Policy Enforcer SUCCESS [  0.393 s] [INFO] 
> integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327 
> s] [INFO] Keycloak Test App Profile JEE ...................... SUCCESS 
> [  0.638 s] [INFO] integration-arquillian-test-apps-cors-parent 
> ....... SUCCESS [  0.144 s] [INFO] Angular Product Portal JS 
> .......................... SUCCESS [  2.995 s] [INFO] JAX-RS Database 
> Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s] [INFO] Fuse 
> Test Applications ............................. SUCCESS [  0.139 s] 
> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [  
> 1.778 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse .......... 
> SUCCESS [  2.099 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse 
> 7.0 on Undertow SUCCESS [  0.798 s] [INFO] CXF JAXWS Example - Secured 
> in Karaf/Fuse .......... SUCCESS [  1.012 s] [INFO] CXF JAXWS Example 
> - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s] [INFO] 
> Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960 
> s] [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow 
> SUCCESS [  1.012 s] [INFO] Camel endpoint example - Secured in 
> Karaf/Fuse ..... SUCCESS [  0.779 s] [INFO] Camel endpoint example - 
> Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s] [INFO] 
> Keycloak Fuse Example - Features ................... SUCCESS [  0.670 
> s] [INFO] Keycloak Examples - External Config ................ SUCCESS 
> [  0.776 s] [INFO] spring-boot-adapter 
> ................................ SUCCESS [  1.358 s] [INFO] 
> spring-boot-adapter-2 .............................. SUCCESS [  1.571 
> s] [INFO] spring-boot-adapter-21 ............................. SUCCESS 
> [  1.435 s] [INFO] Servers 
> ............................................ SUCCESS [  0.152 s] 
> [INFO] Auth Server ........................................ SUCCESS [  
> 0.127 s] [INFO] Auth Server Services ............................... 
> SUCCESS [  0.129 s] [INFO] Auth Server Services - Testsuite Providers 
> ......... SUCCESS [  5.076 s] [INFO] Auth Server - JBoss 
> ................................ SUCCESS [  0.131 s] [INFO] Keycloak 
> TestSuite Utils ........................... SUCCESS [  2.794 s] [INFO] 
> Test Util .......................................... SUCCESS [  1.798 
> s] [INFO] Auth Server - Undertow ............................. SUCCESS 
> [  2.305 s] [INFO] App Server 
> ......................................... SUCCESS [  0.137 s] [INFO] 
> App Server - SPI ................................... SUCCESS [  0.541 
> s] [INFO] App Server - JBoss ................................. SUCCESS 
> [  0.132 s] [INFO] App Server - Karaf 
> ................................. SUCCESS [  0.127 s] [INFO] App 
> Server - Tomcat ................................ SUCCESS [  0.130 s] 
> [INFO] App Server - Undertow .............................. SUCCESS [  
> 1.122 s] [INFO] App Server - Jetty Parent .......................... 
> SUCCESS [  0.151 s] [INFO] Cache Server 
> ....................................... SUCCESS [  0.119 s] [INFO] 
> Cache Server - JBoss Family ........................ SUCCESS [  0.124 
> s] [INFO] Tests .............................................. SUCCESS 
> [  0.493 s] [INFO] Base TestSuite 
> ..................................... FAILURE [  01:45 h] [INFO] Other 
> Tests Modules ................................ SKIPPED [INFO] Adapter 
> Tests ...................................... SKIPPED [INFO] Adapter 
> Tests - JBoss .............................. SKIPPED [INFO] Adapter 
> Tests - Karaf .............................. SKIPPED [INFO] Adapter 
> Tests - WAS ................................ SKIPPED [INFO] Adapter 
> Tests - WLS ................................ SKIPPED [INFO] SSSD tests 
> ......................................... SKIPPED [INFO] 
> integration-arquillian-tests-springboot ............ SKIPPED [INFO] 
> ----------------------------------------------------------------------
> --
> [INFO] BUILD FAILURE
> [INFO] 
> ----------------------------------------------------------------------
> --
> [INFO] Total time:  01:51 h
> [INFO] Finished at: 2019-04-23T19:51:55+08:00 [INFO] 
> ----------------------------------------------------------------------
> -- [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project integration-arquillian-tests-base: There are test failures.
> [ERROR]
> [ERROR] Please refer to C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
>
> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-paren
> t> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From takashi.norimatsu.ws at hitachi.com  Fri May 10 03:49:30 2019
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Fri, 10 May 2019 07:49:30 +0000
Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j
 extension
In-Reply-To: <CAJgngAfL6u=Z9AY5cVftZAvK=bgMa-w2QO24Pf5+yeWv4XEaqQ@mail.gmail.com>
References: <TYAPR01MB2447049C0687F3EFE4AE4244C92F0@TYAPR01MB2447.jpnprd01.prod.outlook.com>
	<CAJgngAfL6u=Z9AY5cVftZAvK=bgMa-w2QO24Pf5+yeWv4XEaqQ@mail.gmail.com>
Message-ID: <OSAPR01MB438701BEA878FA71D3846735CE0C0@OSAPR01MB4387.jpnprd01.prod.outlook.com>

Thank you for comments.

>* Don't require clicking "Authenticate" button, it's confusing and should happen automatically
>* Use a required action for registration, not an authenticator and custom registration flow. This fits better with the future plans of application initiated actions, and also allows users not self-registered.

Yes, I agree with you. I'll revise our prototype.

>* Don't use custom table for credentials. I see it's marked as an open issue, but just wanted to mention it again. Custom entities are not supported, this has issues with hot-deployment and I don't want to have to add additional tables for each credential type.

Could you please the following master branch? I hope this would resolve your concern.
https://github.com/webauthn4j/keycloak-webauthn-authenticator/

At first, I've referred to FIDO U2F Authenticator for Keycloak.
https://github.com/stianst/keycloak-experimental/tree/master/fido-u2f

And, I've used the existing credential store as follows instead of creating a new table.
https://github.com/webauthn4j/keycloak-webauthn-authenticator/issues/7

>* Problems on re-build/deploy as mentioned in open issues is related to two things I think. Firstly, the above with regards to custom entities. Secondly, we have an issue that theme resources are not re-loaded on re-load (see https://issues.jboss.org/browse/KEYCLOAK-8044).

I see. I'll watch this issue.

>With regards to testing have you done any research into possibility of functional testing? I know we've discussed this in the past, but not sure if any progress has been made here.

I'm currently investigating it. Firstly, I'll clarify whether I can use "Web Authentication Testing API" suggested by Yoshikazu Nojima in https://issues.jboss.org/browse/KEYCLOAK-9359 for Arquillian integration tests.

Regards,
Takashi Norimatsu

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Monday, April 29, 2019 8:08 PM
To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension

Sorry for late reply. Finally found some time to try this out. It works pretty well for me, but here's a few discussion points:

* Don't require clicking "Authenticate" button, it's confusing and should happen automatically
* Use a required action for registration, not an authenticator and custom registration flow. This fits better with the future plans of application initiated actions, and also allows users not self-registered.
* Don't use custom table for credentials. I see it's marked as an open issue, but just wanted to mention it again. Custom entities are not supported, this has issues with hot-deployment and I don't want to have to add additional tables for each credential type.
* Problems on re-build/deploy as mentioned in open issues is related to two things I think. Firstly, the above with regards to custom entities.
Secondly, we have an issue that theme resources are not re-loaded on re-load (see https://clicktime.symantec.com/3JzfAFCPayipxzHfDuqGJYs7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-8044).

With regards to testing have you done any research into possibility of functional testing? I know we've discussed this in the past, but not sure if any progress has been made here.



On Thu, 11 Apr 2019 at 05:56, ???? / NAKAMURA?YUUICHI < yuichi.nakamura.fe at hitachi.com> wrote:

> Hi,
>
> We've updated the webauthn authenticator prototype based on webauthn4j :
>
> https://clicktime.symantec.com/3WCzrfPNkLpaxtUGpjWEzmE7Vc?u=https%3A%2
> F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator%2Ftree%2
> Fdemo-completed
>
> We've confirmed that this demo worked well under the following
> environments:
> * U2F with Resident Key Not supported Authenticator Scenario OS : 
> Windows 10 Browser : Google Chrome (ver 73), Mozilla FireFox (ver 66) 
> Authenticator : Yubico Security Key
> Server(RP) : keycloak-5.0.0
>
> * U2F with Resident Key supported Authenticator Scenario OS : Windows 
> 10 Browser : Microsoft Edge (ver 44) Authenticator : Internal 
> Fingerprint Authentication Device
> Server(RP) : keycloak-5.0.0
>
> * UAF with Resident Key supported Authenticator Scenario OS : Windows 
> 10 Browser : Microsoft Edge (ver 44) Authenticator : Internal 
> Fingerprint Authentication Device
> Server(RP) : keycloak-5.0.0
>
> We will continue to improve the prototype, so feedback is welcomed.
>
> Regards,
> Yuichi Nakamura
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org < 
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of ???? / 
> NAKAMURA?YUUICHI
> Sent: Tuesday, March 19, 2019 4:32 PM
> To: stian at redhat.com
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an 
> WebAuthn4j extension
>
> Hi,
>
> Sorry, we have implemented only for Edge now.
> Please wait for other browsers.
>
> > One comment is that it shouldn't create a new table, but rather just
> serialize the value to the existing credential table in the same way 
> as the FIDO U2F example does [1].
> Thank you, we will fix.
>
> Regards,
> Yuichi Nakamura
>
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Sent: Monday, March 18, 2019 5:49 PM
> To: ???? / NAKAMURA?YUUICHI <yuichi.nakamura.fe at hitachi.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>; ???? / 
> NORIMATSU?TAKASHI
> <takashi.norimatsu.ws at hitachi.com>; ???? / MOGI?TAKASHI < 
> takashi.mogi.ep at hitachi.com>; Yoshikazu Nojima <mail at ynojima.net>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an 
> WebAuthn4j extension
>
> Tried this out today and it didn't work for me. I was getting some JS 
> error both on Chrome and Firefox when trying to register authenticator.
>
> One comment is that it shouldn't create a new table, but rather just 
> serialize the value to the existing credential table in the same way 
> as the FIDO U2F example does [1].
>
> [1]
> https://clicktime.symantec.com/3XYorxFfnwRutc8N4z3Ubc77Vc?u=https%3A%2
> F%2Fgithub.com%2Fstianst%2Fkeycloak-experimental%2Ftree%2Fmaster%2Ffid
> o-u2f
>
> On Fri, 15 Mar 2019 at 08:13, ???? / NAKAMURA?YUUICHI <mailto:
> yuichi.nakamura.fe at hitachi.com> wrote:
> Hi,
>
> We?ve uploaded the initial prototype of webauthn authenticator below:
> https://clicktime.symantec.com/37NWG7BAMWtR42Swt5VUTw77Vc?u=https%3A%2
> F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator
>
> Feedback is welcomed.
>
> From: Stian Thorgersen <mailto:sthorger at redhat.com>
> Sent: Thursday, February 28, 2019 6:53 PM
> To: ???? / NAKAMURA?YUUICHI <mailto:yuichi.nakamura.fe at hitachi.com>
> Cc: keycloak-dev <mailto:keycloak-dev at lists.jboss.org>
> Subject: [!]Re: [keycloak-dev] Request for someone to contribute an 
> WebAuthn4j extension
>
> That's great, thanks.
>
> Do you have an idea on roughly when you can have a prototype ready?
>
> On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI <mailto:mailto:
> yuichi.nakamura.fe at hitachi.com> wrote:
> Hi,
>
> My team has begun to help webauthn4j project, and is going to develop 
> prototype of authenticator for keycloak.
> We'd like to take this.
>
> Regards,
> Yuichi Nakamura
> Hitachi, Ltd.
>
> -----Original Message-----
> From: mailto:mailto:keycloak-dev-bounces at lists.jboss.org <mailto:mailto:
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: Thursday, February 28, 2019 12:26 AM
> To: keycloak-dev <mailto:mailto:keycloak-dev at lists.jboss.org>
> Subject: [!][keycloak-dev] Request for someone to contribute an 
> WebAuthn4j extension
>
> A while back I created an experimental extension to Keycloak for FIDO U2F.
> It would be great if someone could adapt this to WebAuthn by 
> leveraging webauthn4j library [1].
>
> Any takers? It shouldn't be hard ;)
>
> [1]
> https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2
> F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j
> _______________________________________________
> keycloak-dev mailing list
> mailto:mailto:keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
>
> https://clicktime.symantec.com/3K7AmDtC5f54UYS4NNrH1wo7Vc?u=https%3A%2
> F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://clicktime.symantec.com/3NyVEGQ7RdnBC2VTZQtDSHz7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev


From vramik at redhat.com  Fri May 10 04:12:31 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Fri, 10 May 2019 10:12:31 +0200
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <CY4PR22MB0248254EDC4DC99BC46D687E980C0@CY4PR22MB0248.namprd22.prod.outlook.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
	<BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>
	<6592fef9-212c-ba25-4927-e7bb0bb80a75@redhat.com>
	<CY4PR22MB0248254EDC4DC99BC46D687E980C0@CY4PR22MB0248.namprd22.prod.outlook.com>
Message-ID: <fdd5669e-7d75-5fb1-ac6a-64b4b6d4aaac@redhat.com>

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

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

On 5/10/19 9:29 AM, Chris Smith wrote:
> Well... if the build is not broken, then it is too darn persnickety.
>
> I have a FRESH Ubuntu Server 18.04.2 VirtualBox VM
> Only things installed are:
> openssl
> dkms
> build-essential
> VBOX guest additions
> GIT
> openjdk-8-jdk
> maven
>
> Only VBOX guest was not installed with apt
>
> fresh checkout from github
>
> run  mvn -e install --log-file ~/kc-build.txt
>
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [
>
> The log can be found at https://gist.github.com/smitopher/16677dd8231869ab41527665f16e67d6
>
> If you can't complete a build on a machine as generic and uncluttered as this, I would consider that a broken build.
>
> Any suggestions about what I'm missing?
>
>
> -----Original Message-----
> From: Vlasta Ramik <vramik at redhat.com>
> Sent: Sunday, April 28, 2019 4:36 AM
> To: Chris Smith <chris.smith at cmfirstgroup.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] mvn install fails
>
>   From quick look at the log, the first failed test is ClaimInformationPointProviderTest. The test fails when tries to start undertow on localhost:8989 [1] and the address is already used. Pls make sure there is nothing running on that port at you env and try to run it again.
>
> V.
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/client/authorization/ClaimInformationPointProviderTest.java#L79
>
> On 4/27/19 10:21 AM, Chris Smith wrote:
>> Here is a full build log
>> https://gist.github.com/smitopher/72b75e362fa6f8856b8ea1808809e918
>>
>>
>>
>> From: Stian Thorgersen <sthorger at redhat.com>
>> Sent: Wednesday, April 24, 2019 4:18 PM
>> To: Chris Smith <chris.smith at cmfirstgroup.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] mvn install fails
>>
>> Looks like some test is failing, but you've not included the relevant part of the log that shows details of what test is failing.
>>
>> On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>> wrote:
>> A fresh clone from Github and mvn install fails to complete.
>> Any reason why?
>>
>> Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211
>>
>> [INFO]
>> ----------------------------------------------------------------------
>> -- [INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
>> [INFO]
>> [INFO] Keycloak BOM Parent ................................ SUCCESS [
>> 11.402 s] [INFO] Keycloak BOM for adapters ..........................
>> SUCCESS [  0.111 s] [INFO] Keycloak BOM for server extensions
>> ................. SUCCESS [  0.105 s] [INFO] Keycloak BOM utilities
>> for the quickstarts ......... SUCCESS [  0.098 s] [INFO] Keycloak
>> ........................................... SUCCESS [  1.655 s] [INFO]
>> Keycloak Common .................................... SUCCESS [ 15.064
>> s] [INFO] Keycloak Core ...................................... SUCCESS
>> [ 12.195 s] [INFO] Keycloak Dependencies Parent
>> ....................... SUCCESS [  0.130 s] [INFO] Keycloak Drools BOM
>> ................................ SUCCESS [  0.129 s] [INFO] Keycloak
>> Server SPI ................................ SUCCESS [  3.287 s] [INFO]
>> Keycloak Server Private SPI ........................ SUCCESS [  8.419
>> s] [INFO] Keycloak Kerberos Federation ....................... SUCCESS
>> [  0.910 s] [INFO] Keycloak LDAP UserStoreProvider
>> .................... SUCCESS [  7.065 s] [INFO] Keycloak SAML Core
>> Public API ...................... SUCCESS [  2.849 s] [INFO] Keycloak
>> SAML Core ................................. SUCCESS [  9.528 s] [INFO]
>> Keycloak REST Services ............................. SUCCESS [ 25.199
>> s] [INFO] Keycloak JS Integration ............................ SUCCESS
>> [  5.176 s] [INFO] Keycloak Themes
>> .................................... SUCCESS [  9.625 s] [INFO]
>> Keycloak Dependencies Server Min ................... SUCCESS [  0.139
>> s] [INFO] Keycloak Model Parent .............................. SUCCESS
>> [  0.139 s] [INFO] Keycloak Model JPA
>> ................................. SUCCESS [  7.185 s] [INFO] Keycloak
>> Model Infinispan .......................... SUCCESS [ 13.296 s] [INFO]
>> Keycloak SSSD Federation ........................... SUCCESS [  5.565
>> s] [INFO] KeyCloak Authz: Parent ............................. SUCCESS
>> [  0.222 s] [INFO] KeyCloak AuthZ: Provider Parent
>> .................... SUCCESS [  0.182 s] [INFO] KeyCloak AuthZ: Common
>> Policy Providers ............ SUCCESS [  2.537 s] [INFO] KeyCloak
>> AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s] [INFO]
>> Keycloak Dependencies Server All ................... SUCCESS [  0.195
>> s] [INFO] Keycloak Federation ................................ SUCCESS
>> [  0.220 s] [INFO] Keycloak Util Embedded LDAP
>> ........................ SUCCESS [  3.089 s] [INFO] Keycloak Util
>> Parent ............................... SUCCESS [  0.209 s] [INFO]
>> Keycloak WildFly Integration ....................... SUCCESS [  0.184
>> s] [INFO] Keycloak WildFly Add User Script ................... SUCCESS
>> [  1.151 s] [INFO] Keycloak WildFly Extensions
>> ........................ SUCCESS [  1.184 s] [INFO] Keycloak WildFly
>> Server Subsystem .................. SUCCESS [  8.763 s] [INFO]
>> Keycloak Integration ............................... SUCCESS [  0.133
>> s] [INFO] Keycloak Admin REST Client ......................... SUCCESS
>> [  1.111 s] [INFO] Keycloak Client Registration API
>> ................... SUCCESS [  0.736 s] [INFO] Keycloak Client CLI
>> ................................ SUCCESS [  0.133 s] [INFO] Keycloak
>> Client Registration CLI ................... SUCCESS [  6.737 s] [INFO]
>> Keycloak Admin CLI ................................. SUCCESS [  5.972
>> s] [INFO] Keycloak Client CLI Distribution ................... SUCCESS
>> [  3.475 s] [INFO] Keycloak Adapter SPI
>> ............................... SUCCESS [  0.939 s] [INFO] Keycloak
>> Tomcat Adapter SPI ........................ SUCCESS [  0.822 s] [INFO]
>> Keycloak Undertow Integration SPI .................. SUCCESS [  1.166
>> s] [INFO] Keycloak Servlet Integration ....................... SUCCESS
>> [  0.828 s] [INFO] Common JBoss/Wildfly Core Classes
>> .................. SUCCESS [  0.591 s] [INFO] Keycloak Jetty Adapter
>> SPI ......................... SUCCESS [  0.928 s] [INFO] Keycloak
>> Client Adapter SPI Modules ................ SUCCESS [  0.163 s] [INFO]
>> Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621
>> s] [INFO] Keycloak SAML Client Adapter Core .................. SUCCESS
>> [  5.196 s] [INFO] Keycloak Undertow SAML Adapter
>> ..................... SUCCESS [  1.009 s] [INFO] Keycloak SAML Tomcat
>> Integration ................... SUCCESS [  0.165 s] [INFO] Keycloak
>> Tomcat Core SAML Integration .............. SUCCESS [  0.839 s] [INFO]
>> Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743
>> s] [INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS
>> [  0.617 s] [INFO] Keycloak Tomcat 7 SAML Integration
>> ................. SUCCESS [  0.625 s] [INFO] Keycloak Wildfly SAML
>> Adapter ...................... SUCCESS [  0.999 s] [INFO] KeyCloak
>> Authz: Client API ......................... SUCCESS [  1.963 s] [INFO]
>> Keycloak Adapter Core .............................. SUCCESS [  6.558
>> s] [INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS
>> [  1.130 s] [INFO] Keycloak Wildfly SAML Adapter Subsystem
>> ............ SUCCESS [  7.527 s] [INFO] Keycloak SAML Wildfly
>> Integration .................. SUCCESS [  0.146 s] [INFO] Keycloak AS7
>> / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s] [INFO]
>> Keycloak AS7 SPI ................................... SUCCESS [  3.170
>> s] [INFO] Keycloak SAML EAP Integration ...................... SUCCESS
>> [  0.130 s] [INFO] Keycloak SAML AS7 Integration
>> ...................... SUCCESS [  1.062 s] [INFO] Keycloak SAML AS7
>> Subsystem ........................ SUCCESS [  5.323 s] [INFO] Keycloak
>> SAML Servlet Filter ....................... SUCCESS [  0.804 s] [INFO]
>> Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865
>> s] [INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS
>> [  0.820 s] [INFO] Keycloak Jetty 9.3.x SAML Integration
>> .............. SUCCESS [  0.894 s] [INFO] Keycloak Jetty 9.4.x SAML
>> Integration .............. SUCCESS [  1.066 s] [INFO] Keycloak SAML
>> Jetty Integration .................... SUCCESS [  0.144 s] [INFO]
>> Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132
>> s] [INFO] Keycloak Tomcat Integration ........................ SUCCESS
>> [  0.140 s] [INFO] Keycloak Tomcat Core Integration
>> ................... SUCCESS [  0.758 s] [INFO] Keycloak AS7
>> Integration ........................... SUCCESS [  0.906 s] [INFO]
>> Keycloak AS7 Subsystem ............................. SUCCESS [  4.368
>> s] [INFO] Keycloak Installed Application ..................... SUCCESS
>> [  1.609 s] [INFO] Keycloak Undertow Integration
>> ...................... SUCCESS [  2.295 s] [INFO] Keycloak Fuse 7.0
>> Integration ...................... SUCCESS [  0.161 s] [INFO] Keycloak
>> Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s] [INFO]
>> Keycloak OSGI Adapter .............................. SUCCESS [  3.531
>> s] [INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS
>> [  1.514 s] [INFO] Keycloak Jetty Core Integration
>> .................... SUCCESS [  1.175 s] [INFO] Keycloak Jetty 9.4.x
>> Integration ................... SUCCESS [  0.945 s] [INFO] Keycloak
>> Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s] [INFO]
>> Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767
>> s] [INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS
>> [  1.105 s] [INFO] Keycloak CLI SSO Framework
>> ......................... SUCCESS [  4.620 s] [INFO] Keycloak JAX-RS
>> OAuth Client ....................... SUCCESS [  1.314 s] [INFO]
>> Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142
>> s] [INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS
>> [  1.144 s] [INFO] Keycloak Jetty Integration
>> ......................... SUCCESS [  0.173 s] [INFO] Keycloak Servlet
>> Filter Adapter Integration ........ SUCCESS [  1.061 s] [INFO]
>> Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150
>> s] [INFO] spring-boot-container-bundle ....................... SUCCESS
>> [  1.761 s] [INFO] Keycloak Spring Security Integration
>> ............... SUCCESS [  8.449 s] [INFO] Keycloak Spring Boot
>> Adapter Core .................. SUCCESS [  1.759 s] [INFO] Keycloak
>> Spring Boot Integration ................... SUCCESS [  4.437 s] [INFO]
>> Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172
>> s] [INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS
>> [  0.689 s] [INFO] Keycloak Tomcat 7 Integration
>> ...................... SUCCESS [  0.761 s] [INFO] Keycloak Wildfly
>> Integration ....................... SUCCESS [  0.998 s] [INFO]
>> Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763
>> s] [INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS
>> [  8.862 s] [INFO] Keycloak Wildfly 8 Adapter Subsystem
>> ............... SUCCESS [  5.703 s] [INFO] Keycloak WildFly
>> Integration ....................... SUCCESS [  0.138 s] [INFO]
>> Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124
>> s] [INFO] Keycloak Adapters .................................. SUCCESS
>> [  0.130 s] [INFO] Keycloak Misc
>> ...................................... SUCCESS [  0.138 s] [INFO]
>> Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148
>> s] [INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS
>> [  0.371 s] [INFO] Keycloak :: Spring :: Boot
>> ......................... SUCCESS [  0.139 s] [INFO] Keycloak ::
>> Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s]
>> [INFO] keycloak-test-helper ............................... SUCCESS [
>> 0.937 s] [INFO] Keycloak TestSuite .................................
>> SUCCESS [  0.128 s] [INFO] DB Allocator Plugin
>> ................................ SUCCESS [ 14.444 s] [INFO] Keycloak
>> Arquillian Integration TestSuite .......... SUCCESS [  0.212 s] [INFO]
>> Test apps .......................................... SUCCESS [  0.144
>> s] [INFO] Test apps distribution ............................. SUCCESS
>> [  7.201 s] [INFO] Keycloak Authz: PhotoZ  Test Parent
>> ................ SUCCESS [  0.145 s] [INFO] Keycloak Authz Test:
>> Photoz RESTful API ............ SUCCESS [  1.871 s] [INFO] Keycloak
>> Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s] [INFO]
>> Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442
>> s] [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS
>> [  0.406 s] [INFO] Keycloak Authz: Servlet Authorization Test
>> ......... SUCCESS [  0.577 s] [INFO] Keycloak Authz: Simple Servlet
>> App with Policy Enforcer SUCCESS [  0.393 s] [INFO]
>> integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327
>> s] [INFO] Keycloak Test App Profile JEE ...................... SUCCESS
>> [  0.638 s] [INFO] integration-arquillian-test-apps-cors-parent
>> ....... SUCCESS [  0.144 s] [INFO] Angular Product Portal JS
>> .......................... SUCCESS [  2.995 s] [INFO] JAX-RS Database
>> Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s] [INFO] Fuse
>> Test Applications ............................. SUCCESS [  0.139 s]
>> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [
>> 1.778 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse ..........
>> SUCCESS [  2.099 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse
>> 7.0 on Undertow SUCCESS [  0.798 s] [INFO] CXF JAXWS Example - Secured
>> in Karaf/Fuse .......... SUCCESS [  1.012 s] [INFO] CXF JAXWS Example
>> - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s] [INFO]
>> Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960
>> s] [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow
>> SUCCESS [  1.012 s] [INFO] Camel endpoint example - Secured in
>> Karaf/Fuse ..... SUCCESS [  0.779 s] [INFO] Camel endpoint example -
>> Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s] [INFO]
>> Keycloak Fuse Example - Features ................... SUCCESS [  0.670
>> s] [INFO] Keycloak Examples - External Config ................ SUCCESS
>> [  0.776 s] [INFO] spring-boot-adapter
>> ................................ SUCCESS [  1.358 s] [INFO]
>> spring-boot-adapter-2 .............................. SUCCESS [  1.571
>> s] [INFO] spring-boot-adapter-21 ............................. SUCCESS
>> [  1.435 s] [INFO] Servers
>> ............................................ SUCCESS [  0.152 s]
>> [INFO] Auth Server ........................................ SUCCESS [
>> 0.127 s] [INFO] Auth Server Services ...............................
>> SUCCESS [  0.129 s] [INFO] Auth Server Services - Testsuite Providers
>> ......... SUCCESS [  5.076 s] [INFO] Auth Server - JBoss
>> ................................ SUCCESS [  0.131 s] [INFO] Keycloak
>> TestSuite Utils ........................... SUCCESS [  2.794 s] [INFO]
>> Test Util .......................................... SUCCESS [  1.798
>> s] [INFO] Auth Server - Undertow ............................. SUCCESS
>> [  2.305 s] [INFO] App Server
>> ......................................... SUCCESS [  0.137 s] [INFO]
>> App Server - SPI ................................... SUCCESS [  0.541
>> s] [INFO] App Server - JBoss ................................. SUCCESS
>> [  0.132 s] [INFO] App Server - Karaf
>> ................................. SUCCESS [  0.127 s] [INFO] App
>> Server - Tomcat ................................ SUCCESS [  0.130 s]
>> [INFO] App Server - Undertow .............................. SUCCESS [
>> 1.122 s] [INFO] App Server - Jetty Parent ..........................
>> SUCCESS [  0.151 s] [INFO] Cache Server
>> ....................................... SUCCESS [  0.119 s] [INFO]
>> Cache Server - JBoss Family ........................ SUCCESS [  0.124
>> s] [INFO] Tests .............................................. SUCCESS
>> [  0.493 s] [INFO] Base TestSuite
>> ..................................... FAILURE [  01:45 h] [INFO] Other
>> Tests Modules ................................ SKIPPED [INFO] Adapter
>> Tests ...................................... SKIPPED [INFO] Adapter
>> Tests - JBoss .............................. SKIPPED [INFO] Adapter
>> Tests - Karaf .............................. SKIPPED [INFO] Adapter
>> Tests - WAS ................................ SKIPPED [INFO] Adapter
>> Tests - WLS ................................ SKIPPED [INFO] SSSD tests
>> ......................................... SKIPPED [INFO]
>> integration-arquillian-tests-springboot ............ SKIPPED [INFO]
>> ----------------------------------------------------------------------
>> --
>> [INFO] BUILD FAILURE
>> [INFO]
>> ----------------------------------------------------------------------
>> --
>> [INFO] Total time:  01:51 h
>> [INFO] Finished at: 2019-04-23T19:51:55+08:00 [INFO]
>> ----------------------------------------------------------------------
>> -- [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project integration-arquillian-tests-base: There are test failures.
>> [ERROR]
>> [ERROR] Please refer to C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports for the individual test results.
>> [ERROR] -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions, please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with the command
>> [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
>>
>> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-paren
>> t> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Fri May 10 04:28:19 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 May 2019 10:28:19 +0200
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <CY4PR22MB0248254EDC4DC99BC46D687E980C0@CY4PR22MB0248.namprd22.prod.outlook.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
	<BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>
	<6592fef9-212c-ba25-4927-e7bb0bb80a75@redhat.com>
	<CY4PR22MB0248254EDC4DC99BC46D687E980C0@CY4PR22MB0248.namprd22.prod.outlook.com>
Message-ID: <CAJgngAe_OXRM=T-L5sbNQqx7DrHtyvaRwhLfP7yEP1ODcKKZew@mail.gmail.com>

Bear in mind the default build runs a lot of testing. If you just want a
build you can skip tests with -DskipTests. To debug and resolve issues in
the testing we would love your contribution by spending a little bit of
time trying to find out what the problem is on your end.

On Fri, 10 May 2019 at 09:32, Chris Smith <chris.smith at cmfirstgroup.com>
wrote:

> Well... if the build is not broken, then it is too darn persnickety.
>
> I have a FRESH Ubuntu Server 18.04.2 VirtualBox VM
> Only things installed are:
> openssl
> dkms
> build-essential
> VBOX guest additions
> GIT
> openjdk-8-jdk
> maven
>
> Only VBOX guest was not installed with apt
>
> fresh checkout from github
>
> run  mvn -e install --log-file ~/kc-build.txt
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [
>
> The log can be found at
> https://gist.github.com/smitopher/16677dd8231869ab41527665f16e67d6
>
> If you can't complete a build on a machine as generic and uncluttered as
> this, I would consider that a broken build.
>
> Any suggestions about what I'm missing?
>
>
> -----Original Message-----
> From: Vlasta Ramik <vramik at redhat.com>
> Sent: Sunday, April 28, 2019 4:36 AM
> To: Chris Smith <chris.smith at cmfirstgroup.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] mvn install fails
>
>  From quick look at the log, the first failed test is
> ClaimInformationPointProviderTest. The test fails when tries to start
> undertow on localhost:8989 [1] and the address is already used. Pls make
> sure there is nothing running on that port at you env and try to run it
> again.
>
> V.
>
> [1]
>
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/client/authorization/ClaimInformationPointProviderTest.java#L79
>
> On 4/27/19 10:21 AM, Chris Smith wrote:
> > Here is a full build log
> > https://gist.github.com/smitopher/72b75e362fa6f8856b8ea1808809e918
> >
> >
> >
> > From: Stian Thorgersen <sthorger at redhat.com>
> > Sent: Wednesday, April 24, 2019 4:18 PM
> > To: Chris Smith <chris.smith at cmfirstgroup.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Subject: Re: [keycloak-dev] mvn install fails
> >
> > Looks like some test is failing, but you've not included the relevant
> part of the log that shows details of what test is failing.
> >
> > On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com
> <mailto:chris.smith at cmfirstgroup.com>> wrote:
> > A fresh clone from Github and mvn install fails to complete.
> > Any reason why?
> >
> > Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211
> >
> > [INFO]
> > ----------------------------------------------------------------------
> > -- [INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
> > [INFO]
> > [INFO] Keycloak BOM Parent ................................ SUCCESS [
> > 11.402 s] [INFO] Keycloak BOM for adapters ..........................
> > SUCCESS [  0.111 s] [INFO] Keycloak BOM for server extensions
> > ................. SUCCESS [  0.105 s] [INFO] Keycloak BOM utilities
> > for the quickstarts ......... SUCCESS [  0.098 s] [INFO] Keycloak
> > ........................................... SUCCESS [  1.655 s] [INFO]
> > Keycloak Common .................................... SUCCESS [ 15.064
> > s] [INFO] Keycloak Core ...................................... SUCCESS
> > [ 12.195 s] [INFO] Keycloak Dependencies Parent
> > ....................... SUCCESS [  0.130 s] [INFO] Keycloak Drools BOM
> > ................................ SUCCESS [  0.129 s] [INFO] Keycloak
> > Server SPI ................................ SUCCESS [  3.287 s] [INFO]
> > Keycloak Server Private SPI ........................ SUCCESS [  8.419
> > s] [INFO] Keycloak Kerberos Federation ....................... SUCCESS
> > [  0.910 s] [INFO] Keycloak LDAP UserStoreProvider
> > .................... SUCCESS [  7.065 s] [INFO] Keycloak SAML Core
> > Public API ...................... SUCCESS [  2.849 s] [INFO] Keycloak
> > SAML Core ................................. SUCCESS [  9.528 s] [INFO]
> > Keycloak REST Services ............................. SUCCESS [ 25.199
> > s] [INFO] Keycloak JS Integration ............................ SUCCESS
> > [  5.176 s] [INFO] Keycloak Themes
> > .................................... SUCCESS [  9.625 s] [INFO]
> > Keycloak Dependencies Server Min ................... SUCCESS [  0.139
> > s] [INFO] Keycloak Model Parent .............................. SUCCESS
> > [  0.139 s] [INFO] Keycloak Model JPA
> > ................................. SUCCESS [  7.185 s] [INFO] Keycloak
> > Model Infinispan .......................... SUCCESS [ 13.296 s] [INFO]
> > Keycloak SSSD Federation ........................... SUCCESS [  5.565
> > s] [INFO] KeyCloak Authz: Parent ............................. SUCCESS
> > [  0.222 s] [INFO] KeyCloak AuthZ: Provider Parent
> > .................... SUCCESS [  0.182 s] [INFO] KeyCloak AuthZ: Common
> > Policy Providers ............ SUCCESS [  2.537 s] [INFO] KeyCloak
> > AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s] [INFO]
> > Keycloak Dependencies Server All ................... SUCCESS [  0.195
> > s] [INFO] Keycloak Federation ................................ SUCCESS
> > [  0.220 s] [INFO] Keycloak Util Embedded LDAP
> > ........................ SUCCESS [  3.089 s] [INFO] Keycloak Util
> > Parent ............................... SUCCESS [  0.209 s] [INFO]
> > Keycloak WildFly Integration ....................... SUCCESS [  0.184
> > s] [INFO] Keycloak WildFly Add User Script ................... SUCCESS
> > [  1.151 s] [INFO] Keycloak WildFly Extensions
> > ........................ SUCCESS [  1.184 s] [INFO] Keycloak WildFly
> > Server Subsystem .................. SUCCESS [  8.763 s] [INFO]
> > Keycloak Integration ............................... SUCCESS [  0.133
> > s] [INFO] Keycloak Admin REST Client ......................... SUCCESS
> > [  1.111 s] [INFO] Keycloak Client Registration API
> > ................... SUCCESS [  0.736 s] [INFO] Keycloak Client CLI
> > ................................ SUCCESS [  0.133 s] [INFO] Keycloak
> > Client Registration CLI ................... SUCCESS [  6.737 s] [INFO]
> > Keycloak Admin CLI ................................. SUCCESS [  5.972
> > s] [INFO] Keycloak Client CLI Distribution ................... SUCCESS
> > [  3.475 s] [INFO] Keycloak Adapter SPI
> > ............................... SUCCESS [  0.939 s] [INFO] Keycloak
> > Tomcat Adapter SPI ........................ SUCCESS [  0.822 s] [INFO]
> > Keycloak Undertow Integration SPI .................. SUCCESS [  1.166
> > s] [INFO] Keycloak Servlet Integration ....................... SUCCESS
> > [  0.828 s] [INFO] Common JBoss/Wildfly Core Classes
> > .................. SUCCESS [  0.591 s] [INFO] Keycloak Jetty Adapter
> > SPI ......................... SUCCESS [  0.928 s] [INFO] Keycloak
> > Client Adapter SPI Modules ................ SUCCESS [  0.163 s] [INFO]
> > Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621
> > s] [INFO] Keycloak SAML Client Adapter Core .................. SUCCESS
> > [  5.196 s] [INFO] Keycloak Undertow SAML Adapter
> > ..................... SUCCESS [  1.009 s] [INFO] Keycloak SAML Tomcat
> > Integration ................... SUCCESS [  0.165 s] [INFO] Keycloak
> > Tomcat Core SAML Integration .............. SUCCESS [  0.839 s] [INFO]
> > Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743
> > s] [INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS
> > [  0.617 s] [INFO] Keycloak Tomcat 7 SAML Integration
> > ................. SUCCESS [  0.625 s] [INFO] Keycloak Wildfly SAML
> > Adapter ...................... SUCCESS [  0.999 s] [INFO] KeyCloak
> > Authz: Client API ......................... SUCCESS [  1.963 s] [INFO]
> > Keycloak Adapter Core .............................. SUCCESS [  6.558
> > s] [INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS
> > [  1.130 s] [INFO] Keycloak Wildfly SAML Adapter Subsystem
> > ............ SUCCESS [  7.527 s] [INFO] Keycloak SAML Wildfly
> > Integration .................. SUCCESS [  0.146 s] [INFO] Keycloak AS7
> > / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s] [INFO]
> > Keycloak AS7 SPI ................................... SUCCESS [  3.170
> > s] [INFO] Keycloak SAML EAP Integration ...................... SUCCESS
> > [  0.130 s] [INFO] Keycloak SAML AS7 Integration
> > ...................... SUCCESS [  1.062 s] [INFO] Keycloak SAML AS7
> > Subsystem ........................ SUCCESS [  5.323 s] [INFO] Keycloak
> > SAML Servlet Filter ....................... SUCCESS [  0.804 s] [INFO]
> > Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865
> > s] [INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS
> > [  0.820 s] [INFO] Keycloak Jetty 9.3.x SAML Integration
> > .............. SUCCESS [  0.894 s] [INFO] Keycloak Jetty 9.4.x SAML
> > Integration .............. SUCCESS [  1.066 s] [INFO] Keycloak SAML
> > Jetty Integration .................... SUCCESS [  0.144 s] [INFO]
> > Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132
> > s] [INFO] Keycloak Tomcat Integration ........................ SUCCESS
> > [  0.140 s] [INFO] Keycloak Tomcat Core Integration
> > ................... SUCCESS [  0.758 s] [INFO] Keycloak AS7
> > Integration ........................... SUCCESS [  0.906 s] [INFO]
> > Keycloak AS7 Subsystem ............................. SUCCESS [  4.368
> > s] [INFO] Keycloak Installed Application ..................... SUCCESS
> > [  1.609 s] [INFO] Keycloak Undertow Integration
> > ...................... SUCCESS [  2.295 s] [INFO] Keycloak Fuse 7.0
> > Integration ...................... SUCCESS [  0.161 s] [INFO] Keycloak
> > Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s] [INFO]
> > Keycloak OSGI Adapter .............................. SUCCESS [  3.531
> > s] [INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS
> > [  1.514 s] [INFO] Keycloak Jetty Core Integration
> > .................... SUCCESS [  1.175 s] [INFO] Keycloak Jetty 9.4.x
> > Integration ................... SUCCESS [  0.945 s] [INFO] Keycloak
> > Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s] [INFO]
> > Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767
> > s] [INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS
> > [  1.105 s] [INFO] Keycloak CLI SSO Framework
> > ......................... SUCCESS [  4.620 s] [INFO] Keycloak JAX-RS
> > OAuth Client ....................... SUCCESS [  1.314 s] [INFO]
> > Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142
> > s] [INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS
> > [  1.144 s] [INFO] Keycloak Jetty Integration
> > ......................... SUCCESS [  0.173 s] [INFO] Keycloak Servlet
> > Filter Adapter Integration ........ SUCCESS [  1.061 s] [INFO]
> > Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150
> > s] [INFO] spring-boot-container-bundle ....................... SUCCESS
> > [  1.761 s] [INFO] Keycloak Spring Security Integration
> > ............... SUCCESS [  8.449 s] [INFO] Keycloak Spring Boot
> > Adapter Core .................. SUCCESS [  1.759 s] [INFO] Keycloak
> > Spring Boot Integration ................... SUCCESS [  4.437 s] [INFO]
> > Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172
> > s] [INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS
> > [  0.689 s] [INFO] Keycloak Tomcat 7 Integration
> > ...................... SUCCESS [  0.761 s] [INFO] Keycloak Wildfly
> > Integration ....................... SUCCESS [  0.998 s] [INFO]
> > Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763
> > s] [INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS
> > [  8.862 s] [INFO] Keycloak Wildfly 8 Adapter Subsystem
> > ............... SUCCESS [  5.703 s] [INFO] Keycloak WildFly
> > Integration ....................... SUCCESS [  0.138 s] [INFO]
> > Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124
> > s] [INFO] Keycloak Adapters .................................. SUCCESS
> > [  0.130 s] [INFO] Keycloak Misc
> > ...................................... SUCCESS [  0.138 s] [INFO]
> > Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148
> > s] [INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS
> > [  0.371 s] [INFO] Keycloak :: Spring :: Boot
> > ......................... SUCCESS [  0.139 s] [INFO] Keycloak ::
> > Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s]
> > [INFO] keycloak-test-helper ............................... SUCCESS [
> > 0.937 s] [INFO] Keycloak TestSuite .................................
> > SUCCESS [  0.128 s] [INFO] DB Allocator Plugin
> > ................................ SUCCESS [ 14.444 s] [INFO] Keycloak
> > Arquillian Integration TestSuite .......... SUCCESS [  0.212 s] [INFO]
> > Test apps .......................................... SUCCESS [  0.144
> > s] [INFO] Test apps distribution ............................. SUCCESS
> > [  7.201 s] [INFO] Keycloak Authz: PhotoZ  Test Parent
> > ................ SUCCESS [  0.145 s] [INFO] Keycloak Authz Test:
> > Photoz RESTful API ............ SUCCESS [  1.871 s] [INFO] Keycloak
> > Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s] [INFO]
> > Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442
> > s] [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS
> > [  0.406 s] [INFO] Keycloak Authz: Servlet Authorization Test
> > ......... SUCCESS [  0.577 s] [INFO] Keycloak Authz: Simple Servlet
> > App with Policy Enforcer SUCCESS [  0.393 s] [INFO]
> > integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327
> > s] [INFO] Keycloak Test App Profile JEE ...................... SUCCESS
> > [  0.638 s] [INFO] integration-arquillian-test-apps-cors-parent
> > ....... SUCCESS [  0.144 s] [INFO] Angular Product Portal JS
> > .......................... SUCCESS [  2.995 s] [INFO] JAX-RS Database
> > Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s] [INFO] Fuse
> > Test Applications ............................. SUCCESS [  0.139 s]
> > [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [
> > 1.778 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse ..........
> > SUCCESS [  2.099 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse
> > 7.0 on Undertow SUCCESS [  0.798 s] [INFO] CXF JAXWS Example - Secured
> > in Karaf/Fuse .......... SUCCESS [  1.012 s] [INFO] CXF JAXWS Example
> > - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s] [INFO]
> > Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960
> > s] [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow
> > SUCCESS [  1.012 s] [INFO] Camel endpoint example - Secured in
> > Karaf/Fuse ..... SUCCESS [  0.779 s] [INFO] Camel endpoint example -
> > Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s] [INFO]
> > Keycloak Fuse Example - Features ................... SUCCESS [  0.670
> > s] [INFO] Keycloak Examples - External Config ................ SUCCESS
> > [  0.776 s] [INFO] spring-boot-adapter
> > ................................ SUCCESS [  1.358 s] [INFO]
> > spring-boot-adapter-2 .............................. SUCCESS [  1.571
> > s] [INFO] spring-boot-adapter-21 ............................. SUCCESS
> > [  1.435 s] [INFO] Servers
> > ............................................ SUCCESS [  0.152 s]
> > [INFO] Auth Server ........................................ SUCCESS [
> > 0.127 s] [INFO] Auth Server Services ...............................
> > SUCCESS [  0.129 s] [INFO] Auth Server Services - Testsuite Providers
> > ......... SUCCESS [  5.076 s] [INFO] Auth Server - JBoss
> > ................................ SUCCESS [  0.131 s] [INFO] Keycloak
> > TestSuite Utils ........................... SUCCESS [  2.794 s] [INFO]
> > Test Util .......................................... SUCCESS [  1.798
> > s] [INFO] Auth Server - Undertow ............................. SUCCESS
> > [  2.305 s] [INFO] App Server
> > ......................................... SUCCESS [  0.137 s] [INFO]
> > App Server - SPI ................................... SUCCESS [  0.541
> > s] [INFO] App Server - JBoss ................................. SUCCESS
> > [  0.132 s] [INFO] App Server - Karaf
> > ................................. SUCCESS [  0.127 s] [INFO] App
> > Server - Tomcat ................................ SUCCESS [  0.130 s]
> > [INFO] App Server - Undertow .............................. SUCCESS [
> > 1.122 s] [INFO] App Server - Jetty Parent ..........................
> > SUCCESS [  0.151 s] [INFO] Cache Server
> > ....................................... SUCCESS [  0.119 s] [INFO]
> > Cache Server - JBoss Family ........................ SUCCESS [  0.124
> > s] [INFO] Tests .............................................. SUCCESS
> > [  0.493 s] [INFO] Base TestSuite
> > ..................................... FAILURE [  01:45 h] [INFO] Other
> > Tests Modules ................................ SKIPPED [INFO] Adapter
> > Tests ...................................... SKIPPED [INFO] Adapter
> > Tests - JBoss .............................. SKIPPED [INFO] Adapter
> > Tests - Karaf .............................. SKIPPED [INFO] Adapter
> > Tests - WAS ................................ SKIPPED [INFO] Adapter
> > Tests - WLS ................................ SKIPPED [INFO] SSSD tests
> > ......................................... SKIPPED [INFO]
> > integration-arquillian-tests-springboot ............ SKIPPED [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] BUILD FAILURE
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] Total time:  01:51 h
> > [INFO] Finished at: 2019-04-23T19:51:55+08:00 [INFO]
> > ----------------------------------------------------------------------
> > -- [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test
> (default-test) on project integration-arquillian-tests-base: There are test
> failures.
> > [ERROR]
> > [ERROR] Please refer to
> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports
> for the individual test results.
> > [ERROR] -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> > [ERROR] [Help 1]
> > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> > [ERROR]
> > [ERROR] After correcting the problems, you can resume the build with the
> command
> > [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
> >
> > C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-paren
> > t> _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri May 10 04:31:26 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 May 2019 10:31:26 +0200
Subject: [keycloak-dev] Typescript support for Node.js adapter
In-Reply-To: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>
References: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>
Message-ID: <CAJgngAfbn4BZ2srchmB86CnfQOLHa9=t6wXbbPRZ2pTBp9ZJcw@mail.gmail.com>

Is Typescript commonly used in the Node.js community? From what
I understand it is very popular with client-side js these days.

On Thu, 9 May 2019 at 20:59, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning, we have this PR opened long time ago
> https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.
> Before review it and probably update it I would like to ask.
>
> Is Typescript something that we would like to support in the Node.js
> adapter? If your answer is yes, why?
>
> --
> - abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From chris.smith at cmfirstgroup.com  Fri May 10 05:22:41 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Fri, 10 May 2019 09:22:41 +0000
Subject: [keycloak-dev] mvn install fails
In-Reply-To: <CAJgngAe_OXRM=T-L5sbNQqx7DrHtyvaRwhLfP7yEP1ODcKKZew@mail.gmail.com>
References: <CY4PR22MB0248D34B6173C3724ACBD94A98230@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAd+8scfeMsKg6bdfwqd+RwK7Uw4yC1gDLd4NpcDtOnBOg@mail.gmail.com>
	<BN6PR22MB0244CA2B6E4107A8A581DB87983F0@BN6PR22MB0244.namprd22.prod.outlook.com>
	<6592fef9-212c-ba25-4927-e7bb0bb80a75@redhat.com>
	<CY4PR22MB0248254EDC4DC99BC46D687E980C0@CY4PR22MB0248.namprd22.prod.outlook.com>
	<CAJgngAe_OXRM=T-L5sbNQqx7DrHtyvaRwhLfP7yEP1ODcKKZew@mail.gmail.com>
Message-ID: <CY4PR22MB02480B2191C9AD95779C6B9F980C0@CY4PR22MB0248.namprd22.prod.outlook.com>

I understand the obligation for me to contribute.  My maven expertise is pretty limited so my digging in would be a learning experience.

I was hopping that a completed maven command line build would fill my local repository with all dependencies so that my Eclipse workspace would not by the mass of ?Error Markers? that it is.

I?ll review the 2 issues that Vlasta pointed to.

From: Stian Thorgersen <sthorger at redhat.com>
Sent: Friday, May 10, 2019 3:28 AM
To: Chris Smith <chris.smith at cmfirstgroup.com>
Cc: Vlasta Ramik <vramik at redhat.com>; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] mvn install fails

Bear in mind the default build runs a lot of testing. If you just want a build you can skip tests with -DskipTests. To debug and resolve issues in the testing we would love your contribution by spending a little bit of time trying to find out what the problem is on your end.

On Fri, 10 May 2019 at 09:32, Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>> wrote:
Well... if the build is not broken, then it is too darn persnickety.

I have a FRESH Ubuntu Server 18.04.2 VirtualBox VM
Only things installed are:
openssl
dkms
build-essential
VBOX guest additions
GIT
openjdk-8-jdk
maven

Only VBOX guest was not installed with apt

fresh checkout from github

run  mvn -e install --log-file ~/kc-build.txt

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[

The log can be found at https://gist.github.com/smitopher/16677dd8231869ab41527665f16e67d6

If you can't complete a build on a machine as generic and uncluttered as this, I would consider that a broken build.

Any suggestions about what I'm missing?


-----Original Message-----
From: Vlasta Ramik <vramik at redhat.com<mailto:vramik at redhat.com>>
Sent: Sunday, April 28, 2019 4:36 AM
To: Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>>
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] mvn install fails

 From quick look at the log, the first failed test is ClaimInformationPointProviderTest. The test fails when tries to start undertow on localhost:8989 [1] and the address is already used. Pls make sure there is nothing running on that port at you env and try to run it again.

V.

[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/client/authorization/ClaimInformationPointProviderTest.java#L79

On 4/27/19 10:21 AM, Chris Smith wrote:
> Here is a full build log
> https://gist.github.com/smitopher/72b75e362fa6f8856b8ea1808809e918
>
>
>
> From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
> Sent: Wednesday, April 24, 2019 4:18 PM
> To: Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>>
> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] mvn install fails
>
> Looks like some test is failing, but you've not included the relevant part of the log that shows details of what test is failing.
>
> On Tue, 23 Apr 2019 at 18:46, Chris Smith <chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com><mailto:chris.smith at cmfirstgroup.com<mailto:chris.smith at cmfirstgroup.com>>> wrote:
> A fresh clone from Github and mvn install fails to complete.
> Any reason why?
>
> Tests run: 2860, Failures: 0, Errors: 22, Skipped: 211
>
> [INFO]
> ----------------------------------------------------------------------
> -- [INFO] Reactor Summary for Keycloak 7.0.0-SNAPSHOT:
> [INFO]
> [INFO] Keycloak BOM Parent ................................ SUCCESS [
> 11.402 s] [INFO] Keycloak BOM for adapters ..........................
> SUCCESS [  0.111 s] [INFO] Keycloak BOM for server extensions
> ................. SUCCESS [  0.105 s] [INFO] Keycloak BOM utilities
> for the quickstarts ......... SUCCESS [  0.098 s] [INFO] Keycloak
> ........................................... SUCCESS [  1.655 s] [INFO]
> Keycloak Common .................................... SUCCESS [ 15.064
> s] [INFO] Keycloak Core ...................................... SUCCESS
> [ 12.195 s] [INFO] Keycloak Dependencies Parent
> ....................... SUCCESS [  0.130 s] [INFO] Keycloak Drools BOM
> ................................ SUCCESS [  0.129 s] [INFO] Keycloak
> Server SPI ................................ SUCCESS [  3.287 s] [INFO]
> Keycloak Server Private SPI ........................ SUCCESS [  8.419
> s] [INFO] Keycloak Kerberos Federation ....................... SUCCESS
> [  0.910 s] [INFO] Keycloak LDAP UserStoreProvider
> .................... SUCCESS [  7.065 s] [INFO] Keycloak SAML Core
> Public API ...................... SUCCESS [  2.849 s] [INFO] Keycloak
> SAML Core ................................. SUCCESS [  9.528 s] [INFO]
> Keycloak REST Services ............................. SUCCESS [ 25.199
> s] [INFO] Keycloak JS Integration ............................ SUCCESS
> [  5.176 s] [INFO] Keycloak Themes
> .................................... SUCCESS [  9.625 s] [INFO]
> Keycloak Dependencies Server Min ................... SUCCESS [  0.139
> s] [INFO] Keycloak Model Parent .............................. SUCCESS
> [  0.139 s] [INFO] Keycloak Model JPA
> ................................. SUCCESS [  7.185 s] [INFO] Keycloak
> Model Infinispan .......................... SUCCESS [ 13.296 s] [INFO]
> Keycloak SSSD Federation ........................... SUCCESS [  5.565
> s] [INFO] KeyCloak Authz: Parent ............................. SUCCESS
> [  0.222 s] [INFO] KeyCloak AuthZ: Provider Parent
> .................... SUCCESS [  0.182 s] [INFO] KeyCloak AuthZ: Common
> Policy Providers ............ SUCCESS [  2.537 s] [INFO] KeyCloak
> AuthZ: Drools Policy Provider ............. SUCCESS [  1.934 s] [INFO]
> Keycloak Dependencies Server All ................... SUCCESS [  0.195
> s] [INFO] Keycloak Federation ................................ SUCCESS
> [  0.220 s] [INFO] Keycloak Util Embedded LDAP
> ........................ SUCCESS [  3.089 s] [INFO] Keycloak Util
> Parent ............................... SUCCESS [  0.209 s] [INFO]
> Keycloak WildFly Integration ....................... SUCCESS [  0.184
> s] [INFO] Keycloak WildFly Add User Script ................... SUCCESS
> [  1.151 s] [INFO] Keycloak WildFly Extensions
> ........................ SUCCESS [  1.184 s] [INFO] Keycloak WildFly
> Server Subsystem .................. SUCCESS [  8.763 s] [INFO]
> Keycloak Integration ............................... SUCCESS [  0.133
> s] [INFO] Keycloak Admin REST Client ......................... SUCCESS
> [  1.111 s] [INFO] Keycloak Client Registration API
> ................... SUCCESS [  0.736 s] [INFO] Keycloak Client CLI
> ................................ SUCCESS [  0.133 s] [INFO] Keycloak
> Client Registration CLI ................... SUCCESS [  6.737 s] [INFO]
> Keycloak Admin CLI ................................. SUCCESS [  5.972
> s] [INFO] Keycloak Client CLI Distribution ................... SUCCESS
> [  3.475 s] [INFO] Keycloak Adapter SPI
> ............................... SUCCESS [  0.939 s] [INFO] Keycloak
> Tomcat Adapter SPI ........................ SUCCESS [  0.822 s] [INFO]
> Keycloak Undertow Integration SPI .................. SUCCESS [  1.166
> s] [INFO] Keycloak Servlet Integration ....................... SUCCESS
> [  0.828 s] [INFO] Common JBoss/Wildfly Core Classes
> .................. SUCCESS [  0.591 s] [INFO] Keycloak Jetty Adapter
> SPI ......................... SUCCESS [  0.928 s] [INFO] Keycloak
> Client Adapter SPI Modules ................ SUCCESS [  0.163 s] [INFO]
> Keycloak SAML Client Adapter Public API ............ SUCCESS [  0.621
> s] [INFO] Keycloak SAML Client Adapter Core .................. SUCCESS
> [  5.196 s] [INFO] Keycloak Undertow SAML Adapter
> ..................... SUCCESS [  1.009 s] [INFO] Keycloak SAML Tomcat
> Integration ................... SUCCESS [  0.165 s] [INFO] Keycloak
> Tomcat Core SAML Integration .............. SUCCESS [  0.839 s] [INFO]
> Keycloak Tomcat 8 SAML Integration ................. SUCCESS [  0.743
> s] [INFO] Keycloak Tomcat 6 Saml Integration ................. SUCCESS
> [  0.617 s] [INFO] Keycloak Tomcat 7 SAML Integration
> ................. SUCCESS [  0.625 s] [INFO] Keycloak Wildfly SAML
> Adapter ...................... SUCCESS [  0.999 s] [INFO] KeyCloak
> Authz: Client API ......................... SUCCESS [  1.963 s] [INFO]
> Keycloak Adapter Core .............................. SUCCESS [  6.558
> s] [INFO] Keycloak WildFly Elytron SAML Adapter .............. SUCCESS
> [  1.130 s] [INFO] Keycloak Wildfly SAML Adapter Subsystem
> ............ SUCCESS [  7.527 s] [INFO] Keycloak SAML Wildfly
> Integration .................. SUCCESS [  0.146 s] [INFO] Keycloak AS7
> / JBoss EAP 6 Integration ............. SUCCESS [  0.183 s] [INFO]
> Keycloak AS7 SPI ................................... SUCCESS [  3.170
> s] [INFO] Keycloak SAML EAP Integration ...................... SUCCESS
> [  0.130 s] [INFO] Keycloak SAML AS7 Integration
> ...................... SUCCESS [  1.062 s] [INFO] Keycloak SAML AS7
> Subsystem ........................ SUCCESS [  5.323 s] [INFO] Keycloak
> SAML Servlet Filter ....................... SUCCESS [  0.804 s] [INFO]
> Keycloak Jetty Core SAML Integration ............... SUCCESS [  0.865
> s] [INFO] Keycloak Jetty 9.2.x SAML Integration .............. SUCCESS
> [  0.820 s] [INFO] Keycloak Jetty 9.3.x SAML Integration
> .............. SUCCESS [  0.894 s] [INFO] Keycloak Jetty 9.4.x SAML
> Integration .............. SUCCESS [  1.066 s] [INFO] Keycloak SAML
> Jetty Integration .................... SUCCESS [  0.144 s] [INFO]
> Keycloak SAML Client Adapter Modules ............... SUCCESS [  0.132
> s] [INFO] Keycloak Tomcat Integration ........................ SUCCESS
> [  0.140 s] [INFO] Keycloak Tomcat Core Integration
> ................... SUCCESS [  0.758 s] [INFO] Keycloak AS7
> Integration ........................... SUCCESS [  0.906 s] [INFO]
> Keycloak AS7 Subsystem ............................. SUCCESS [  4.368
> s] [INFO] Keycloak Installed Application ..................... SUCCESS
> [  1.609 s] [INFO] Keycloak Undertow Integration
> ...................... SUCCESS [  2.295 s] [INFO] Keycloak Fuse 7.0
> Integration ...................... SUCCESS [  0.161 s] [INFO] Keycloak
> Fuse 7.0 Adapter - Camel + Undertow ....... SUCCESS [  1.773 s] [INFO]
> Keycloak OSGI Adapter .............................. SUCCESS [  3.531
> s] [INFO] Keycloak Fuse 7.0 Adapter - Undertow ............... SUCCESS
> [  1.514 s] [INFO] Keycloak Jetty Core Integration
> .................... SUCCESS [  1.175 s] [INFO] Keycloak Jetty 9.4.x
> Integration ................... SUCCESS [  0.945 s] [INFO] Keycloak
> Fuse 7.0 Adapter - Jetty 9.4 .............. SUCCESS [  1.345 s] [INFO]
> Keycloak Tomcat 8 Integration ...................... SUCCESS [  0.767
> s] [INFO] Keycloak Fuse 7.0 Adapter - Tomcat 8 ............... SUCCESS
> [  1.105 s] [INFO] Keycloak CLI SSO Framework
> ......................... SUCCESS [  4.620 s] [INFO] Keycloak JAX-RS
> OAuth Client ....................... SUCCESS [  1.314 s] [INFO]
> Keycloak Jetty 9.2.x Integration ................... SUCCESS [  1.142
> s] [INFO] Keycloak Jetty 9.3.x Integration ................... SUCCESS
> [  1.144 s] [INFO] Keycloak Jetty Integration
> ......................... SUCCESS [  0.173 s] [INFO] Keycloak Servlet
> Filter Adapter Integration ........ SUCCESS [  1.061 s] [INFO]
> Keycloak Servlet OAuth Client ...................... SUCCESS [  4.150
> s] [INFO] spring-boot-container-bundle ....................... SUCCESS
> [  1.761 s] [INFO] Keycloak Spring Security Integration
> ............... SUCCESS [  8.449 s] [INFO] Keycloak Spring Boot
> Adapter Core .................. SUCCESS [  1.759 s] [INFO] Keycloak
> Spring Boot Integration ................... SUCCESS [  4.437 s] [INFO]
> Keycloak Spring Boot 2 Integration ................. SUCCESS [  4.172
> s] [INFO] Keycloak Tomcat 6 Integration ...................... SUCCESS
> [  0.689 s] [INFO] Keycloak Tomcat 7 Integration
> ...................... SUCCESS [  0.761 s] [INFO] Keycloak Wildfly
> Integration ....................... SUCCESS [  0.998 s] [INFO]
> Keycloak Wildfly Elytron OIDC Adapter .............. SUCCESS [  1.763
> s] [INFO] Keycloak Wildfly Adapter Subsystem ................. SUCCESS
> [  8.862 s] [INFO] Keycloak Wildfly 8 Adapter Subsystem
> ............... SUCCESS [  5.703 s] [INFO] Keycloak WildFly
> Integration ....................... SUCCESS [  0.138 s] [INFO]
> Keycloak OIDC Client Adapter Modules ............... SUCCESS [  0.124
> s] [INFO] Keycloak Adapters .................................. SUCCESS
> [  0.130 s] [INFO] Keycloak Misc
> ...................................... SUCCESS [  0.138 s] [INFO]
> Keycloak :: Spring :: Boot ......................... SUCCESS [  0.148
> s] [INFO] Keycloak :: Spring :: Boot :: Default ::  Starter .. SUCCESS
> [  0.371 s] [INFO] Keycloak :: Spring :: Boot
> ......................... SUCCESS [  0.139 s] [INFO] Keycloak ::
> Legacy :: Spring :: Boot :: Default ::  Starter SUCCESS [  0.388 s]
> [INFO] keycloak-test-helper ............................... SUCCESS [
> 0.937 s] [INFO] Keycloak TestSuite .................................
> SUCCESS [  0.128 s] [INFO] DB Allocator Plugin
> ................................ SUCCESS [ 14.444 s] [INFO] Keycloak
> Arquillian Integration TestSuite .......... SUCCESS [  0.212 s] [INFO]
> Test apps .......................................... SUCCESS [  0.144
> s] [INFO] Test apps distribution ............................. SUCCESS
> [  7.201 s] [INFO] Keycloak Authz: PhotoZ  Test Parent
> ................ SUCCESS [  0.145 s] [INFO] Keycloak Authz Test:
> Photoz RESTful API ............ SUCCESS [  1.871 s] [INFO] Keycloak
> Authz Tests: Photoz HTML5 Client .......... SUCCESS [  1.330 s] [INFO]
> Keycloak Authz Tests: Photoz Authz Rule-based Policy SUCCESS [  0.442
> s] [INFO] Keycloak Authz Tests: Hello World Example .......... SUCCESS
> [  0.406 s] [INFO] Keycloak Authz: Servlet Authorization Test
> ......... SUCCESS [  0.577 s] [INFO] Keycloak Authz: Simple Servlet
> App with Policy Enforcer SUCCESS [  0.393 s] [INFO]
> integration-arquillian-test-apps-servlets .......... SUCCESS [  1.327
> s] [INFO] Keycloak Test App Profile JEE ...................... SUCCESS
> [  0.638 s] [INFO] integration-arquillian-test-apps-cors-parent
> ....... SUCCESS [  0.144 s] [INFO] Angular Product Portal JS
> .......................... SUCCESS [  2.995 s] [INFO] JAX-RS Database
> Service Using OAuth Bearer Tokens .. SUCCESS [  0.728 s] [INFO] Fuse
> Test Applications ............................. SUCCESS [  0.139 s]
> [INFO] Customer Portal - Secured in Karaf/Fuse ............ SUCCESS [
> 1.778 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse ..........
> SUCCESS [  2.099 s] [INFO] CXF JAXRS Example - Secured in Karaf/Fuse
> 7.0 on Undertow SUCCESS [  0.798 s] [INFO] CXF JAXWS Example - Secured
> in Karaf/Fuse .......... SUCCESS [  1.012 s] [INFO] CXF JAXWS Example
> - Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.830 s] [INFO]
> Product Portal - Secured in Karaf/Fuse ............. SUCCESS [  0.960
> s] [INFO] Product Portal - Secured in Karaf/Fuse 7.0 on Undertow
> SUCCESS [  1.012 s] [INFO] Camel endpoint example - Secured in
> Karaf/Fuse ..... SUCCESS [  0.779 s] [INFO] Camel endpoint example -
> Secured in Karaf/Fuse 7.0 on Undertow SUCCESS [  0.879 s] [INFO]
> Keycloak Fuse Example - Features ................... SUCCESS [  0.670
> s] [INFO] Keycloak Examples - External Config ................ SUCCESS
> [  0.776 s] [INFO] spring-boot-adapter
> ................................ SUCCESS [  1.358 s] [INFO]
> spring-boot-adapter-2 .............................. SUCCESS [  1.571
> s] [INFO] spring-boot-adapter-21 ............................. SUCCESS
> [  1.435 s] [INFO] Servers
> ............................................ SUCCESS [  0.152 s]
> [INFO] Auth Server ........................................ SUCCESS [
> 0.127 s] [INFO] Auth Server Services ...............................
> SUCCESS [  0.129 s] [INFO] Auth Server Services - Testsuite Providers
> ......... SUCCESS [  5.076 s] [INFO] Auth Server - JBoss
> ................................ SUCCESS [  0.131 s] [INFO] Keycloak
> TestSuite Utils ........................... SUCCESS [  2.794 s] [INFO]
> Test Util .......................................... SUCCESS [  1.798
> s] [INFO] Auth Server - Undertow ............................. SUCCESS
> [  2.305 s] [INFO] App Server
> ......................................... SUCCESS [  0.137 s] [INFO]
> App Server - SPI ................................... SUCCESS [  0.541
> s] [INFO] App Server - JBoss ................................. SUCCESS
> [  0.132 s] [INFO] App Server - Karaf
> ................................. SUCCESS [  0.127 s] [INFO] App
> Server - Tomcat ................................ SUCCESS [  0.130 s]
> [INFO] App Server - Undertow .............................. SUCCESS [
> 1.122 s] [INFO] App Server - Jetty Parent ..........................
> SUCCESS [  0.151 s] [INFO] Cache Server
> ....................................... SUCCESS [  0.119 s] [INFO]
> Cache Server - JBoss Family ........................ SUCCESS [  0.124
> s] [INFO] Tests .............................................. SUCCESS
> [  0.493 s] [INFO] Base TestSuite
> ..................................... FAILURE [  01:45 h] [INFO] Other
> Tests Modules ................................ SKIPPED [INFO] Adapter
> Tests ...................................... SKIPPED [INFO] Adapter
> Tests - JBoss .............................. SKIPPED [INFO] Adapter
> Tests - Karaf .............................. SKIPPED [INFO] Adapter
> Tests - WAS ................................ SKIPPED [INFO] Adapter
> Tests - WLS ................................ SKIPPED [INFO] SSSD tests
> ......................................... SKIPPED [INFO]
> integration-arquillian-tests-springboot ............ SKIPPED [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] BUILD FAILURE
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Total time:  01:51 h
> [INFO] Finished at: 2019-04-23T19:51:55+08:00 [INFO]
> ----------------------------------------------------------------------
> -- [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project integration-arquillian-tests-base: There are test failures.
> [ERROR]
> [ERROR] Please refer to C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-parent\testsuite\integration-arquillian\tests\base\target\surefire-reports for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :integration-arquillian-tests-base
>
> C:\Users\christopher.smith\Documents\keycloak\workspace\keycloak-paren
> t> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org><mailto:keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bruno at abstractj.org  Fri May 10 08:15:25 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 10 May 2019 09:15:25 -0300
Subject: [keycloak-dev] Typescript support for Node.js adapter
In-Reply-To: <CAJgngAfbn4BZ2srchmB86CnfQOLHa9=t6wXbbPRZ2pTBp9ZJcw@mail.gmail.com>
References: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>
	<CAJgngAfbn4BZ2srchmB86CnfQOLHa9=t6wXbbPRZ2pTBp9ZJcw@mail.gmail.com>
Message-ID: <20190510121525.GA10675@abstractj.org>

If you ask me, I'm not crazy about the idea of providing Typescript
definitions inside the Node.js adapter. And there's a single request
from the community about it.

At the same time, it's hard to ignore some numbers. The weekly NPM
downloads for Typescript is almost 5 million[1] and for ts-node[2] is
almost 2 million.

The goal of that PR is to provide only the Typescript definitions for
the Node.js adapter, so that projects using the adapter can benefit from
it.  If we agree to move forward with this, I believe some automated way
to generate it, has to be provided.

Thoughts?

[1] - https://www.npmjs.com/package/typescript
[2] - https://www.npmjs.com/package/ts-node

On 2019-05-10, Stian Thorgersen wrote:
> Is Typescript commonly used in the Node.js community? From what
> I understand it is very popular with client-side js these days.
> 
> On Thu, 9 May 2019 at 20:59, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> > Good morning, we have this PR opened long time ago
> > https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.
> > Before review it and probably update it I would like to ask.
> >
> > Is Typescript something that we would like to support in the Node.js
> > adapter? If your answer is yes, why?
> >
> > --
> > - abstractj
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >

-- 

abstractj

From orivat at janua.fr  Fri May 10 11:08:41 2019
From: orivat at janua.fr (Olivier Rivat)
Date: Fri, 10 May 2019 17:08:41 +0200
Subject: [keycloak-dev] Cannot get UMA photoz example working (keycloak
	quickstart 6.0.1)
Message-ID: <cc06972f-f4d5-dad5-f30d-fb2c14dbabd1@janua.fr>

Hi,

I am not able to get the app-auth-photoz uma example working.

I have followed the example instructions at

https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz

When I ckik on the
http://localhost:8080/photoz-html5-client

I obtain the error message

We're sorry...
Page not 
foundhttps://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz

Landing URL in teh browser is:
http://localhost:8180/auth/realms/photoz/protocol/openid-connect/auth?client_id=photoz-html5-client&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fphotoz-html5-client%2F&state=38044f03-0abc-4473-8a76-06531078d225&response_mode=fragment&response_type=code&scope=openid&nonce=6f1d9f20-64da-4ac1-9c71-8d399d8e0d5f

I have enabled debug logs, but haven't found any further clue.

I am wondering where this problem can originate ?
Misconfiguration of mine (I've tried this example with diffrenet 
distribs and always falling in the same hurdle)

Or is it a bug in with this example ?


Regards,


Olivier Rivat



-- 


<http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/images/LogoSignature.gif>

	<http://www.janua.fr/images/6g_top.gif>
	
Olivier Rivat
CTO
orivat at janua.fr <mailto:dchikhaoui at janua.fr>
Gsm: +33(0)682 801 609
T?l: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
	<http://www.janua.fr/images/6g_top.gif>



From ssilvert at redhat.com  Fri May 10 12:49:46 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 May 2019 12:49:46 -0400
Subject: [keycloak-dev] Typescript support for Node.js adapter
In-Reply-To: <20190510121525.GA10675@abstractj.org>
References: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>
	<CAJgngAfbn4BZ2srchmB86CnfQOLHa9=t6wXbbPRZ2pTBp9ZJcw@mail.gmail.com>
	<20190510121525.GA10675@abstractj.org>
Message-ID: <a3032ce6-b579-437b-7109-b03b79250658@redhat.com>

On 5/10/2019 8:15 AM, Bruno Oliveira wrote:
> If you ask me, I'm not crazy about the idea of providing Typescript
> definitions inside the Node.js adapter. And there's a single request
> from the community about it.
>
> At the same time, it's hard to ignore some numbers. The weekly NPM
> downloads for Typescript is almost 5 million[1] and for ts-node[2] is
> almost 2 million.
>
> The goal of that PR is to provide only the Typescript definitions for
> the Node.js adapter, so that projects using the adapter can benefit from
> it.  If we agree to move forward with this, I believe some automated way
> to generate it, has to be provided.
>
> Thoughts?
Yes, you should provide it.? These days, every serious javascript 
library is expected to have a definition file.

I don't think there would be any way to automate creation of the file 
unless you write your code in TypeScript.
>
> [1] - https://www.npmjs.com/package/typescript
> [2] - https://www.npmjs.com/package/ts-node
>
> On 2019-05-10, Stian Thorgersen wrote:
>> Is Typescript commonly used in the Node.js community? From what
>> I understand it is very popular with client-side js these days.
>>
>> On Thu, 9 May 2019 at 20:59, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>>> Good morning, we have this PR opened long time ago
>>> https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.
>>> Before review it and probably update it I would like to ask.
>>>
>>> Is Typescript something that we would like to support in the Node.js
>>> adapter? If your answer is yes, why?
>>>
>>> --
>>> - abstractj
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>


From orivat at janua.fr  Sat May 11 13:06:27 2019
From: orivat at janua.fr (Olivier Rivat)
Date: Sat, 11 May 2019 19:06:27 +0200
Subject: [keycloak-dev] Cannot get UMA photoz example working (keycloak
	quickstart 6.0.1)
In-Reply-To: <cc06972f-f4d5-dad5-f30d-fb2c14dbabd1@janua.fr>
References: <cc06972f-f4d5-dad5-f30d-fb2c14dbabd1@janua.fr>
Message-ID: <0dfe4a55-5308-ae3d-d3cc-302a8646a289@janua.fr>

Hi,

I have found the discrepancy

I have used the import command, whereas one should use the "add 
realm"/select file and doc should you mention to upload file here.
I think keycloak quikstart guide doc example clarity could be improved? 
with above comment to avoid any further confusion


Regards,

Olivier Rivat



Le 10/05/2019 ? 17:08, Olivier Rivat a ?crit?:
>
> Hi,
>
> I am not able to get the app-auth-photoz uma example working.
>
> I have followed the example instructions at
>
> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz
>
> When I ckik on the
> http://localhost:8080/photoz-html5-client
>
> I obtain the error message
>
> We're sorry...
> Page not 
> foundhttps://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz
>
> Landing URL in teh browser is:
> http://localhost:8180/auth/realms/photoz/protocol/openid-connect/auth?client_id=photoz-html5-client&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fphotoz-html5-client%2F&state=38044f03-0abc-4473-8a76-06531078d225&response_mode=fragment&response_type=code&scope=openid&nonce=6f1d9f20-64da-4ac1-9c71-8d399d8e0d5f
>
> I have enabled debug logs, but haven't found any further clue.
>
> I am wondering where this problem can originate ?
> Misconfiguration of mine (I've tried this example with diffrenet 
> distribs and always falling in the same hurdle)
>
> Or is it a bug in with this example ?
>
>
> Regards,
>
>
> Olivier Rivat
>
>
>
> -- 
>
>
> <http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/images/LogoSignature.gif>
>
> 	<http://www.janua.fr/images/6g_top.gif>
> 	
> Olivier Rivat
> CTO
> orivat at janua.fr <mailto:dchikhaoui at janua.fr>
> Gsm: +33(0)682 801 609
> T?l: +33(0)489 829 238
> Fax: +33(0)955 260 370
> http://www.janua.fr <http://www.janua.fr/>
> 	<http://www.janua.fr/images/6g_top.gif>
>
>
-- 


<http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/images/LogoSignature.gif>

	<http://www.janua.fr/images/6g_top.gif>
	
Olivier Rivat
CTO
orivat at janua.fr <mailto:dchikhaoui at janua.fr>
Gsm: +33(0)682 801 609
T?l: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
	<http://www.janua.fr/images/6g_top.gif>



From sblanc at redhat.com  Sun May 12 01:56:36 2019
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 12 May 2019 07:56:36 +0200
Subject: [keycloak-dev] Cannot get UMA photoz example working (keycloak
 quickstart 6.0.1)
In-Reply-To: <0dfe4a55-5308-ae3d-d3cc-302a8646a289@janua.fr>
References: <cc06972f-f4d5-dad5-f30d-fb2c14dbabd1@janua.fr>
	<0dfe4a55-5308-ae3d-d3cc-302a8646a289@janua.fr>
Message-ID: <CAMZCGg83kW0KcUJdxXdh4mNm3aNR-P06xthXJqgNmVZsRn8B1Q@mail.gmail.com>

Could you tell us what the issue was with the import when using the command
line ? Because it should also work.


On Sat, May 11, 2019 at 7:19 PM Olivier Rivat <orivat at janua.fr> wrote:

> Hi,
>
> I have found the discrepancy
>
> I have used the import command, whereas one should use the "add
> realm"/select file and doc should you mention to upload file here.
> I think keycloak quikstart guide doc example clarity could be improved
> with above comment to avoid any further confusion
>
>
> Regards,
>
> Olivier Rivat
>
>
>
> Le 10/05/2019 ? 17:08, Olivier Rivat a ?crit :
> >
> > Hi,
> >
> > I am not able to get the app-auth-photoz uma example working.
> >
> > I have followed the example instructions at
> >
> >
> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz
> >
> > When I ckik on the
> > http://localhost:8080/photoz-html5-client
> >
> > I obtain the error message
> >
> > We're sorry...
> > Page not
> > foundhttps://
> github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz
> >
> > Landing URL in teh browser is:
> >
> http://localhost:8180/auth/realms/photoz/protocol/openid-connect/auth?client_id=photoz-html5-client&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fphotoz-html5-client%2F&state=38044f03-0abc-4473-8a76-06531078d225&response_mode=fragment&response_type=code&scope=openid&nonce=6f1d9f20-64da-4ac1-9c71-8d399d8e0d5f
> >
> > I have enabled debug logs, but haven't found any further clue.
> >
> > I am wondering where this problem can originate ?
> > Misconfiguration of mine (I've tried this example with diffrenet
> > distribs and always falling in the same hurdle)
> >
> > Or is it a bug in with this example ?
> >
> >
> > Regards,
> >
> >
> > Olivier Rivat
> >
> >
> >
> > --
> >
> >
> > <http://www.janua.fr/images/logo-big-sans.png><
> http://www.janua.fr/images/LogoSignature.gif>
> >
> >       <http://www.janua.fr/images/6g_top.gif>
> >
> > Olivier Rivat
> > CTO
> > orivat at janua.fr <mailto:dchikhaoui at janua.fr>
> > Gsm: +33(0)682 801 609
> > T?l: +33(0)489 829 238
> > Fax: +33(0)955 260 370
> > http://www.janua.fr <http://www.janua.fr/>
> >       <http://www.janua.fr/images/6g_top.gif>
> >
> >
> --
>
>
> <http://www.janua.fr/images/logo-big-sans.png><
> http://www.janua.fr/images/LogoSignature.gif>
>
>         <http://www.janua.fr/images/6g_top.gif>
>
> Olivier Rivat
> CTO
> orivat at janua.fr <mailto:dchikhaoui at janua.fr>
> Gsm: +33(0)682 801 609
> T?l: +33(0)489 829 238
> Fax: +33(0)955 260 370
> http://www.janua.fr <http://www.janua.fr/>
>         <http://www.janua.fr/images/6g_top.gif>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From Lars.Wilhelmsen at thales.no  Mon May 13 03:24:23 2019
From: Lars.Wilhelmsen at thales.no (Lars Wilhelmsen)
Date: Mon, 13 May 2019 07:24:23 +0000
Subject: [keycloak-dev] Moving container files from
 https://github.com/jboss-dockerfiles/keycloak to
 https://github.com/keycloak-containers
In-Reply-To: <CAJgngAfqiXzyD91CxU9feVZczmxhufDoiyufn8+_=b3f+HmQLA@mail.gmail.com>
References: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>
	<CAM5SUC59odSzjnpU_aV2H9Rx0UFGCXzaGckJPo_Q5fvxVL7g7A@mail.gmail.com>
	<CAA9R9O5Q5RSY1OYUr_tQcpTNL4dyYY2qVcsSZXJ8mku1zu7XTg@mail.gmail.com>
	<CAJgngAfqiXzyD91CxU9feVZczmxhufDoiyufn8+_=b3f+HmQLA@mail.gmail.com>
Message-ID: <baadeac9e66745a0a5f31f7b980718fb@Thales.no>

ETA?

 --larsw

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: onsdag 8. mai 2019 13:57
To: Sebastian Laskawiec <slaskawi at redhat.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Moving container files from https://github.com/jboss-dockerfiles/keycloak to https://github.com/keycloak-containers

Yep, missed one keycloak in there ;)

On Wed, 8 May 2019 at 13:55, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey Stian,
>
> I guess you mean ttps://github.com/keycloak/keycloak-containers
> <https://github.com/keycloak-containers> (keycloak-containers repo 
> under keycloak organization)? If so, +1 from me.
>
> Thanks,
> Seb
>
> On Wed, May 8, 2019 at 1:19 PM Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> +1
>>
>> On Wed, May 8, 2019 at 8:06 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> >
>> > I'm planning on moving 
>> > https://github.com/jboss-dockerfiles/keycloak to https://github.com/keycloak-containers.
>> > _______________________________________________
>> > 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 contributing.to.keycloak at gmail.com  Mon May 13 04:39:10 2019
From: contributing.to.keycloak at gmail.com (Roland Werner)
Date: Mon, 13 May 2019 10:39:10 +0200
Subject: [keycloak-dev] Proposal: REST Endpoint for creating TOTP
Message-ID: <CADK9-H1REFEtf82h1BubLah7gi2xvVFrSS6OTk0==k=dR6Mv5w@mail.gmail.com>

Hi,

I noticed that the REST API (
https://www.keycloak.org/docs-api/6.0/rest-api/index.html) does contain an
endpoint "Remove TOTP from the user", but none that allows to create a TOTP
for a user in the first place.

I'm proposing to add this "create-totp" endpoint and would also contribute
it. The call would look like this:

curl -X PUT -H 'Content-Type: application/json' -H 'Authorization: Bearer
<token>' -i http://
<keycloak-url>:<port>/auth/admin/realms/myrealm/users/<user-id>/create-totp

and the reply as follow:
{
  "totpSecret": "aA3mIuIzvxTmC5gqUqpl",
  "qrCode": "iVBORw0KGgoAAA...AAABJRU5ErkJggg=="
}

I would check the existence of TOTP on the requested user and would reply
with 400-Bad-Request and the message
{
  "errorMessage": "User already has totp. Remove first."
}
in that case (just to make sure that this doesn't happen on accident).
One question in that respect: The JavaDocs of
org.keycloak.representations.idm.UserRepresentation says that isTotp is
deprecated, but doesn't say what to use instead. Can someone point me to
the right direction here?

I am aware that the current practice in Keycloak when adding a TOTP to a
user is to instantly request a generated OTP and only if that is correct
add the credential-type to the user. Obviously this would not apply for the
REST endpoint. However, as the endpoint is only reachable for an admin I
don't think this would result in a significant security loss, especially as
the "remove-totp" endpoint can also be used without the need to enter an
OTP.

I suggest to align the code with the behavior of the remove-totp endpoint,
such that
- it uses PUT
- it is called on given user
- it requires the same admin rights

This reason for my approach is that we want to introduce a process in our
organisation where every user in the given realm is forced to use an OTP to
login and there is no self-registration but instead the users are handed
over the QR-Code outside of Keycloak (on paper or digitally). In the
meantime we use a custom plugin, but I would love to see this also make its
way into the standard Keycloak.

What do you think?

Thanks and Regards,
Roland

From sthorger at redhat.com  Mon May 13 04:57:50 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 May 2019 10:57:50 +0200
Subject: [keycloak-dev] Proposal: REST Endpoint for creating TOTP
In-Reply-To: <CADK9-H1REFEtf82h1BubLah7gi2xvVFrSS6OTk0==k=dR6Mv5w@mail.gmail.com>
References: <CADK9-H1REFEtf82h1BubLah7gi2xvVFrSS6OTk0==k=dR6Mv5w@mail.gmail.com>
Message-ID: <CAJgngAdRCZvrH+Wa13rGi93=0J1ZuN+dWW0NmELW36gDn1U2gw@mail.gmail.com>

Having an admin create OTP codes in this way and printing it out means
there are more people with access to confidential secrets that needed. This
is also a harder way for users to configure/enable OTP. Further, it is not
very future proof. Sofware OTP tokens are already pretty much legacy so
your company will at some point want to move to something more secure like
WebAuthn Security Keys, in which case your approach of printing QR codes on
paper won't work and you will need to change your process.

A better approach which is what Keycloak already supports is requiring
users to enable OTP on first login. That way the secret is only exposed to
Keycloak and the user, not to other systems and people. Further, this can
easily be changed in the future to require users to register a WebAuthn
security key for instance.

With regards to the proposed endpoint we do not want specific OTP endpoints
like this as we are working towards making Keycloak less hard-coded around
the concept of software OTP and allow flexiblity to support any credential
types.

On Mon, 13 May 2019 at 10:42, Roland Werner <
contributing.to.keycloak at gmail.com> wrote:

> Hi,
>
> I noticed that the REST API (
> https://www.keycloak.org/docs-api/6.0/rest-api/index.html) does contain an
> endpoint "Remove TOTP from the user", but none that allows to create a TOTP
> for a user in the first place.
>
> I'm proposing to add this "create-totp" endpoint and would also contribute
> it. The call would look like this:
>
> curl -X PUT -H 'Content-Type: application/json' -H 'Authorization: Bearer
> <token>' -i http://
> <keycloak-url>:<port>/auth/admin/realms/myrealm/users/<user-id>/create-totp
>
> and the reply as follow:
> {
>   "totpSecret": "aA3mIuIzvxTmC5gqUqpl",
>   "qrCode": "iVBORw0KGgoAAA...AAABJRU5ErkJggg=="
> }
>
> I would check the existence of TOTP on the requested user and would reply
> with 400-Bad-Request and the message
> {
>   "errorMessage": "User already has totp. Remove first."
> }
> in that case (just to make sure that this doesn't happen on accident).
> One question in that respect: The JavaDocs of
> org.keycloak.representations.idm.UserRepresentation says that isTotp is
> deprecated, but doesn't say what to use instead. Can someone point me to
> the right direction here?
>
> I am aware that the current practice in Keycloak when adding a TOTP to a
> user is to instantly request a generated OTP and only if that is correct
> add the credential-type to the user. Obviously this would not apply for the
> REST endpoint. However, as the endpoint is only reachable for an admin I
> don't think this would result in a significant security loss, especially as
> the "remove-totp" endpoint can also be used without the need to enter an
> OTP.
>
> I suggest to align the code with the behavior of the remove-totp endpoint,
> such that
> - it uses PUT
> - it is called on given user
> - it requires the same admin rights
>
> This reason for my approach is that we want to introduce a process in our
> organisation where every user in the given realm is forced to use an OTP to
> login and there is no self-registration but instead the users are handed
> over the QR-Code outside of Keycloak (on paper or digitally). In the
> meantime we use a custom plugin, but I would love to see this also make its
> way into the standard Keycloak.
>
> What do you think?
>
> Thanks and Regards,
> Roland
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From maksym.gendin at gmail.com  Mon May 13 07:36:30 2019
From: maksym.gendin at gmail.com (Maksym Gendin)
Date: Mon, 13 May 2019 13:36:30 +0200
Subject: [keycloak-dev] Not properly closed connections in
	org.keycloak.adapters.ServerRequest
Message-ID: <CAKm1Xe+3EzfY-_gbLsfHJhbN474O9ift3FLtfFCCFv_yhwbgXA@mail.gmail.com>

Dear Keycloak developers,

I have noticed a potential problem with closing the connections
in org.keycloak.adapters.ServerRequest#invokeClientManagementRequest method.

I'm facing problems with number of opened files on a linux machine and
trying to identify the source...querying the open connections with netstat
I see a couple of connections in CLOSE_WAIT status from my microservice
instances towards Keycloak...

Can someone confirm me that the ServerRequest class closes the connections
in a proper way?

Best regards
Maksym

From orivat at janua.fr  Mon May 13 08:16:06 2019
From: orivat at janua.fr (Olivier Rivat)
Date: Mon, 13 May 2019 14:16:06 +0200
Subject: [keycloak-dev] Cannot get UMA photoz example working (keycloak
 quickstart 6.0.1)
In-Reply-To: <CAMZCGg83kW0KcUJdxXdh4mNm3aNR-P06xthXJqgNmVZsRn8B1Q@mail.gmail.com>
References: <cc06972f-f4d5-dad5-f30d-fb2c14dbabd1@janua.fr>
	<0dfe4a55-5308-ae3d-d3cc-302a8646a289@janua.fr>
	<CAMZCGg83kW0KcUJdxXdh4mNm3aNR-P06xthXJqgNmVZsRn8B1Q@mail.gmail.com>
Message-ID: <646ae16a-96a3-1f24-2b31-62642dd7134e@janua.fr>

discrepancy is :

1) I was using the import command of the master realm to upload 
photoz-realm.json
(it was my mistake)

2) you should do as follows:
a) select "Add realm"
b) select "Select File" and upload photoz-realm.json

---> quickstart realm and everything is created succesfully


It is following text which has confused me quite a lot, and which should 
be clearer documented (indicating to use the button add-realm for exampkle)



https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz


    /Create the Example Realm and a Resource Server/

//

/Considering that your Keycloak Server is up and running, log in to the 
Keycloak Administration Console./

//

/Now, create a new realm based on the following configuration file:/

//

/|keycloak-quickstarts/app-authz-photoz/photoz-realm.json |/

//

/That will import a pre-configured realm with everything you need to run 
this quickstart. For more details about how to import a realm into 
Keycloak, check the Keycloak's reference documentation./

//

/After importing that file, you'll have a new realm called //|photoz|//./




Regarsd,

Olivier




Le 12/05/2019 ? 07:56, Sebastien Blanc a ?crit?:
> I have used the import command, whereas one should use the "add
> realm"/select file and doc should you mention to upload file here.
> I think keycloak quikstart guide doc example clarity could be improved
> with above comment to avoid any further confusion
-- 


<http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/images/LogoSignature.gif>

	<http://www.janua.fr/images/6g_top.gif>
	
Olivier Rivat
CTO
orivat at janua.fr <mailto:dchikhaoui at janua.fr>
Gsm: +33(0)682 801 609
T?l: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
	<http://www.janua.fr/images/6g_top.gif>



From shiva.prasad.thagadur.prakash at ericsson.com  Mon May 13 08:42:26 2019
From: shiva.prasad.thagadur.prakash at ericsson.com (Shiva Prasad Thagadur Prakash)
Date: Mon, 13 May 2019 12:42:26 +0000
Subject: [keycloak-dev] How to enable logging on console for dev environment
Message-ID: <1557751346.22248.3.camel@ericsson.com>

Hi Guys,
How to enable logging on console in development environment? I am not
able to see logs on console when I start keycloak server using "mvn -f
testsuite/utils/pom.xml exec:java -Pkeycloak-server?".?

Thanks,
Shiva


From mhajas at redhat.com  Mon May 13 09:07:53 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Mon, 13 May 2019 15:07:53 +0200
Subject: [keycloak-dev] How to enable logging on console for dev
	environment
In-Reply-To: <1557751346.22248.3.camel@ericsson.com>
References: <1557751346.22248.3.camel@ericsson.com>
Message-ID: <CACv4bCQL996OqNq1C08SGD=X02F9cUpyB5vP=2sUf1p30qOfuw@mail.gmail.com>

Hi,

you need to add property -Dkeycloak.logging.level=debug. See:
https://github.com/keycloak/keycloak/blob/master/testsuite/utils/src/main/resources/log4j.properties#L26

Regards,
Michal Hajas

On Mon, May 13, 2019 at 2:44 PM Shiva Prasad Thagadur Prakash <
shiva.prasad.thagadur.prakash at ericsson.com> wrote:

> Hi Guys,
> How to enable logging on console in development environment? I am not
> able to see logs on console when I start keycloak server using "mvn -f
> testsuite/utils/pom.xml exec:java -Pkeycloak-server ".
>
> Thanks,
> Shiva
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From shiva.prasad.thagadur.prakash at ericsson.com  Mon May 13 09:29:53 2019
From: shiva.prasad.thagadur.prakash at ericsson.com (Shiva Prasad Thagadur Prakash)
Date: Mon, 13 May 2019 13:29:53 +0000
Subject: [keycloak-dev] How to enable logging on console for dev
 environment
In-Reply-To: <CACv4bCQL996OqNq1C08SGD=X02F9cUpyB5vP=2sUf1p30qOfuw@mail.gmail.com>
References: <1557751346.22248.3.camel@ericsson.com>
	<CACv4bCQL996OqNq1C08SGD=X02F9cUpyB5vP=2sUf1p30qOfuw@mail.gmail.com>
Message-ID: <1557754193.22248.6.camel@ericsson.com>

Hi Michal Hajas,

Thank you very much.

Best regards,
Shiva
On ma, 2019-05-13 at 15:07 +0200, Michal Hajas wrote:
> Hi,
> 
> you need to add property?-Dkeycloak.logging.level=debug. See:?https:/
> /github.com/keycloak/keycloak/blob/master/testsuite/utils/src/main/re
> sources/log4j.properties#L26
> 
> Regards,
> Michal Hajas
> 
> On Mon, May 13, 2019 at 2:44 PM Shiva Prasad Thagadur Prakash <shiva.
> prasad.thagadur.prakash at ericsson.com> wrote:
> > Hi Guys,
> > How to enable logging on console in development environment? I am
> > not
> > able to see logs on console when I start keycloak server using "mvn
> > -f
> > testsuite/utils/pom.xml exec:java -Pkeycloak-server?".?
> > 
> > Thanks,
> > Shiva
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Mon May 13 18:17:09 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 13 May 2019 19:17:09 -0300
Subject: [keycloak-dev] Typescript support for Node.js adapter
In-Reply-To: <a3032ce6-b579-437b-7109-b03b79250658@redhat.com>
References: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>
	<CAJgngAfbn4BZ2srchmB86CnfQOLHa9=t6wXbbPRZ2pTBp9ZJcw@mail.gmail.com>
	<20190510121525.GA10675@abstractj.org>
	<a3032ce6-b579-437b-7109-b03b79250658@redhat.com>
Message-ID: <20190513221709.GC1516@abstractj.org>

Thanks Stan, I'm adding Evan so he can provide his thoughts on it.

On 2019-05-10, Stan Silvert wrote:
> On 5/10/2019 8:15 AM, Bruno Oliveira wrote:
> > If you ask me, I'm not crazy about the idea of providing Typescript
> > definitions inside the Node.js adapter. And there's a single request
> > from the community about it.
> >
> > At the same time, it's hard to ignore some numbers. The weekly NPM
> > downloads for Typescript is almost 5 million[1] and for ts-node[2] is
> > almost 2 million.
> >
> > The goal of that PR is to provide only the Typescript definitions for
> > the Node.js adapter, so that projects using the adapter can benefit from
> > it.  If we agree to move forward with this, I believe some automated way
> > to generate it, has to be provided.
> >
> > Thoughts?
> Yes, you should provide it.? These days, every serious javascript 
> library is expected to have a definition file.
> 
> I don't think there would be any way to automate creation of the file 
> unless you write your code in TypeScript.
> >
> > [1] - https://www.npmjs.com/package/typescript
> > [2] - https://www.npmjs.com/package/ts-node
> >
> > On 2019-05-10, Stian Thorgersen wrote:
> >> Is Typescript commonly used in the Node.js community? From what
> >> I understand it is very popular with client-side js these days.
> >>
> >> On Thu, 9 May 2019 at 20:59, Bruno Oliveira <bruno at abstractj.org> wrote:
> >>
> >>> Good morning, we have this PR opened long time ago
> >>> https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.
> >>> Before review it and probably update it I would like to ask.
> >>>
> >>> Is Typescript something that we would like to support in the Node.js
> >>> adapter? If your answer is yes, why?
> >>>
> >>> --
> >>> - 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

-- 

abstractj

From eshortis at redhat.com  Mon May 13 22:10:44 2019
From: eshortis at redhat.com (Evan Shortiss)
Date: Mon, 13 May 2019 19:10:44 -0700
Subject: [keycloak-dev] Typescript support for Node.js adapter
In-Reply-To: <20190513221709.GC1516@abstractj.org>
References: <CAM5SUC46_1Y5ptZdDHsOd728rkNjVX-sFMzVyNKua8OzqtJ2og@mail.gmail.com>
	<CAJgngAfbn4BZ2srchmB86CnfQOLHa9=t6wXbbPRZ2pTBp9ZJcw@mail.gmail.com>
	<20190510121525.GA10675@abstractj.org>
	<a3032ce6-b579-437b-7109-b03b79250658@redhat.com>
	<20190513221709.GC1516@abstractj.org>
Message-ID: <CA+BWC0JCBvqb4voDdbtKvvtaR_VTzxbMEz0d452NVQBbHYQEiA@mail.gmail.com>

It's a developer experience and polish thing IMO. Not critical to runtime,
but massively helpful for development.

Looking at the docs here[1] I can guess at what argument types are, but
have no *real *idea if I guessed them correctly until I get a runtime
failure or some sort of undefined/unexpected behaviour. I'll always favour
fail fast behaviour and typings provide it by vetting my code before
runtime. There also seem to be some functions available (defined in the PR
d.ts file) that are not covered in docs (I may need to look harder?) so a
*d.ts* file would allow you generate some docs for these functions.

If the kc team don't want to support it types can be published in
DefinitelyTyped[2] and maintained by others instead. If it becomes a team
priority they can eventually be moved into the official module.

[1] -
https://www.keycloak.org/docs/latest/securing_apps/index.html#_nodejs_adapter
[2] - https://github.com/DefinitelyTyped/DefinitelyTyped

On Mon, May 13, 2019 at 3:17 PM Bruno Oliveira <bruno at abstractj.org> wrote:

> Thanks Stan, I'm adding Evan so he can provide his thoughts on it.
>
> On 2019-05-10, Stan Silvert wrote:
> > On 5/10/2019 8:15 AM, Bruno Oliveira wrote:
> > > If you ask me, I'm not crazy about the idea of providing Typescript
> > > definitions inside the Node.js adapter. And there's a single request
> > > from the community about it.
> > >
> > > At the same time, it's hard to ignore some numbers. The weekly NPM
> > > downloads for Typescript is almost 5 million[1] and for ts-node[2] is
> > > almost 2 million.
> > >
> > > The goal of that PR is to provide only the Typescript definitions for
> > > the Node.js adapter, so that projects using the adapter can benefit
> from
> > > it.  If we agree to move forward with this, I believe some automated
> way
> > > to generate it, has to be provided.
> > >
> > > Thoughts?
> > Yes, you should provide it.  These days, every serious javascript
> > library is expected to have a definition file.
> >
> > I don't think there would be any way to automate creation of the file
> > unless you write your code in TypeScript.
> > >
> > > [1] - https://www.npmjs.com/package/typescript
> > > [2] - https://www.npmjs.com/package/ts-node
> > >
> > > On 2019-05-10, Stian Thorgersen wrote:
> > >> Is Typescript commonly used in the Node.js community? From what
> > >> I understand it is very popular with client-side js these days.
> > >>
> > >> On Thu, 9 May 2019 at 20:59, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> > >>
> > >>> Good morning, we have this PR opened long time ago
> > >>> https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.
> > >>> Before review it and probably update it I would like to ask.
> > >>>
> > >>> Is Typescript something that we would like to support in the Node.js
> > >>> adapter? If your answer is yes, why?
> > >>>
> > >>> --
> > >>> - 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
>
> --
>
> abstractj
>


-- 

Evan Shortiss

Technical Marketing Manager

Red Hat NA <https://www.redhat.com/>

Los Angeles

evan.shortiss at redhat.com
M: +1-781-354-2834     IM: evanshortiss
<https://www.redhat.com/>

From khaianisnizar2007 at gmail.com  Tue May 14 16:47:44 2019
From: khaianisnizar2007 at gmail.com (khaianisnizar2007)
Date: Tue, 14 May 2019 20:47:44 +0000
Subject: [keycloak-dev] keycloak-dev Digest, Vol 71, Issue 7
In-Reply-To: <mailman.25829.1557786052.4530.keycloak-dev@lists.jboss.org>
Message-ID: <5cdb2979.1c69fb81.fa699.123a@mx.google.com>

Dear Keycloak developers,What is the appropriate authorisation flow?For mobile ( swift , kotlin) application ??I used before code grant flow for spa app ( react js)?To use the same strong flow i m facing during redirect uri to personalise the webview ,?But the end users continue to make remarks concerning webview,?I m thinking to use resource owner user credentials passwords but after a lot search i find a lot of bad recommandations precisely about trusting end user app (mobile).Can u advice or help me to adopt best approach.Best regards.Envoy? depuis mon smartphone Samsung Galaxy.
-------- Message d'origine --------De : keycloak-dev-request at lists.jboss.org Date : 13/05/2019  22:20  (GMT+00:00) ? : keycloak-dev at lists.jboss.org Objet : keycloak-dev Digest, Vol 71, Issue 7 Send keycloak-dev mailing list submissions to	keycloak-dev at lists.jboss.orgTo subscribe or unsubscribe via the World Wide Web, visit	https://lists.jboss.org/mailman/listinfo/keycloak-devor, via email, send a message with subject or body 'help' to	keycloak-dev-request at lists.jboss.orgYou can reach the person managing the list at	keycloak-dev-owner at lists.jboss.orgWhen replying, please edit your Subject line so it is more specificthan "Re: Contents of keycloak-dev digest..."Today's Topics:?? 1. Re: Proposal: REST Endpoint for creating TOTP (Stian Thorgersen)?? 2. Not properly closed connections in????? org.keycloak.adapters.ServerRequest (Maksym Gendin)?? 3. Re: Cannot get UMA photoz example working (keycloak????? quickstart 6.0.1) (Olivier Rivat)?? 4. How to enable logging on console for dev environment????? (Shiva Prasad Thagadur Prakash)?? 5. Re: How to enable logging on console for dev	environment????? (Michal Hajas)?? 6. Re: How to enable logging on console for dev environment????? (Shiva Prasad Thagadur Prakash)?? 7. Re: Typescript support for Node.js adapter (Bruno Oliveira)----------------------------------------------------------------------Message: 1Date: Mon, 13 May 2019 10:57:50 +0200From: Stian Thorgersen <sthorger at redhat.com>Subject: Re: [keycloak-dev] Proposal: REST Endpoint for creating TOTPTo: Roland Werner <contributing.to.keycloak at gmail.com>Cc: keycloak-dev <keycloak-dev at lists.jboss.org>Message-ID:	<CAJgngAdRCZvrH+Wa13rGi93=0J1ZuN+dWW0NmELW36gDn1U2gw at mail.gmail.com>Content-Type: text/plain; charset="UTF-8"Having an admin create OTP codes in this way and printing it out meansthere are more people with access to confidential secrets that needed. Thisis also a harder way for users to configure/enable OTP. Further, it is notvery future proof. Sofware OTP tokens are already pretty much legacy soyour company will at some point want to move to something more secure likeWebAuthn Security Keys, in which case your approach of printing QR codes onpaper won't work and you will need to change your process.A better approach which is what Keycloak already supports is requiringusers to enable OTP on first login. That way the secret is only exposed toKeycloak and the user, not to other systems and people. Further, this caneasily be changed in the future to require users to register a WebAuthnsecurity key for instance.With regards to the proposed endpoint we do not want specific OTP endpointslike this as we are working towards making Keycloak less hard-coded aroundthe concept of software OTP and allow flexiblity to support any credentialtypes.On Mon, 13 May 2019 at 10:42, Roland Werner <contributing.to.keycloak at gmail.com> wrote:> Hi,>> I noticed that the REST API (> https://www.keycloak.org/docs-api/6.0/rest-api/index.html) does contain an> endpoint "Remove TOTP from the user", but none that allows to create a TOTP> for a user in the first place.>> I'm proposing to add this "create-totp" endpoint and would also contribute> it. The call would look like this:>> curl -X PUT -H 'Content-Type: application/json' -H 'Authorization: Bearer> <token>' -i http://> <keycloak-url>:<port>/auth/admin/realms/myrealm/users/<user-id>/create-totp>> and the reply as follow:> {>?? "totpSecret": "aA3mIuIzvxTmC5gqUqpl",>?? "qrCode": "iVBORw0KGgoAAA...AAABJRU5ErkJggg=="> }>> I would check the existence of TOTP on the requested user and would reply> with 400-Bad-Request and the message> {>?? "errorMessage": "User already has totp. Remove first."> }> in that case (just to make sure that this doesn't happen on accident).> One question in that respect: The JavaDocs of> org.keycloak.representations.idm.UserRepresentation says that isTotp is> deprecated, but doesn't say what to use instead. Can someone point me to> the right direction here?>> I am aware that the current practice in Keycloak when adding a TOTP to a> user is to instantly request a generated OTP and only if that is correct> add the credential-type to the user. Obviously this would not apply for the> REST endpoint. However, as the endpoint is only reachable for an admin I> don't think this would result in a significant security loss, especially as> the "remove-totp" endpoint can also be used without the need to enter an> OTP.>> I suggest to align the code with the behavior of the remove-totp endpoint,> such that> - it uses PUT> - it is called on given user> - it requires the same admin rights>> This reason for my approach is that we want to introduce a process in our> organisation where every user in the given realm is forced to use an OTP to> login and there is no self-registration but instead the users are handed> over the QR-Code outside of Keycloak (on paper or digitally). In the> meantime we use a custom plugin, but I would love to see this also make its> way into the standard Keycloak.>> What do you think?>> Thanks and Regards,> Roland> _______________________________________________> keycloak-dev mailing list> keycloak-dev at lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev>------------------------------Message: 2Date: Mon, 13 May 2019 13:36:30 +0200From: Maksym Gendin <maksym.gendin at gmail.com>Subject: [keycloak-dev] Not properly closed connections in	org.keycloak.adapters.ServerRequestTo: keycloak-dev at lists.jboss.orgMessage-ID:	<CAKm1Xe+3EzfY-_gbLsfHJhbN474O9ift3FLtfFCCFv_yhwbgXA at mail.gmail.com>Content-Type: text/plain; charset="UTF-8"Dear Keycloak developers,I have noticed a potential problem with closing the connectionsin org.keycloak.adapters.ServerRequest#invokeClientManagementRequest method.I'm facing problems with number of opened files on a linux machine andtrying to identify the source...querying the open connections with netstatI see a couple of connections in CLOSE_WAIT status from my microserviceinstances towards Keycloak...Can someone confirm me that the ServerRequest class closes the connectionsin a proper way?Best regardsMaksym------------------------------Message: 3Date: Mon, 13 May 2019 14:16:06 +0200From: Olivier Rivat <orivat at janua.fr>Subject: Re: [keycloak-dev] Cannot get UMA photoz example working	(keycloak quickstart 6.0.1)To: Sebastien Blanc <sblanc at redhat.com>Cc: keycloak-dev <keycloak-dev at lists.jboss.org>,	keycloak-user	<keycloak-user at lists.jboss.org>Message-ID: <646ae16a-96a3-1f24-2b31-62642dd7134e at janua.fr>Content-Type: text/plain; charset=utf-8; format=floweddiscrepancy is :1) I was using the import command of the master realm to upload photoz-realm.json(it was my mistake)2) you should do as follows:a) select "Add realm"b) select "Select File" and upload photoz-realm.json---> quickstart realm and everything is created succesfullyIt is following text which has confused me quite a lot, and which should be clearer documented (indicating to use the button add-realm for exampkle)https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-photoz??? /Create the Example Realm and a Resource Server////Considering that your Keycloak Server is up and running, log in to the Keycloak Administration Console.////Now, create a new realm based on the following configuration file:////|keycloak-quickstarts/app-authz-photoz/photoz-realm.json |////That will import a pre-configured realm with everything you need to run this quickstart. For more details about how to import a realm into Keycloak, check the Keycloak's reference documentation.////After importing that file, you'll have a new realm called //|photoz|//./Regarsd,OlivierLe 12/05/2019 ? 07:56, Sebastien Blanc a ?crit?:> I have used the import command, whereas one should use the "add> realm"/select file and doc should you mention to upload file here.> I think keycloak quikstart guide doc example clarity could be improved> with above comment to avoid any further confusion-- <http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/images/LogoSignature.gif>	<http://www.janua.fr/images/6g_top.gif>	Olivier RivatCTOorivat at janua.fr <mailto:dchikhaoui at janua.fr>Gsm: +33(0)682 801 609T?l: +33(0)489 829 238Fax: +33(0)955 260 370http://www.janua.fr <http://www.janua.fr/>	<http://www.janua.fr/images/6g_top.gif>------------------------------Message: 4Date: Mon, 13 May 2019 12:42:26 +0000From: Shiva Prasad Thagadur Prakash	<shiva.prasad.thagadur.prakash at ericsson.com>Subject: [keycloak-dev] How to enable logging on console for dev	environmentTo: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>Message-ID: <1557751346.22248.3.camel at ericsson.com>Content-Type: text/plain; charset="utf-8"Hi Guys,How to enable logging on console in development environment? I am notable to see logs on console when I start keycloak server using "mvn -ftestsuite/utils/pom.xml exec:java -Pkeycloak-server?".?Thanks,Shiva------------------------------Message: 5Date: Mon, 13 May 2019 15:07:53 +0200From: Michal Hajas <mhajas at redhat.com>Subject: Re: [keycloak-dev] How to enable logging on console for dev	environmentTo: Shiva Prasad Thagadur Prakash	<shiva.prasad.thagadur.prakash at ericsson.com>Cc: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>Message-ID:	<CACv4bCQL996OqNq1C08SGD=X02F9cUpyB5vP=2sUf1p30qOfuw at mail.gmail.com>Content-Type: text/plain; charset="UTF-8"Hi,you need to add property -Dkeycloak.logging.level=debug. See:https://github.com/keycloak/keycloak/blob/master/testsuite/utils/src/main/resources/log4j.properties#L26Regards,Michal HajasOn Mon, May 13, 2019 at 2:44 PM Shiva Prasad Thagadur Prakash <shiva.prasad.thagadur.prakash at ericsson.com> wrote:> Hi Guys,> How to enable logging on console in development environment? I am not> able to see logs on console when I start keycloak server using "mvn -f> testsuite/utils/pom.xml exec:java -Pkeycloak-server ".>> Thanks,> Shiva>> _______________________________________________> keycloak-dev mailing list> keycloak-dev at lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev------------------------------Message: 6Date: Mon, 13 May 2019 13:29:53 +0000From: Shiva Prasad Thagadur Prakash	<shiva.prasad.thagadur.prakash at ericsson.com>Subject: Re: [keycloak-dev] How to enable logging on console for dev	environmentTo: "mhajas at redhat.com" <mhajas at redhat.com>Cc: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>Message-ID: <1557754193.22248.6.camel at ericsson.com>Content-Type: text/plain; charset="utf-8"Hi Michal Hajas,Thank you very much.Best regards,ShivaOn ma, 2019-05-13 at 15:07 +0200, Michal Hajas wrote:> Hi,> > you need to add property?-Dkeycloak.logging.level=debug. See:?https:/> /github.com/keycloak/keycloak/blob/master/testsuite/utils/src/main/re> sources/log4j.properties#L26> > Regards,> Michal Hajas> > On Mon, May 13, 2019 at 2:44 PM Shiva Prasad Thagadur Prakash <shiva.> prasad.thagadur.prakash at ericsson.com> wrote:> > Hi Guys,> > How to enable logging on console in development environment? I am> > not> > able to see logs on console when I start keycloak server using "mvn> > -f> > testsuite/utils/pom.xml exec:java -Pkeycloak-server?".?> > > > Thanks,> > Shiva> > > > _______________________________________________> > keycloak-dev mailing list> > keycloak-dev at lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev------------------------------Message: 7Date: Mon, 13 May 2019 19:17:09 -0300From: Bruno Oliveira <bruno at abstractj.org>Subject: Re: [keycloak-dev] Typescript support for Node.js adapterTo: Stan Silvert <ssilvert at redhat.com>Cc: evanshortiss at gmail.com, keycloak-dev at lists.jboss.orgMessage-ID: <20190513221709.GC1516 at abstractj.org>Content-Type: text/plain; charset=utf-8Thanks Stan, I'm adding Evan so he can provide his thoughts on it.On 2019-05-10, Stan Silvert wrote:> On 5/10/2019 8:15 AM, Bruno Oliveira wrote:> > If you ask me, I'm not crazy about the idea of providing Typescript> > definitions inside the Node.js adapter. And there's a single request> > from the community about it.> >> > At the same time, it's hard to ignore some numbers. The weekly NPM> > downloads for Typescript is almost 5 million[1] and for ts-node[2] is> > almost 2 million.> >> > The goal of that PR is to provide only the Typescript definitions for> > the Node.js adapter, so that projects using the adapter can benefit from> > it.? If we agree to move forward with this, I believe some automated way> > to generate it, has to be provided.> >> > Thoughts?> Yes, you should provide it.? These days, every serious javascript > library is expected to have a definition file.> > I don't think there would be any way to automate creation of the file > unless you write your code in TypeScript.> >> > [1] - https://www.npmjs.com/package/typescript> > [2] - https://www.npmjs.com/package/ts-node> >> > On 2019-05-10, Stian Thorgersen wrote:> >> Is Typescript commonly used in the Node.js community? From what> >> I understand it is very popular with client-side js these days.> >>> >> On Thu, 9 May 2019 at 20:59, Bruno Oliveira <bruno at abstractj.org> wrote:> >>> >>> Good morning, we have this PR opened long time ago> >>> https://github.com/keycloak/keycloak-nodejs-connect/pull/123/files.> >>> Before review it and probably update it I would like to ask.> >>>> >>> Is Typescript something that we would like to support in the Node.js> >>> adapter? If your answer is yes, why?> >>>> >>> --> >>> - 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-- abstractj------------------------------_______________________________________________keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-devEnd of keycloak-dev Digest, Vol 71, Issue 7*******************************************

From sthorger at redhat.com  Wed May 15 04:41:39 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 May 2019 10:41:39 +0200
Subject: [keycloak-dev] Anyone going to KubeCon?
Message-ID: <CAJgngAfDabVk2hgSWdVjm4nyuUcjHuirk_ErPrJLcCu305Uj7Q@mail.gmail.com>

I'm going to KubeCon and would love to have a chat with anyone from the
Keycloak community that are also going.

From sthorger at redhat.com  Wed May 15 07:22:21 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 May 2019 13:22:21 +0200
Subject: [keycloak-dev] Moving container files from
 https://github.com/jboss-dockerfiles/keycloak to
 https://github.com/keycloak-containers
In-Reply-To: <baadeac9e66745a0a5f31f7b980718fb@Thales.no>
References: <CAJgngAf8Z3wEVuMr3F0XW_TB932QVqzhvvH9UVv+S6PrY4GfGw@mail.gmail.com>
	<CAM5SUC59odSzjnpU_aV2H9Rx0UFGCXzaGckJPo_Q5fvxVL7g7A@mail.gmail.com>
	<CAA9R9O5Q5RSY1OYUr_tQcpTNL4dyYY2qVcsSZXJ8mku1zu7XTg@mail.gmail.com>
	<CAJgngAfqiXzyD91CxU9feVZczmxhufDoiyufn8+_=b3f+HmQLA@mail.gmail.com>
	<baadeac9e66745a0a5f31f7b980718fb@Thales.no>
Message-ID: <CAJgngAceWTL_=OdmSyu4qVDsxLpuemLES6SMvMGFwtW=Y93s1A@mail.gmail.com>

Soon - any specific reason you're asking?

On Mon, 13 May 2019 at 09:24, Lars Wilhelmsen <Lars.Wilhelmsen at thales.no>
wrote:

> ETA?
>
>  --larsw
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org <
> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen
> Sent: onsdag 8. mai 2019 13:57
> To: Sebastian Laskawiec <slaskawi at redhat.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Moving container files from
> https://github.com/jboss-dockerfiles/keycloak to
> https://github.com/keycloak-containers
>
> Yep, missed one keycloak in there ;)
>
> On Wed, 8 May 2019 at 13:55, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
> > Hey Stian,
> >
> > I guess you mean ttps://github.com/keycloak/keycloak-containers
> > <https://github.com/keycloak-containers> (keycloak-containers repo
> > under keycloak organization)? If so, +1 from me.
> >
> > Thanks,
> > Seb
> >
> > On Wed, May 8, 2019 at 1:19 PM Bruno Oliveira <bruno at abstractj.org>
> wrote:
> >
> >> +1
> >>
> >> On Wed, May 8, 2019 at 8:06 AM Stian Thorgersen <sthorger at redhat.com>
> >> wrote:
> >> >
> >> > I'm planning on moving
> >> > https://github.com/jboss-dockerfiles/keycloak to
> https://github.com/keycloak-containers.
> >> > _______________________________________________
> >> > 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 sthorger at redhat.com  Wed May 15 09:59:37 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 May 2019 15:59:37 +0200
Subject: [keycloak-dev] Request for review: Chinese translation of email
	verification page
Message-ID: <CAJgngAc7oMNbq-z8VV1RMuHKSS7v6xKv4cyWeEHUv4PL=WsDfg@mail.gmail.com>

I need help from the community to review:

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

From sthorger at redhat.com  Wed May 15 10:00:08 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 15 May 2019 16:00:08 +0200
Subject: [keycloak-dev] Review request: Arabic translation
Message-ID: <CAJgngAcysH=usW4FuOboEaMj41AuHJ81UQkr=ev+N2__sDPXAg@mail.gmail.com>

I need help from the community to review $sub:

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

From psilva at redhat.com  Thu May 16 11:14:02 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 16 May 2019 12:14:02 -0300
Subject: [keycloak-dev] Users and Realms
Message-ID: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>

Hi,

As you know, currently users belong to a realm and as such, you can't share
them across different realms. We always had people looking for alternatives
about how to solve this problem where all the available options have their
pros and cons.

I would like to see what you think about decoupling users from realms in a
way that user federation and management are completely decoupled from
realms so that users (or group of users) can be *associated* with realms.

As an example, here is how you would configure users and realms in Keycloak:

1) Configure your identity stores/user federation from where users will be
fetched. Or create users in Keycloak.

2) Assign to your users a label or a logical group. This assignment could
be done manually or even automatically depending on:

    a) default group where all users are in
    b) the identity store from where users are fetched
    c) based on the user's email (domain)
    d) anything else that makes sense

3) Create a realm and specify which users should belong to a realm based on
these labels or groups. A realm should be able to have users with different
labels/groups.

The realm definition/configuration would not change much as it stands
today. Each of them would still have their own way of managing realm
specific groups and roles.

Regards.
Pedro Igor

From federico.facca at martel-innovate.com  Thu May 16 15:54:35 2019
From: federico.facca at martel-innovate.com (Federico Michele Facca)
Date: Thu, 16 May 2019 21:54:35 +0200
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
Message-ID: <CAOxz=rNmSKjaToSgRexz+Du+-d9LOGSqdAQC=mGwfhWXw0A=mg@mail.gmail.com>

Dear Pedro,
this is a very relevant discussion to us. We currently solved the issue
using a single realm,
and using "root" level groups with a attribute "tenant=true". We have then
created a custom
client to manage this configuration from the single "tenant" admin
perspective.

This solution for us allows to manage "multi-tenancy" also at the single
oidc client without
much complexity (your approach wouldn't allow for that, right?)
Of course we had to use some tricks to do fine grained control access,
which is basically working under the assumption you attach users to groups
and you
manage roles attached to groups and not to users. Then, within the token,
we return
user roles per client based on their group membership.

Cheers,
Federico

On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> As you know, currently users belong to a realm and as such, you can't share
> them across different realms. We always had people looking for alternatives
> about how to solve this problem where all the available options have their
> pros and cons.
>
> I would like to see what you think about decoupling users from realms in a
> way that user federation and management are completely decoupled from
> realms so that users (or group of users) can be *associated* with realms.
>
> As an example, here is how you would configure users and realms in
> Keycloak:
>
> 1) Configure your identity stores/user federation from where users will be
> fetched. Or create users in Keycloak.
>
> 2) Assign to your users a label or a logical group. This assignment could
> be done manually or even automatically depending on:
>
>     a) default group where all users are in
>     b) the identity store from where users are fetched
>     c) based on the user's email (domain)
>     d) anything else that makes sense
>
> 3) Create a realm and specify which users should belong to a realm based on
> these labels or groups. A realm should be able to have users with different
> labels/groups.
>
> The realm definition/configuration would not change much as it stands
> today. Each of them would still have their own way of managing realm
> specific groups and roles.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
+41 788075838
*MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE MAKE
IT HAPPEN
Click *HERE* to download Martel reports and white papers!
<https://www.martel-innovate.com/premium-content/>
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>

From ssilvert at redhat.com  Fri May 17 06:27:15 2019
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 17 May 2019 06:27:15 -0400
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
Message-ID: <87dfd341-273f-8deb-146b-b663db117fd4@redhat.com>

I think it's worth considering if we still have use cases without a good 
solution.

On 5/16/2019 11:14 AM, Pedro Igor Silva wrote:
> Hi,
>
> As you know, currently users belong to a realm and as such, you can't share
> them across different realms. We always had people looking for alternatives
> about how to solve this problem where all the available options have their
> pros and cons.
>
> I would like to see what you think about decoupling users from realms in a
> way that user federation and management are completely decoupled from
> realms so that users (or group of users) can be *associated* with realms.
>
> As an example, here is how you would configure users and realms in Keycloak:
>
> 1) Configure your identity stores/user federation from where users will be
> fetched. Or create users in Keycloak.
>
> 2) Assign to your users a label or a logical group. This assignment could
> be done manually or even automatically depending on:
>
>      a) default group where all users are in
>      b) the identity store from where users are fetched
>      c) based on the user's email (domain)
>      d) anything else that makes sense
>
> 3) Create a realm and specify which users should belong to a realm based on
> these labels or groups. A realm should be able to have users with different
> labels/groups.
>
> The realm definition/configuration would not change much as it stands
> today. Each of them would still have their own way of managing realm
> specific groups and roles.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From bruno at abstractj.org  Fri May 17 08:40:12 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 17 May 2019 09:40:12 -0300
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
Message-ID: <20190517124012.GA13325@abstractj.org>

I agree with Stan on the use cases.

Looking at what you suggested it reminds me about something that we
talked some time ago called "Realms of realms".

The idea consisted of sharing clients, roles, client scopes,
users...across multiple instances through realm inheritance. Into other
words, you have a "master" realm with these items that you wanted to
share, and the other realms that would benefit from it. Keep in mind that I'm
briefly summarizing it.

Of course, the complexity to implement this is far from being simple as your
proposal, but maybe your idea could complement what was suggested for
"Realms of realms".

On 2019-05-16, Pedro Igor Silva wrote:
> Hi,
> 
> As you know, currently users belong to a realm and as such, you can't share
> them across different realms. We always had people looking for alternatives
> about how to solve this problem where all the available options have their
> pros and cons.
> 
> I would like to see what you think about decoupling users from realms in a
> way that user federation and management are completely decoupled from
> realms so that users (or group of users) can be *associated* with realms.
> 
> As an example, here is how you would configure users and realms in Keycloak:
> 
> 1) Configure your identity stores/user federation from where users will be
> fetched. Or create users in Keycloak.
> 
> 2) Assign to your users a label or a logical group. This assignment could
> be done manually or even automatically depending on:
> 
>     a) default group where all users are in
>     b) the identity store from where users are fetched
>     c) based on the user's email (domain)
>     d) anything else that makes sense
> 
> 3) Create a realm and specify which users should belong to a realm based on
> these labels or groups. A realm should be able to have users with different
> labels/groups.
> 
> The realm definition/configuration would not change much as it stands
> today. Each of them would still have their own way of managing realm
> specific groups and roles.
> 
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From psilva at redhat.com  Fri May 17 09:03:45 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 17 May 2019 10:03:45 -0300
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAOxz=rNmSKjaToSgRexz+Du+-d9LOGSqdAQC=mGwfhWXw0A=mg@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
	<CAOxz=rNmSKjaToSgRexz+Du+-d9LOGSqdAQC=mGwfhWXw0A=mg@mail.gmail.com>
Message-ID: <CAJrcDBc5y6iwPBWoUWYGdmZ5iHK_hdHVyZWBRbvMWAb-kAsQVQ@mail.gmail.com>

Good to know about your approach to multi-tenancy. It is an interesting
solution.

On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca <
federico.facca at martel-innovate.com> wrote:

> Dear Pedro,
> this is a very relevant discussion to us. We currently solved the issue
> using a single realm,
> and using "root" level groups with a attribute "tenant=true". We have then
> created a custom
> client to manage this configuration from the single "tenant" admin
> perspective.
>

Could you elaborate more on that, please? I understand how you are using
groups and the tenant attribute, but what you exactly mean by "custom
client to manage this configuration" ?

I guess you all your tenants share the same security policies defined on
the realm level too?


>
> This solution for us allows to manage "multi-tenancy" also at the single
> oidc client without
> much complexity (your approach wouldn't allow for that, right?)
>

Do your users have access to different tenants? When issuing tokens to
these users, do you have roles within the token for each tenant the user
belongs to?


> Of course we had to use some tricks to do fine grained control access,
> which is basically working under the assumption you attach users to groups
> and you
> manage roles attached to groups and not to users. Then, within the token,
> we return
> user roles per client based on their group membership.
>
> Cheers,
> Federico
>
> On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hi,
>>
>> As you know, currently users belong to a realm and as such, you can't
>> share
>> them across different realms. We always had people looking for
>> alternatives
>> about how to solve this problem where all the available options have their
>> pros and cons.
>>
>> I would like to see what you think about decoupling users from realms in a
>> way that user federation and management are completely decoupled from
>> realms so that users (or group of users) can be *associated* with realms.
>>
>> As an example, here is how you would configure users and realms in
>> Keycloak:
>>
>> 1) Configure your identity stores/user federation from where users will be
>> fetched. Or create users in Keycloak.
>>
>> 2) Assign to your users a label or a logical group. This assignment could
>> be done manually or even automatically depending on:
>>
>>     a) default group where all users are in
>>     b) the identity store from where users are fetched
>>     c) based on the user's email (domain)
>>     d) anything else that makes sense
>>
>> 3) Create a realm and specify which users should belong to a realm based
>> on
>> these labels or groups. A realm should be able to have users with
>> different
>> labels/groups.
>>
>> The realm definition/configuration would not change much as it stands
>> today. Each of them would still have their own way of managing realm
>> specific groups and roles.
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> --
> *Dr. FEDERICO MICHELE FACCA*
> *CTO, Head of Martel Lab*
> +41 788075838
> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
> MAKE IT HAPPEN
> Click *HERE* to download Martel reports and white papers!
> <https://www.martel-innovate.com/premium-content/>
> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>

From psilva at redhat.com  Fri May 17 09:29:55 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 17 May 2019 10:29:55 -0300
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <20190517124012.GA13325@abstractj.org>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
	<20190517124012.GA13325@abstractj.org>
Message-ID: <CAJrcDBdr3OAiNn+33nbY4uYT-OUm1vV-4YTis4xWM-vgamOn3w@mail.gmail.com>

Yeah, it was mainly targeted for openshift when we were doing all the
integration work. It is still a good solution to make more flexible realm
configuration. Especially when you have a set of predefined settings that
serve as the skeleton to create realms that are targeted to protect a
specific domain.

My proposal is not simple to implement too. Although it is mainly focused
on solving a specific problem where users can have access to applications
in different realms, thus can be associated with distinct realms.

We have some workarounds to solve this problem but it either relies on
using a single realm or replicating users across realms through identity
brokering. Each one with its pros and cons.

I personally think that the identity broker approach is the most
appropriate option as it kinds of creates a trust model across realms
(federation) while still keeping each realm with their own security
policies and configuration. However, since all trusted realms are in
Keycloak, we have users duplicated across these realms. I would like to see
other opinions about this and if it the approach I'm suggesting (for users)
makes sense.

It should also allow admins to:

* Admins can manage users from a single place
* Admins can map user access more clearly, considering the different realms
they are associated with (traceability)
* Admins can grant/revoke access to users on realms more easily

On Fri, May 17, 2019 at 9:40 AM Bruno Oliveira <bruno at abstractj.org> wrote:

> I agree with Stan on the use cases.
>
> Looking at what you suggested it reminds me about something that we
> talked some time ago called "Realms of realms".
>
> The idea consisted of sharing clients, roles, client scopes,
> users...across multiple instances through realm inheritance. Into other
> words, you have a "master" realm with these items that you wanted to
> share, and the other realms that would benefit from it. Keep in mind that
> I'm
> briefly summarizing it.
>
> Of course, the complexity to implement this is far from being simple as
> your
> proposal, but maybe your idea could complement what was suggested for
> "Realms of realms".
>
> On 2019-05-16, Pedro Igor Silva wrote:
> > Hi,
> >
> > As you know, currently users belong to a realm and as such, you can't
> share
> > them across different realms. We always had people looking for
> alternatives
> > about how to solve this problem where all the available options have
> their
> > pros and cons.
> >
> > I would like to see what you think about decoupling users from realms in
> a
> > way that user federation and management are completely decoupled from
> > realms so that users (or group of users) can be *associated* with realms.
> >
> > As an example, here is how you would configure users and realms in
> Keycloak:
> >
> > 1) Configure your identity stores/user federation from where users will
> be
> > fetched. Or create users in Keycloak.
> >
> > 2) Assign to your users a label or a logical group. This assignment could
> > be done manually or even automatically depending on:
> >
> >     a) default group where all users are in
> >     b) the identity store from where users are fetched
> >     c) based on the user's email (domain)
> >     d) anything else that makes sense
> >
> > 3) Create a realm and specify which users should belong to a realm based
> on
> > these labels or groups. A realm should be able to have users with
> different
> > labels/groups.
> >
> > The realm definition/configuration would not change much as it stands
> > today. Each of them would still have their own way of managing realm
> > specific groups and roles.
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
>
> abstractj
>

From federico.facca at martel-innovate.com  Fri May 17 09:47:18 2019
From: federico.facca at martel-innovate.com (Federico Michele Facca)
Date: Fri, 17 May 2019 15:47:18 +0200
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJrcDBc5y6iwPBWoUWYGdmZ5iHK_hdHVyZWBRbvMWAb-kAsQVQ@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
	<CAOxz=rNmSKjaToSgRexz+Du+-d9LOGSqdAQC=mGwfhWXw0A=mg@mail.gmail.com>
	<CAJrcDBc5y6iwPBWoUWYGdmZ5iHK_hdHVyZWBRbvMWAb-kAsQVQ@mail.gmail.com>
Message-ID: <CAOxz=rMewkgB7HHVMwTrSUhc-79FLwJ_q0ogTXiDBHeWAo1+dA@mail.gmail.com>

Dear Pedro,

On Fri, 17 May 2019 at 15:03, Pedro Igor Silva <psilva at redhat.com> wrote:

> Good to know about your approach to multi-tenancy. It is an interesting
> solution.
>
> On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca <
> federico.facca at martel-innovate.com> wrote:
>
>> Dear Pedro,
>> this is a very relevant discussion to us. We currently solved the issue
>> using a single realm,
>> and using "root" level groups with a attribute "tenant=true". We have
>> then created a custom
>> client to manage this configuration from the single "tenant" admin
>> perspective.
>>
>
> Could you elaborate more on that, please? I understand how you are using
> groups and the tenant attribute, but what you exactly mean by "custom
> client to manage this configuration" ?
>
> I guess you all your tenants share the same security policies defined on
> the realm level too?
>

we have a custom script mapper associated to a "tenants" default scope that
inject the needed information either in the token or in the user profile.

the mapper return something like:

"tenants": [
        {
            "name": "Wolfsburg",
            "groups": [
                {
                    "parent": "Wolfsburg",
                    "realmRoles": [
                        "offline_access"
                    ],
                    "name": "Admin",
                    "clientRoles": [
                        "uma_protection",
                        "entity:delete",
                        "group:create",
                        "device:read",
                        "group:write",
                        "registration:create",
                        "endpoint:create",
                        "subscription:write",
                        "entitytype:read",
                        "user:delete",
                        "subscription:read",
                        "endpoint:read",
                        "group:read",
                        "device:create",
                        "subscription:create",
                        "devicegroup:create",
                        "devicegroup:write",
                        "endpoint:delete",
                        "group:delete",
                        "registration:write",
                        "user:read",
                        "endpoint:write",
                        "entity:read",
                        "entity:create",
                        "devicegroup:read",
                        "user:create",
                        "registration:read",
                        "registration:delete",
                        "entity:write",
                        "devicegroup:delete",
                        "user:write",
                        "subscription:delete",
                        "device:delete",
                        "device:write"
                    ]
                },
                {
                    "parent": "Wolfsburg",
                    "realmRoles": [
                        "offline_access"
                    ],
                    "name": "User",
                    "clientRoles": [
                        "uma_protection",
                        "entity:read",
                        "device:read",
                        "devicegroup:read",
                        "registration:read",
                        "entitytype:read",
                        "subscription:read",
                        "endpoint:read"
                    ]
                },
                {
                    "parent": "Wolfsburg",
                    "realmRoles": [],
                    "name": "WasteManagement",
                    "is_servicepath": true
                }
            ],
            "id": "f6b3d2e5-0064-4d0b-8cea-6e378f2cfff2"
        },
        {
            "name": "Vecciano",
            "groups": [
                {
                    "parent": "Vecciano",
                    "realmRoles": [],
                    "name": "Admin",
                    "clientRoles": [
                        "entity:delete",
                        "group:create",
                        "device:read",
                        "group:write",
                        "registration:create",
                        "endpoint:create",
                        "subscription:write",
                        "entitytype:read",
                        "user:delete",
                        "subscription:read",
                        "endpoint:read",
                        "group:read",
                        "device:create",
                        "subscription:create",
                        "devicegroup:create",
                        "devicegroup:write",
                        "endpoint:delete",
                        "group:delete",
                        "registration:write",
                        "user:read",
                        "endpoint:write",
                        "entity:read",
                        "entity:create",
                        "devicegroup:read",
                        "user:create",
                        "registration:read",
                        "registration:delete",
                        "entity:write",
                        "devicegroup:delete",
                        "user:write",
                        "subscription:delete",
                        "device:delete",
                        "device:write"
                    ]
                }
            ],
            "id": "c088dbc0-a01c-45fc-9304-926cd881e690"
        }
    ],


>
>
>>
>> This solution for us allows to manage "multi-tenancy" also at the single
>> oidc client without
>> much complexity (your approach wouldn't allow for that, right?)
>>
>
> Do your users have access to different tenants? When issuing tokens to
> these users, do you have roles within the token for each tenant the user
> belongs to?
>

yes, user have access to different tenants. as you saw above we have roles
per tenants.
we are thinking of adding some mechanism (based on scope or claims ?) to
return only roles for a specific tenant of the user.

This solution allows to avoid to replicate the same configuration of a
client across different realms, which would be quite annoying.
I suppose it's not optimal, but we couldn't think of anything better.

Cheers,
Federico


>
>
>> Of course we had to use some tricks to do fine grained control access,
>> which is basically working under the assumption you attach users to
>> groups and you
>> manage roles attached to groups and not to users. Then, within the token,
>> we return
>> user roles per client based on their group membership.
>>
>> Cheers,
>> Federico
>>
>> On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> As you know, currently users belong to a realm and as such, you can't
>>> share
>>> them across different realms. We always had people looking for
>>> alternatives
>>> about how to solve this problem where all the available options have
>>> their
>>> pros and cons.
>>>
>>> I would like to see what you think about decoupling users from realms in
>>> a
>>> way that user federation and management are completely decoupled from
>>> realms so that users (or group of users) can be *associated* with realms.
>>>
>>> As an example, here is how you would configure users and realms in
>>> Keycloak:
>>>
>>> 1) Configure your identity stores/user federation from where users will
>>> be
>>> fetched. Or create users in Keycloak.
>>>
>>> 2) Assign to your users a label or a logical group. This assignment could
>>> be done manually or even automatically depending on:
>>>
>>>     a) default group where all users are in
>>>     b) the identity store from where users are fetched
>>>     c) based on the user's email (domain)
>>>     d) anything else that makes sense
>>>
>>> 3) Create a realm and specify which users should belong to a realm based
>>> on
>>> these labels or groups. A realm should be able to have users with
>>> different
>>> labels/groups.
>>>
>>> The realm definition/configuration would not change much as it stands
>>> today. Each of them would still have their own way of managing realm
>>> specific groups and roles.
>>>
>>> Regards.
>>> Pedro Igor
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>> --
>> *Dr. FEDERICO MICHELE FACCA*
>> *CTO, Head of Martel Lab*
>> +41 788075838
>> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
>> MAKE IT HAPPEN
>> Click *HERE* to download Martel reports and white papers!
>> <https://www.martel-innovate.com/premium-content/>
>> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>>
>

-- 
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
+41 788075838
*MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE MAKE
IT HAPPEN
Click *HERE* to download Martel reports and white papers!
<https://www.martel-innovate.com/premium-content/>
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>

From psilva at redhat.com  Fri May 17 10:35:12 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 17 May 2019 11:35:12 -0300
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAOxz=rMewkgB7HHVMwTrSUhc-79FLwJ_q0ogTXiDBHeWAo1+dA@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
	<CAOxz=rNmSKjaToSgRexz+Du+-d9LOGSqdAQC=mGwfhWXw0A=mg@mail.gmail.com>
	<CAJrcDBc5y6iwPBWoUWYGdmZ5iHK_hdHVyZWBRbvMWAb-kAsQVQ@mail.gmail.com>
	<CAOxz=rMewkgB7HHVMwTrSUhc-79FLwJ_q0ogTXiDBHeWAo1+dA@mail.gmail.com>
Message-ID: <CAJrcDBfzJEt-St2ModcjBCS8vYSAyPjLSmkWKnGP1QFUuAcHMw@mail.gmail.com>

Yes, it makes the configuration and management easier by avoiding multiple
realms with the same client replicated on each of them. But it also has
some cons as all your tenants share the same security policies (as they are
within a single realm) and your tokens size would increase a lot depending
on how many tenants the user can access. For the latter, you should be able
to workaround by using client scopes or improving the logic in your mapper.

With my proposal, some issues you are trying to avoid would still be there,
such as client replication. Which could be addressed by having some
provisioning logic that could be used automatically create a realm
accordingly with your needs. In fact, this is something that could also be
addressed by the "Realms of Realms" approach that Bruno mentioned.

However, you would still have the standard Keycloak model but with the
possibility to have the same user across different realms, each realm with
distinct policies, configuration, etc.

On Fri, May 17, 2019 at 10:47 AM Federico Michele Facca <
federico.facca at martel-innovate.com> wrote:

> Dear Pedro,
>
> On Fri, 17 May 2019 at 15:03, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Good to know about your approach to multi-tenancy. It is an interesting
>> solution.
>>
>> On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca <
>> federico.facca at martel-innovate.com> wrote:
>>
>>> Dear Pedro,
>>> this is a very relevant discussion to us. We currently solved the issue
>>> using a single realm,
>>> and using "root" level groups with a attribute "tenant=true". We have
>>> then created a custom
>>> client to manage this configuration from the single "tenant" admin
>>> perspective.
>>>
>>
>> Could you elaborate more on that, please? I understand how you are using
>> groups and the tenant attribute, but what you exactly mean by "custom
>> client to manage this configuration" ?
>>
>> I guess you all your tenants share the same security policies defined on
>> the realm level too?
>>
>
> we have a custom script mapper associated to a "tenants" default scope
> that inject the needed information either in the token or in the user
> profile.
>
> the mapper return something like:
>
> "tenants": [
>         {
>             "name": "Wolfsburg",
>             "groups": [
>                 {
>                     "parent": "Wolfsburg",
>                     "realmRoles": [
>                         "offline_access"
>                     ],
>                     "name": "Admin",
>                     "clientRoles": [
>                         "uma_protection",
>                         "entity:delete",
>                         "group:create",
>                         "device:read",
>                         "group:write",
>                         "registration:create",
>                         "endpoint:create",
>                         "subscription:write",
>                         "entitytype:read",
>                         "user:delete",
>                         "subscription:read",
>                         "endpoint:read",
>                         "group:read",
>                         "device:create",
>                         "subscription:create",
>                         "devicegroup:create",
>                         "devicegroup:write",
>                         "endpoint:delete",
>                         "group:delete",
>                         "registration:write",
>                         "user:read",
>                         "endpoint:write",
>                         "entity:read",
>                         "entity:create",
>                         "devicegroup:read",
>                         "user:create",
>                         "registration:read",
>                         "registration:delete",
>                         "entity:write",
>                         "devicegroup:delete",
>                         "user:write",
>                         "subscription:delete",
>                         "device:delete",
>                         "device:write"
>                     ]
>                 },
>                 {
>                     "parent": "Wolfsburg",
>                     "realmRoles": [
>                         "offline_access"
>                     ],
>                     "name": "User",
>                     "clientRoles": [
>                         "uma_protection",
>                         "entity:read",
>                         "device:read",
>                         "devicegroup:read",
>                         "registration:read",
>                         "entitytype:read",
>                         "subscription:read",
>                         "endpoint:read"
>                     ]
>                 },
>                 {
>                     "parent": "Wolfsburg",
>                     "realmRoles": [],
>                     "name": "WasteManagement",
>                     "is_servicepath": true
>                 }
>             ],
>             "id": "f6b3d2e5-0064-4d0b-8cea-6e378f2cfff2"
>         },
>         {
>             "name": "Vecciano",
>             "groups": [
>                 {
>                     "parent": "Vecciano",
>                     "realmRoles": [],
>                     "name": "Admin",
>                     "clientRoles": [
>                         "entity:delete",
>                         "group:create",
>                         "device:read",
>                         "group:write",
>                         "registration:create",
>                         "endpoint:create",
>                         "subscription:write",
>                         "entitytype:read",
>                         "user:delete",
>                         "subscription:read",
>                         "endpoint:read",
>                         "group:read",
>                         "device:create",
>                         "subscription:create",
>                         "devicegroup:create",
>                         "devicegroup:write",
>                         "endpoint:delete",
>                         "group:delete",
>                         "registration:write",
>                         "user:read",
>                         "endpoint:write",
>                         "entity:read",
>                         "entity:create",
>                         "devicegroup:read",
>                         "user:create",
>                         "registration:read",
>                         "registration:delete",
>                         "entity:write",
>                         "devicegroup:delete",
>                         "user:write",
>                         "subscription:delete",
>                         "device:delete",
>                         "device:write"
>                     ]
>                 }
>             ],
>             "id": "c088dbc0-a01c-45fc-9304-926cd881e690"
>         }
>     ],
>
>
>>
>>
>>>
>>> This solution for us allows to manage "multi-tenancy" also at the single
>>> oidc client without
>>> much complexity (your approach wouldn't allow for that, right?)
>>>
>>
>> Do your users have access to different tenants? When issuing tokens to
>> these users, do you have roles within the token for each tenant the user
>> belongs to?
>>
>
> yes, user have access to different tenants. as you saw above we have roles
> per tenants.
> we are thinking of adding some mechanism (based on scope or claims ?) to
> return only roles for a specific tenant of the user.
>
> This solution allows to avoid to replicate the same configuration of a
> client across different realms, which would be quite annoying.
> I suppose it's not optimal, but we couldn't think of anything better.
>
> Cheers,
> Federico
>
>
>>
>>
>>> Of course we had to use some tricks to do fine grained control access,
>>> which is basically working under the assumption you attach users to
>>> groups and you
>>> manage roles attached to groups and not to users. Then, within the
>>> token, we return
>>> user roles per client based on their group membership.
>>>
>>> Cheers,
>>> Federico
>>>
>>> On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> As you know, currently users belong to a realm and as such, you can't
>>>> share
>>>> them across different realms. We always had people looking for
>>>> alternatives
>>>> about how to solve this problem where all the available options have
>>>> their
>>>> pros and cons.
>>>>
>>>> I would like to see what you think about decoupling users from realms
>>>> in a
>>>> way that user federation and management are completely decoupled from
>>>> realms so that users (or group of users) can be *associated* with
>>>> realms.
>>>>
>>>> As an example, here is how you would configure users and realms in
>>>> Keycloak:
>>>>
>>>> 1) Configure your identity stores/user federation from where users will
>>>> be
>>>> fetched. Or create users in Keycloak.
>>>>
>>>> 2) Assign to your users a label or a logical group. This assignment
>>>> could
>>>> be done manually or even automatically depending on:
>>>>
>>>>     a) default group where all users are in
>>>>     b) the identity store from where users are fetched
>>>>     c) based on the user's email (domain)
>>>>     d) anything else that makes sense
>>>>
>>>> 3) Create a realm and specify which users should belong to a realm
>>>> based on
>>>> these labels or groups. A realm should be able to have users with
>>>> different
>>>> labels/groups.
>>>>
>>>> The realm definition/configuration would not change much as it stands
>>>> today. Each of them would still have their own way of managing realm
>>>> specific groups and roles.
>>>>
>>>> Regards.
>>>> Pedro Igor
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>> --
>>> *Dr. FEDERICO MICHELE FACCA*
>>> *CTO, Head of Martel Lab*
>>> +41 788075838
>>> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
>>> MAKE IT HAPPEN
>>> Click *HERE* to download Martel reports and white papers!
>>> <https://www.martel-innovate.com/premium-content/>
>>> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>>>
>>
>
> --
> *Dr. FEDERICO MICHELE FACCA*
> *CTO, Head of Martel Lab*
> +41 788075838
> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
> MAKE IT HAPPEN
> Click *HERE* to download Martel reports and white papers!
> <https://www.martel-innovate.com/premium-content/>
> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>

From federico.facca at martel-innovate.com  Fri May 17 10:46:41 2019
From: federico.facca at martel-innovate.com (Federico Michele Facca)
Date: Fri, 17 May 2019 16:46:41 +0200
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJrcDBfzJEt-St2ModcjBCS8vYSAyPjLSmkWKnGP1QFUuAcHMw@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
	<CAOxz=rNmSKjaToSgRexz+Du+-d9LOGSqdAQC=mGwfhWXw0A=mg@mail.gmail.com>
	<CAJrcDBc5y6iwPBWoUWYGdmZ5iHK_hdHVyZWBRbvMWAb-kAsQVQ@mail.gmail.com>
	<CAOxz=rMewkgB7HHVMwTrSUhc-79FLwJ_q0ogTXiDBHeWAo1+dA@mail.gmail.com>
	<CAJrcDBfzJEt-St2ModcjBCS8vYSAyPjLSmkWKnGP1QFUuAcHMw@mail.gmail.com>
Message-ID: <CAOxz=rMOnJp_jkkiibeM-QsD9NF3JWyv=7gHJ+y3xDSz3-g3gA@mail.gmail.com>

Indeed "Realms of Realms" sounds nice :)

Regarding token size, this is true. Currently we trick this by using the
mapper on the in the user profile (we want tokens to be minimal).
Anyhow, ideally, we would like to have this information in the token for a
specific tenant to reduce api interactions (so far the only way
we thought is to use a scope for each tenant and use this scope to generate
the output of the mapper - of course if you have any better idea,
that will not break the standard OIDC, we are happy to try).

Cheers,
Federico

On Fri, 17 May 2019 at 16:35, Pedro Igor Silva <psilva at redhat.com> wrote:

> Yes, it makes the configuration and management easier by avoiding multiple
> realms with the same client replicated on each of them. But it also has
> some cons as all your tenants share the same security policies (as they are
> within a single realm) and your tokens size would increase a lot depending
> on how many tenants the user can access. For the latter, you should be able
> to workaround by using client scopes or improving the logic in your mapper.
>
> With my proposal, some issues you are trying to avoid would still be
> there, such as client replication. Which could be addressed by having some
> provisioning logic that could be used automatically create a realm
> accordingly with your needs. In fact, this is something that could also be
> addressed by the "Realms of Realms" approach that Bruno mentioned.
>
> However, you would still have the standard Keycloak model but with the
> possibility to have the same user across different realms, each realm with
> distinct policies, configuration, etc.
>
> On Fri, May 17, 2019 at 10:47 AM Federico Michele Facca <
> federico.facca at martel-innovate.com> wrote:
>
>> Dear Pedro,
>>
>> On Fri, 17 May 2019 at 15:03, Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> Good to know about your approach to multi-tenancy. It is an interesting
>>> solution.
>>>
>>> On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca <
>>> federico.facca at martel-innovate.com> wrote:
>>>
>>>> Dear Pedro,
>>>> this is a very relevant discussion to us. We currently solved the issue
>>>> using a single realm,
>>>> and using "root" level groups with a attribute "tenant=true". We have
>>>> then created a custom
>>>> client to manage this configuration from the single "tenant" admin
>>>> perspective.
>>>>
>>>
>>> Could you elaborate more on that, please? I understand how you are using
>>> groups and the tenant attribute, but what you exactly mean by "custom
>>> client to manage this configuration" ?
>>>
>>> I guess you all your tenants share the same security policies defined on
>>> the realm level too?
>>>
>>
>> we have a custom script mapper associated to a "tenants" default scope
>> that inject the needed information either in the token or in the user
>> profile.
>>
>> the mapper return something like:
>>
>> "tenants": [
>>         {
>>             "name": "Wolfsburg",
>>             "groups": [
>>                 {
>>                     "parent": "Wolfsburg",
>>                     "realmRoles": [
>>                         "offline_access"
>>                     ],
>>                     "name": "Admin",
>>                     "clientRoles": [
>>                         "uma_protection",
>>                         "entity:delete",
>>                         "group:create",
>>                         "device:read",
>>                         "group:write",
>>                         "registration:create",
>>                         "endpoint:create",
>>                         "subscription:write",
>>                         "entitytype:read",
>>                         "user:delete",
>>                         "subscription:read",
>>                         "endpoint:read",
>>                         "group:read",
>>                         "device:create",
>>                         "subscription:create",
>>                         "devicegroup:create",
>>                         "devicegroup:write",
>>                         "endpoint:delete",
>>                         "group:delete",
>>                         "registration:write",
>>                         "user:read",
>>                         "endpoint:write",
>>                         "entity:read",
>>                         "entity:create",
>>                         "devicegroup:read",
>>                         "user:create",
>>                         "registration:read",
>>                         "registration:delete",
>>                         "entity:write",
>>                         "devicegroup:delete",
>>                         "user:write",
>>                         "subscription:delete",
>>                         "device:delete",
>>                         "device:write"
>>                     ]
>>                 },
>>                 {
>>                     "parent": "Wolfsburg",
>>                     "realmRoles": [
>>                         "offline_access"
>>                     ],
>>                     "name": "User",
>>                     "clientRoles": [
>>                         "uma_protection",
>>                         "entity:read",
>>                         "device:read",
>>                         "devicegroup:read",
>>                         "registration:read",
>>                         "entitytype:read",
>>                         "subscription:read",
>>                         "endpoint:read"
>>                     ]
>>                 },
>>                 {
>>                     "parent": "Wolfsburg",
>>                     "realmRoles": [],
>>                     "name": "WasteManagement",
>>                     "is_servicepath": true
>>                 }
>>             ],
>>             "id": "f6b3d2e5-0064-4d0b-8cea-6e378f2cfff2"
>>         },
>>         {
>>             "name": "Vecciano",
>>             "groups": [
>>                 {
>>                     "parent": "Vecciano",
>>                     "realmRoles": [],
>>                     "name": "Admin",
>>                     "clientRoles": [
>>                         "entity:delete",
>>                         "group:create",
>>                         "device:read",
>>                         "group:write",
>>                         "registration:create",
>>                         "endpoint:create",
>>                         "subscription:write",
>>                         "entitytype:read",
>>                         "user:delete",
>>                         "subscription:read",
>>                         "endpoint:read",
>>                         "group:read",
>>                         "device:create",
>>                         "subscription:create",
>>                         "devicegroup:create",
>>                         "devicegroup:write",
>>                         "endpoint:delete",
>>                         "group:delete",
>>                         "registration:write",
>>                         "user:read",
>>                         "endpoint:write",
>>                         "entity:read",
>>                         "entity:create",
>>                         "devicegroup:read",
>>                         "user:create",
>>                         "registration:read",
>>                         "registration:delete",
>>                         "entity:write",
>>                         "devicegroup:delete",
>>                         "user:write",
>>                         "subscription:delete",
>>                         "device:delete",
>>                         "device:write"
>>                     ]
>>                 }
>>             ],
>>             "id": "c088dbc0-a01c-45fc-9304-926cd881e690"
>>         }
>>     ],
>>
>>
>>>
>>>
>>>>
>>>> This solution for us allows to manage "multi-tenancy" also at the
>>>> single oidc client without
>>>> much complexity (your approach wouldn't allow for that, right?)
>>>>
>>>
>>> Do your users have access to different tenants? When issuing tokens to
>>> these users, do you have roles within the token for each tenant the user
>>> belongs to?
>>>
>>
>> yes, user have access to different tenants. as you saw above we have
>> roles per tenants.
>> we are thinking of adding some mechanism (based on scope or claims ?) to
>> return only roles for a specific tenant of the user.
>>
>> This solution allows to avoid to replicate the same configuration of a
>> client across different realms, which would be quite annoying.
>> I suppose it's not optimal, but we couldn't think of anything better.
>>
>> Cheers,
>> Federico
>>
>>
>>>
>>>
>>>> Of course we had to use some tricks to do fine grained control access,
>>>> which is basically working under the assumption you attach users to
>>>> groups and you
>>>> manage roles attached to groups and not to users. Then, within the
>>>> token, we return
>>>> user roles per client based on their group membership.
>>>>
>>>> Cheers,
>>>> Federico
>>>>
>>>> On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As you know, currently users belong to a realm and as such, you can't
>>>>> share
>>>>> them across different realms. We always had people looking for
>>>>> alternatives
>>>>> about how to solve this problem where all the available options have
>>>>> their
>>>>> pros and cons.
>>>>>
>>>>> I would like to see what you think about decoupling users from realms
>>>>> in a
>>>>> way that user federation and management are completely decoupled from
>>>>> realms so that users (or group of users) can be *associated* with
>>>>> realms.
>>>>>
>>>>> As an example, here is how you would configure users and realms in
>>>>> Keycloak:
>>>>>
>>>>> 1) Configure your identity stores/user federation from where users
>>>>> will be
>>>>> fetched. Or create users in Keycloak.
>>>>>
>>>>> 2) Assign to your users a label or a logical group. This assignment
>>>>> could
>>>>> be done manually or even automatically depending on:
>>>>>
>>>>>     a) default group where all users are in
>>>>>     b) the identity store from where users are fetched
>>>>>     c) based on the user's email (domain)
>>>>>     d) anything else that makes sense
>>>>>
>>>>> 3) Create a realm and specify which users should belong to a realm
>>>>> based on
>>>>> these labels or groups. A realm should be able to have users with
>>>>> different
>>>>> labels/groups.
>>>>>
>>>>> The realm definition/configuration would not change much as it stands
>>>>> today. Each of them would still have their own way of managing realm
>>>>> specific groups and roles.
>>>>>
>>>>> Regards.
>>>>> Pedro Igor
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> *Dr. FEDERICO MICHELE FACCA*
>>>> *CTO, Head of Martel Lab*
>>>> +41 788075838
>>>> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
>>>> MAKE IT HAPPEN
>>>> Click *HERE* to download Martel reports and white papers!
>>>> <https://www.martel-innovate.com/premium-content/>
>>>> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>>>>
>>>
>>
>> --
>> *Dr. FEDERICO MICHELE FACCA*
>> *CTO, Head of Martel Lab*
>> +41 788075838
>> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
>> MAKE IT HAPPEN
>> Click *HERE* to download Martel reports and white papers!
>> <https://www.martel-innovate.com/premium-content/>
>> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>>
>

-- 
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
+41 788075838
*MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE MAKE
IT HAPPEN
Click *HERE* to download Martel reports and white papers!
<https://www.martel-innovate.com/premium-content/>
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>

From federico.facca at martel-innovate.com  Mon May 20 05:30:55 2019
From: federico.facca at martel-innovate.com (Federico Michele Facca)
Date: Mon, 20 May 2019 11:30:55 +0200
Subject: [keycloak-dev] configure longer access tokens / permanent access
	tokens
Message-ID: <CAOxz=rNUtvgtEJQbRkhtjARU=i4LA_30m0-ayFtRAFpsOJTGtQ@mail.gmail.com>

Dear All,
to better support IoT devices, we are looking to support longer expiration
for specific tokens
(when using a specific scope - in a similar way to offline_access scope).
We have been looking into:
https://github.com/looorent/keycloak-configurable-token-api

The issue is that, while using this plugin it is possible to extend the
life of a token,
the underlying session will anyhow expire based on the max duration of
token lifespan,
so if you validate the token after the session expiration, the validation
will say that the token
is not active.

What could be a non intrusive way to support extending the life of specific
sessions associated
to such tokens? (i.e. without making changes to the core code).

We thought about changing the started value in the session an put it in the
future, but this is not actually possible. Only getStarted is available on
UserSessions. An other alternative would be to set a very long token
lifespan for the client , but the all tokens will have such long life
(which is not what we aim for).

Any feedback / idea is welcome :)

Cheers,
Federico

From sthorger at redhat.com  Mon May 20 05:31:17 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 20 May 2019 11:31:17 +0200
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
Message-ID: <CAJgngAdvSrBsTGwzjMMXfs8XoKtm1L5aG29UNDyjtLb2CZ5OxQ@mail.gmail.com>

For the new store I was actually thinking that we could completely detach
users from the realm. Rather than have a user store as part of the realm we
would just have an optional Keycloak user store that could be attached to a
realm in the same was as any other user store.

We shouldn't make any such big changes to the current store though and
rather reserve that to the next store.

On Thu, 16 May 2019 at 17:56, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> As you know, currently users belong to a realm and as such, you can't share
> them across different realms. We always had people looking for alternatives
> about how to solve this problem where all the available options have their
> pros and cons.
>
> I would like to see what you think about decoupling users from realms in a
> way that user federation and management are completely decoupled from
> realms so that users (or group of users) can be *associated* with realms.
>
> As an example, here is how you would configure users and realms in
> Keycloak:
>
> 1) Configure your identity stores/user federation from where users will be
> fetched. Or create users in Keycloak.
>
> 2) Assign to your users a label or a logical group. This assignment could
> be done manually or even automatically depending on:
>
>     a) default group where all users are in
>     b) the identity store from where users are fetched
>     c) based on the user's email (domain)
>     d) anything else that makes sense
>
> 3) Create a realm and specify which users should belong to a realm based on
> these labels or groups. A realm should be able to have users with different
> labels/groups.
>
> The realm definition/configuration would not change much as it stands
> today. Each of them would still have their own way of managing realm
> specific groups and roles.
>
> 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  Mon May 20 08:03:38 2019
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 20 May 2019 09:03:38 -0300
Subject: [keycloak-dev] Users and Realms
In-Reply-To: <CAJgngAdvSrBsTGwzjMMXfs8XoKtm1L5aG29UNDyjtLb2CZ5OxQ@mail.gmail.com>
References: <CAJrcDBcZqFQPJUxzNE0GfWU4bUYVLOUgaUpn-huOOdPQAA-d=w@mail.gmail.com>
	<CAJgngAdvSrBsTGwzjMMXfs8XoKtm1L5aG29UNDyjtLb2CZ5OxQ@mail.gmail.com>
Message-ID: <CAJrcDBckzPPda8BbFeRssAFHF15+eH10w2nJCqAQqNuxZn5NDw@mail.gmail.com>

Sounds like a good plan to me ...

On Mon, May 20, 2019 at 6:31 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> For the new store I was actually thinking that we could completely detach
> users from the realm. Rather than have a user store as part of the realm we
> would just have an optional Keycloak user store that could be attached to a
> realm in the same was as any other user store.
>
> We shouldn't make any such big changes to the current store though and
> rather reserve that to the next store.
>
> On Thu, 16 May 2019 at 17:56, Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Hi,
>>
>> As you know, currently users belong to a realm and as such, you can't
>> share
>> them across different realms. We always had people looking for
>> alternatives
>> about how to solve this problem where all the available options have their
>> pros and cons.
>>
>> I would like to see what you think about decoupling users from realms in a
>> way that user federation and management are completely decoupled from
>> realms so that users (or group of users) can be *associated* with realms.
>>
>> As an example, here is how you would configure users and realms in
>> Keycloak:
>>
>> 1) Configure your identity stores/user federation from where users will be
>> fetched. Or create users in Keycloak.
>>
>> 2) Assign to your users a label or a logical group. This assignment could
>> be done manually or even automatically depending on:
>>
>>     a) default group where all users are in
>>     b) the identity store from where users are fetched
>>     c) based on the user's email (domain)
>>     d) anything else that makes sense
>>
>> 3) Create a realm and specify which users should belong to a realm based
>> on
>> these labels or groups. A realm should be able to have users with
>> different
>> labels/groups.
>>
>> The realm definition/configuration would not change much as it stands
>> today. Each of them would still have their own way of managing realm
>> specific groups and roles.
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From vramik at redhat.com  Tue May 21 04:16:39 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Tue, 21 May 2019 10:16:39 +0200
Subject: [keycloak-dev] jdk7 for tomcat modules
Message-ID: <649fb747-8c55-0049-d8a6-c81e04637206@redhat.com>

Hey guys,

I'm working on https://issues.jboss.org/browse/KEYCLOAK-9596 Remove 
Apache Tomcat 6.0.x adapter, as a side affect I plan to update jdk 
version for compiler from 1.6 to 1.7 for all modules related to tomcat 
adapter. Does anyone have any objections?

Thanks,

V.


From sthorger at redhat.com  Tue May 21 04:41:59 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 21 May 2019 10:41:59 +0200
Subject: [keycloak-dev] configure longer access tokens / permanent
	access tokens
In-Reply-To: <CAOxz=rNUtvgtEJQbRkhtjARU=i4LA_30m0-ayFtRAFpsOJTGtQ@mail.gmail.com>
References: <CAOxz=rNUtvgtEJQbRkhtjARU=i4LA_30m0-ayFtRAFpsOJTGtQ@mail.gmail.com>
Message-ID: <CAJgngAeSny5TO2mH6RBfR9dq4EPvWWcuTdLykMhiGAx3fNPHiQ@mail.gmail.com>

This would be very relevant both for mobile and IoT. It would be something
we'd be interested in having a contribution around.

A few points from me:

* Add a new session type for the realms which is longer duration. It should
still have some timeouts as otherwise it will never be cleared up.
* Configurable session type per client?
* Request longer duration session type with scope?


On Mon, 20 May 2019 at 11:32, Federico Michele Facca <
federico.facca at martel-innovate.com> wrote:

> Dear All,
> to better support IoT devices, we are looking to support longer expiration
> for specific tokens
> (when using a specific scope - in a similar way to offline_access scope).
> We have been looking into:
> https://github.com/looorent/keycloak-configurable-token-api
>
> The issue is that, while using this plugin it is possible to extend the
> life of a token,
> the underlying session will anyhow expire based on the max duration of
> token lifespan,
> so if you validate the token after the session expiration, the validation
> will say that the token
> is not active.
>
> What could be a non intrusive way to support extending the life of specific
> sessions associated
> to such tokens? (i.e. without making changes to the core code).
>
> We thought about changing the started value in the session an put it in the
> future, but this is not actually possible. Only getStarted is available on
> UserSessions. An other alternative would be to set a very long token
> lifespan for the client , but the all tokens will have such long life
> (which is not what we aim for).
>
> Any feedback / idea is welcome :)
>
> Cheers,
> Federico
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue May 21 04:42:35 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 21 May 2019 10:42:35 +0200
Subject: [keycloak-dev] configure longer access tokens / permanent
	access tokens
In-Reply-To: <CAJgngAeSny5TO2mH6RBfR9dq4EPvWWcuTdLykMhiGAx3fNPHiQ@mail.gmail.com>
References: <CAOxz=rNUtvgtEJQbRkhtjARU=i4LA_30m0-ayFtRAFpsOJTGtQ@mail.gmail.com>
	<CAJgngAeSny5TO2mH6RBfR9dq4EPvWWcuTdLykMhiGAx3fNPHiQ@mail.gmail.com>
Message-ID: <CAJgngAdcJNkj6Tw5VSODBPkijaJmBLZg=6RYcss-SopUFFRZfA@mail.gmail.com>

Ideally sessions like that should also be persisted, otherwise they'd get
lost during upgrades or other downtime of the server.

On Tue, 21 May 2019 at 10:41, Stian Thorgersen <sthorger at redhat.com> wrote:

> This would be very relevant both for mobile and IoT. It would be something
> we'd be interested in having a contribution around.
>
> A few points from me:
>
> * Add a new session type for the realms which is longer duration. It
> should still have some timeouts as otherwise it will never be cleared up.
> * Configurable session type per client?
> * Request longer duration session type with scope?
>
>
> On Mon, 20 May 2019 at 11:32, Federico Michele Facca <
> federico.facca at martel-innovate.com> wrote:
>
>> Dear All,
>> to better support IoT devices, we are looking to support longer expiration
>> for specific tokens
>> (when using a specific scope - in a similar way to offline_access scope).
>> We have been looking into:
>> https://github.com/looorent/keycloak-configurable-token-api
>>
>> The issue is that, while using this plugin it is possible to extend the
>> life of a token,
>> the underlying session will anyhow expire based on the max duration of
>> token lifespan,
>> so if you validate the token after the session expiration, the validation
>> will say that the token
>> is not active.
>>
>> What could be a non intrusive way to support extending the life of
>> specific
>> sessions associated
>> to such tokens? (i.e. without making changes to the core code).
>>
>> We thought about changing the started value in the session an put it in
>> the
>> future, but this is not actually possible. Only getStarted is available on
>> UserSessions. An other alternative would be to set a very long token
>> lifespan for the client , but the all tokens will have such long life
>> (which is not what we aim for).
>>
>> Any feedback / idea is welcome :)
>>
>> Cheers,
>> Federico
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From marc.ewert at leverton.ai  Tue May 21 08:34:57 2019
From: marc.ewert at leverton.ai (Marc Ewert)
Date: Tue, 21 May 2019 12:34:57 +0000
Subject: [keycloak-dev] Providing idpHint in JavaScript Adapter JSON
	configuration
Message-ID: <1feb1baf-a648-fc46-3bbf-cf77cfe73f52@leverton.ai>

Hi,

we would like to create a very small PR for the JavaScript Adapter (keycloak.js).  This change would allow one to provide the idpHint via the JSON configuration which could of course then be dynamically served by a backend. By this everyone could generate a JSON of the following format:

{
  realm: "production",
  auth-server-url: "https://customer-a.example.com/auth"<https://customer-a.example.com/auth>,
  bearer-only: false,
  resource: "frontend-client",
  idp-hint: "customer-a",
}

The consumption of the idp-hint parameter could be done as an one-liner in keycloak.js. Would it be okay, if we create a PR with the needed change for letting that happen, or are there other as simple solutions, that we are missing?

Best

Marc Ewert

--
________________________________________________
Marc Ewert | Senior Engineering Manager
Leverton GmbH | Sch?neberger Str. 15 | 10963 Berlin | Germany
P +49 30 868 711 059
E marc.ewert at leverton.ai<mailto:marc.ewert at leverton.ai>
https://www.leverton.ai/ | LinkedIn<https://www.linkedin.com/company/leverton>

District Court Berlin-Charlottenburg HRB 140028
Managing Directors: Florian Kuhlmann, Abhinav Somani

From federico.facca at martel-innovate.com  Tue May 21 08:53:30 2019
From: federico.facca at martel-innovate.com (Federico Michele Facca)
Date: Tue, 21 May 2019 14:53:30 +0200
Subject: [keycloak-dev] configure longer access tokens / permanent
	access tokens
In-Reply-To: <CAJgngAdcJNkj6Tw5VSODBPkijaJmBLZg=6RYcss-SopUFFRZfA@mail.gmail.com>
References: <CAOxz=rNUtvgtEJQbRkhtjARU=i4LA_30m0-ayFtRAFpsOJTGtQ@mail.gmail.com>
	<CAJgngAeSny5TO2mH6RBfR9dq4EPvWWcuTdLykMhiGAx3fNPHiQ@mail.gmail.com>
	<CAJgngAdcJNkj6Tw5VSODBPkijaJmBLZg=6RYcss-SopUFFRZfA@mail.gmail.com>
Message-ID: <CAOxz=rNC+vEt_EQ0V3pRz8ypAb1LsQ6yJaSpK4nLWnSMwDW1Ow@mail.gmail.com>

Hi Stian,
ideally (as for offline refresh tokens) you should be able to invalidate
the session manually (e.g. in case the iot device is compromised).

My understanding, is that basically you would be happy to have this in the
core code, right?

At the time being, using the approach of loorent, what we have been
thinking to test is attaching to the access token an offline session
instead of a normal session. I will let you know if this easy experiment
works out :)

Cheers,
Federico

On Tue, 21 May 2019 at 10:42, Stian Thorgersen <sthorger at redhat.com> wrote:

> Ideally sessions like that should also be persisted, otherwise they'd get
> lost during upgrades or other downtime of the server.
>
> On Tue, 21 May 2019 at 10:41, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> This would be very relevant both for mobile and IoT. It would be
>> something we'd be interested in having a contribution around.
>>
>> A few points from me:
>>
>> * Add a new session type for the realms which is longer duration. It
>> should still have some timeouts as otherwise it will never be cleared up.
>> * Configurable session type per client?
>> * Request longer duration session type with scope?
>>
>>
>> On Mon, 20 May 2019 at 11:32, Federico Michele Facca <
>> federico.facca at martel-innovate.com> wrote:
>>
>>> Dear All,
>>> to better support IoT devices, we are looking to support longer
>>> expiration
>>> for specific tokens
>>> (when using a specific scope - in a similar way to offline_access scope).
>>> We have been looking into:
>>> https://github.com/looorent/keycloak-configurable-token-api
>>>
>>> The issue is that, while using this plugin it is possible to extend the
>>> life of a token,
>>> the underlying session will anyhow expire based on the max duration of
>>> token lifespan,
>>> so if you validate the token after the session expiration, the validation
>>> will say that the token
>>> is not active.
>>>
>>> What could be a non intrusive way to support extending the life of
>>> specific
>>> sessions associated
>>> to such tokens? (i.e. without making changes to the core code).
>>>
>>> We thought about changing the started value in the session an put it in
>>> the
>>> future, but this is not actually possible. Only getStarted is available
>>> on
>>> UserSessions. An other alternative would be to set a very long token
>>> lifespan for the client , but the all tokens will have such long life
>>> (which is not what we aim for).
>>>
>>> Any feedback / idea is welcome :)
>>>
>>> Cheers,
>>> Federico
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>

-- 
*Dr. FEDERICO MICHELE FACCA*
*CTO, Head of Martel Lab*
+41 788075838
*MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE MAKE
IT HAPPEN
Click *HERE* to download Martel reports and white papers!
<https://www.martel-innovate.com/premium-content/>
Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>

From sthorger at redhat.com  Tue May 21 09:45:41 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 21 May 2019 15:45:41 +0200
Subject: [keycloak-dev] configure longer access tokens / permanent
	access tokens
In-Reply-To: <CAOxz=rNC+vEt_EQ0V3pRz8ypAb1LsQ6yJaSpK4nLWnSMwDW1Ow@mail.gmail.com>
References: <CAOxz=rNUtvgtEJQbRkhtjARU=i4LA_30m0-ayFtRAFpsOJTGtQ@mail.gmail.com>
	<CAJgngAeSny5TO2mH6RBfR9dq4EPvWWcuTdLykMhiGAx3fNPHiQ@mail.gmail.com>
	<CAJgngAdcJNkj6Tw5VSODBPkijaJmBLZg=6RYcss-SopUFFRZfA@mail.gmail.com>
	<CAOxz=rNC+vEt_EQ0V3pRz8ypAb1LsQ6yJaSpK4nLWnSMwDW1Ow@mail.gmail.com>
Message-ID: <CAJgngAdJV4rzxhFVOFO4H0o5GY60eEEM4d+BKf8VmsAHG3AS8g@mail.gmail.com>

On Tue, 21 May 2019, 14:54 Federico Michele Facca, <
federico.facca at martel-innovate.com> wrote:

> Hi Stian,
> ideally (as for offline refresh tokens) you should be able to invalidate
> the session manually (e.g. in case the iot device is compromised).
>

That should be reasonable simple as it's just about allowing invalidating a
specific session.


> My understanding, is that basically you would be happy to have this in the
> core code, right?
>

Yes, if done properly of course. This should probably start with a proposal
to
https://github.com/keycloak/keycloak-community/tree/master/design

>
> At the time being, using the approach of loorent, what we have been
> thinking to test is attaching to the access token an offline session
> instead of a normal session. I will let you know if this easy experiment
> works out :)
>

Attaching to an offline session is not the right approach I think as it
detaches from the current session.


> Cheers,
> Federico
>
> On Tue, 21 May 2019 at 10:42, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Ideally sessions like that should also be persisted, otherwise they'd get
>> lost during upgrades or other downtime of the server.
>>
>> On Tue, 21 May 2019 at 10:41, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> This would be very relevant both for mobile and IoT. It would be
>>> something we'd be interested in having a contribution around.
>>>
>>> A few points from me:
>>>
>>> * Add a new session type for the realms which is longer duration. It
>>> should still have some timeouts as otherwise it will never be cleared up.
>>> * Configurable session type per client?
>>> * Request longer duration session type with scope?
>>>
>>>
>>> On Mon, 20 May 2019 at 11:32, Federico Michele Facca <
>>> federico.facca at martel-innovate.com> wrote:
>>>
>>>> Dear All,
>>>> to better support IoT devices, we are looking to support longer
>>>> expiration
>>>> for specific tokens
>>>> (when using a specific scope - in a similar way to offline_access
>>>> scope).
>>>> We have been looking into:
>>>> https://github.com/looorent/keycloak-configurable-token-api
>>>>
>>>> The issue is that, while using this plugin it is possible to extend the
>>>> life of a token,
>>>> the underlying session will anyhow expire based on the max duration of
>>>> token lifespan,
>>>> so if you validate the token after the session expiration, the
>>>> validation
>>>> will say that the token
>>>> is not active.
>>>>
>>>> What could be a non intrusive way to support extending the life of
>>>> specific
>>>> sessions associated
>>>> to such tokens? (i.e. without making changes to the core code).
>>>>
>>>> We thought about changing the started value in the session an put it in
>>>> the
>>>> future, but this is not actually possible. Only getStarted is available
>>>> on
>>>> UserSessions. An other alternative would be to set a very long token
>>>> lifespan for the client , but the all tokens will have such long life
>>>> (which is not what we aim for).
>>>>
>>>> Any feedback / idea is welcome :)
>>>>
>>>> Cheers,
>>>> Federico
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>
> --
> *Dr. FEDERICO MICHELE FACCA*
> *CTO, Head of Martel Lab*
> +41 788075838
> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE
> MAKE IT HAPPEN
> Click *HERE* to download Martel reports and white papers!
> <https://www.martel-innovate.com/premium-content/>
> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate>
>

From sthorger at redhat.com  Tue May 21 09:50:10 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 21 May 2019 15:50:10 +0200
Subject: [keycloak-dev] Providing idpHint in JavaScript Adapter JSON
	configuration
In-Reply-To: <1feb1baf-a648-fc46-3bbf-cf77cfe73f52@leverton.ai>
References: <1feb1baf-a648-fc46-3bbf-cf77cfe73f52@leverton.ai>
Message-ID: <CAJgngAeK5=qisbsrnv5t4kRLk7RSGVJOA0PcowrHzaGBa0-u1Q@mail.gmail.com>

I'm not too keen on adding little bits like this to keycloak.json on its
own. Today we have the config split between keycloak.json and init. I'd be
open to allow configuring what you can through init in Keycloak.json, but
would have to be a complete pr with docs and tests.

On Tue, 21 May 2019, 14:37 Marc Ewert, <marc.ewert at leverton.ai> wrote:

> Hi,
>
> we would like to create a very small PR for the JavaScript Adapter
> (keycloak.js).  This change would allow one to provide the idpHint via the
> JSON configuration which could of course then be dynamically served by a
> backend. By this everyone could generate a JSON of the following format:
>
> {
>   realm: "production",
>   auth-server-url: "https://customer-a.example.com/auth"<
> https://customer-a.example.com/auth>,
>   bearer-only: false,
>   resource: "frontend-client",
>   idp-hint: "customer-a",
> }
>
> The consumption of the idp-hint parameter could be done as an one-liner in
> keycloak.js. Would it be okay, if we create a PR with the needed change for
> letting that happen, or are there other as simple solutions, that we are
> missing?
>
> Best
>
> Marc Ewert
>
> --
> ________________________________________________
> Marc Ewert | Senior Engineering Manager
> Leverton GmbH | Sch?neberger Str. 15 | 10963 Berlin | Germany
> P +49 30 868 711 059
> E marc.ewert at leverton.ai<mailto:marc.ewert at leverton.ai>
> https://www.leverton.ai/ | LinkedIn<
> https://www.linkedin.com/company/leverton>
>
> District Court Berlin-Charlottenburg HRB 140028
> Managing Directors: Florian Kuhlmann, Abhinav Somani
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From orivat at janua.fr  Wed May 22 04:27:37 2019
From: orivat at janua.fr (Olivier Rivat)
Date: Wed, 22 May 2019 10:27:37 +0200
Subject: [keycloak-dev] keycloak quick start example Uma Photoz:
 authorization request to resource owner not working
Message-ID: <65da42dd-150c-522f-5938-de71111ea5d9@janua.fr>


Hi,

I am using

Keycloak 6.0.1
wildfly 16
chrome 74
https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-authz-uma-photoz

Done the test several time
1)just unzip keycloak
2) and uploded phothoz-realm.json
3) create alice vacation album with greece view permission for joe
4) log as Joe, but cannot sent delete request

I always obtain:
You can not access or perform the requested operation on this resource.

instead of
Sent authorization request to resource owner, please, wait for approval.

Is is a misconfiguration of mine (I have been through the example 
several times) or might it be a bug ?

Regards,
Olivier Rivat




-- 


<http://www.janua.fr/images/logo-big-sans.png><http://www.janua.fr/images/LogoSignature.gif>

	<http://www.janua.fr/images/6g_top.gif>
	
Olivier Rivat
CTO
orivat at janua.fr <mailto:dchikhaoui at janua.fr>
Gsm: +33(0)682 801 609
T?l: +33(0)489 829 238
Fax: +33(0)955 260 370
http://www.janua.fr <http://www.janua.fr/>
	<http://www.janua.fr/images/6g_top.gif>



From mhajas at redhat.com  Wed May 22 10:13:49 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Wed, 22 May 2019 16:13:49 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
Message-ID: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>

Hi all,

currently, we are using phantomjs browser for running Node.js tests [1].
However, we are experiencing some issues which seem to be caused by
phantomjs, so we are considering to change the default browser from
phantomjs to headless chrome.

Do you have some objections why not to do so?

[1]
https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25

From vmuzikar at redhat.com  Wed May 22 10:40:58 2019
From: vmuzikar at redhat.com (=?UTF-8?B?VsOhY2xhdiBNdXppa8OhxZk=?=)
Date: Wed, 22 May 2019 16:40:58 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
Message-ID: <CAMQSZyijjAVGP==rKeJ9ZfwTssvcCAxi49pYRJdpCjOn7hfCeg@mail.gmail.com>

+1
Using a real-life browser is always better and more credible than synthetic
browsers.

However, we need to keep Travis in mind before doing such change.

On Wed, May 22, 2019 at 4:30 PM Michal Hajas <mhajas at redhat.com> wrote:

> Hi all,
>
> currently, we are using phantomjs browser for running Node.js tests [1].
> However, we are experiencing some issues which seem to be caused by
> phantomjs, so we are considering to change the default browser from
> phantomjs to headless chrome.
>
> Do you have some objections why not to do so?
>
> [1]
>
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


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

From Sebastian.Schuster at bosch-si.com  Wed May 22 10:47:50 2019
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST-CSS/BSV-OS2))
Date: Wed, 22 May 2019 14:47:50 +0000
Subject: [keycloak-dev] User Consents via Account REST API
Message-ID: <7cc300612a8f4ec7b71cf0fb7449f081@bosch-si.com>

Hi everybody (and probably especially Stan and Stian),

In some of our projects we want to make heavy use of Keycloaks ability to obtain user consent to third parties to access user data in our APIs.
In one project, the third parties provide modules that plug into our app and the user should give his consent for this plugin at plugin installation time.
We plan to have one client for every plugin so the user can for every plugin decide which scope of backend API access it wants to grant to the plugin.
I would be cool if asking for consent would be possible from the app in its UI at the point when the user installs the plugin.

To do that, we would like to extend the account REST Api that?s currently in preview state so it

a)    covers the ?applications? functionality (this is currently a TODO)

b)    allows to create consents using the REST Api. I am well aware there might be security implications here for clients that are essentially public, e.g. a rogue app could manage consents of a user if he does not pay attention.

c)     use a finer-grained role model for the accounts service, e.g. at least splitting up view-account into view-profile+view-consents and manage-account into manage-profile+manage-consents so we can control which clients may invoke the consents functionality or we can prevent changing profile attributes
that come from an external IDP in our case.

What do you think about these changes/additions? Do they make sense? If yes, we would like to contribute them.

Thanks and best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | 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
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic




From bruno at abstractj.org  Wed May 22 13:46:07 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 22 May 2019 14:46:07 -0300
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
 Phantomjs
In-Reply-To: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
Message-ID: <20190522174607.GC5458@abstractj.org>

Hi Michal, I'm not against changing the browser used for testing, as
long as we keep Travis happy, like Va?ek mentioned.

Before we make this decision, I suggest to first isolate the tests and
give it a try with some headless browser (maybe chrome-headless). After
that, we can decide whether or not we should drop phantomjs.

On 2019-05-22, Michal Hajas wrote:
> Hi all,
> 
> currently, we are using phantomjs browser for running Node.js tests [1].
> However, we are experiencing some issues which seem to be caused by
> phantomjs, so we are considering to change the default browser from
> phantomjs to headless chrome.
> 
> Do you have some objections why not to do so?
> 
> [1]
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From mhajas at redhat.com  Thu May 23 02:49:31 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Thu, 23 May 2019 08:49:31 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <20190522174607.GC5458@abstractj.org>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
Message-ID: <CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>

I created an issue [1] and I will start to work on making it work on Travis.

[1] https://issues.jboss.org/browse/KEYCLOAK-10359

On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org> wrote:

> Hi Michal, I'm not against changing the browser used for testing, as
> long as we keep Travis happy, like Va?ek mentioned.
>
> Before we make this decision, I suggest to first isolate the tests and
> give it a try with some headless browser (maybe chrome-headless). After
> that, we can decide whether or not we should drop phantomjs.
>
> On 2019-05-22, Michal Hajas wrote:
> > Hi all,
> >
> > currently, we are using phantomjs browser for running Node.js tests [1].
> > However, we are experiencing some issues which seem to be caused by
> > phantomjs, so we are considering to change the default browser from
> > phantomjs to headless chrome.
> >
> > Do you have some objections why not to do so?
> >
> > [1]
> >
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> > _______________________________________________
> > 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 May 23 03:48:06 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 May 2019 09:48:06 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
Message-ID: <CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>

+1 as long as chrome-headless works everywhere I'd rather see that as the
default and stop using phantom-js and htmlunit (or whatever it's called).
>From looking at this a looooong time ago I seem to remember chrome-headless
was faster than everything else.

On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com> wrote:

> I created an issue [1] and I will start to work on making it work on
> Travis.
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
>
> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > Hi Michal, I'm not against changing the browser used for testing, as
> > long as we keep Travis happy, like Va?ek mentioned.
> >
> > Before we make this decision, I suggest to first isolate the tests and
> > give it a try with some headless browser (maybe chrome-headless). After
> > that, we can decide whether or not we should drop phantomjs.
> >
> > On 2019-05-22, Michal Hajas wrote:
> > > Hi all,
> > >
> > > currently, we are using phantomjs browser for running Node.js tests
> [1].
> > > However, we are experiencing some issues which seem to be caused by
> > > phantomjs, so we are considering to change the default browser from
> > > phantomjs to headless chrome.
> > >
> > > Do you have some objections why not to do so?
> > >
> > > [1]
> > >
> >
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> >
> > abstractj
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Thu May 23 03:56:48 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 23 May 2019 09:56:48 +0200
Subject: [keycloak-dev] User Consents via Account REST API
In-Reply-To: <7cc300612a8f4ec7b71cf0fb7449f081@bosch-si.com>
References: <7cc300612a8f4ec7b71cf0fb7449f081@bosch-si.com>
Message-ID: <CAJgngAeHX2aSQfu6XSahhc2LRibygYVTSdHjLPrPj9EQLs95YA@mail.gmail.com>

I assume it's not the third party application that is installing the
plugins, but rather some internal user management application? Having a
third-party app being able to manage consents would obviously defeat the
whole purpose of consent.

I don't have any issue with adding endpoints to be able to manage
applications and the introduction of fine-grained roles. Fine-grained roles
should be added for everything though, not just consents. Also, the
applications endpoint does more than just manage consents it also manages
offline access to applications, so that needs to be considered.

Would be good with a design proposal around this, to continue the
discussion there rather than fragmented on the ML.

On Wed, 22 May 2019 at 17:02, Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi everybody (and probably especially Stan and Stian),
>
> In some of our projects we want to make heavy use of Keycloaks ability to
> obtain user consent to third parties to access user data in our APIs.
> In one project, the third parties provide modules that plug into our app
> and the user should give his consent for this plugin at plugin installation
> time.
> We plan to have one client for every plugin so the user can for every
> plugin decide which scope of backend API access it wants to grant to the
> plugin.
> I would be cool if asking for consent would be possible from the app in
> its UI at the point when the user installs the plugin.
>
> To do that, we would like to extend the account REST Api that?s currently
> in preview state so it
>
> a)    covers the ?applications? functionality (this is currently a TODO)
>
> b)    allows to create consents using the REST Api. I am well aware there
> might be security implications here for clients that are essentially
> public, e.g. a rogue app could manage consents of a user if he does not pay
> attention.
>
> c)     use a finer-grained role model for the accounts service, e.g. at
> least splitting up view-account into view-profile+view-consents and
> manage-account into manage-profile+manage-consents so we can control which
> clients may invoke the consents functionality or we can prevent changing
> profile attributes
> that come from an external IDP in our case.
>
> What do you think about these changes/additions? Do they make sense? If
> yes, we would like to contribute them.
>
> Thanks and best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing. Sebastian Schuster
>
> Open Source Services (INST-CSS/BSV-OS2)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com<http://www.bosch-si.com>
> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | 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
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.
> Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bruno at abstractj.org  Thu May 23 09:16:32 2019
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 May 2019 10:16:32 -0300
Subject: [keycloak-dev] jdk7 for tomcat modules
In-Reply-To: <649fb747-8c55-0049-d8a6-c81e04637206@redhat.com>
References: <649fb747-8c55-0049-d8a6-c81e04637206@redhat.com>
Message-ID: <20190523131632.GE5458@abstractj.org>

No objections from me. 

+1

On 2019-05-21, Vlasta Ramik wrote:
> Hey guys,
> 
> I'm working on https://issues.jboss.org/browse/KEYCLOAK-9596 Remove 
> Apache Tomcat 6.0.x adapter, as a side affect I plan to update jdk 
> version for compiler from 1.6 to 1.7 for all modules related to tomcat 
> adapter. Does anyone have any objections?
> 
> Thanks,
> 
> V.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 

abstractj

From chris.smith at cmfirstgroup.com  Thu May 23 18:13:04 2019
From: chris.smith at cmfirstgroup.com (Chris Smith)
Date: Thu, 23 May 2019 22:13:04 +0000
Subject: [keycloak-dev] Adding a Kerberos ticket as a Claim (not SPNEGO)
Message-ID: <CY4PR22MB02480AA014B611D2426A54D498010@CY4PR22MB0248.namprd22.prod.outlook.com>

I can get the Kerberos ticket I need when the KerberosUsernamePasswordAuthenticator performs a User/Password validation.
I have validated that the ticket can be used for IBM EIM(Enterprise Identity Mapping)

                public Subject authenticateSubject(String username, String password) throws LoginException {
                                String principal = getKerberosPrincipal(username);

                                logger.debug("Validating password of principal: " + principal);
                                loginContext = new LoginContext("does-not-matter", null, createJaasCallbackHandler(principal, password),
                                                                createJaasConfiguration());

                                loginContext.login();
                                logger.debug("Principal " + principal + " authenticated succesfully");
                                Subject subject = loginContext.getSubject();
                                serializeKerberosTicket(subject);
                                return subject;
                }

                private void serializeKerberosTicket(Subject subject) {
                                Optional<KerberosTicket> kerbTicket = subject.getPrivateCredentials(KerberosTicket.class).stream().findFirst();
                                if (kerbTicket.isPresent()) {
                                                try {
                                                                ByteArrayOutputStream bos = new ByteArrayOutputStream();
                                                                ObjectOutputStream oos = new ObjectOutputStream(bos);
                                                                oos.writeObject(kerbTicket.get());
                                                                String serializedKerberosTicket = Base64.encodeBytes(bos.toByteArray());
                                                                // TODO add as a claim
                                                } catch (IOException e) {
                                                                logger.debug("Kerberos Ticket Serialize failed", e);
                                                }
                                } else {
                                                logger.debug("Kerberos Ticket was not found in Subject");
                                }
                }

I tried to follow the SPNEGOAuthenticator but I got lost.
Is there an easy place to put the String serializedKerberosTicket so it will be added as a claim?

From Sebastian.Schuster at bosch-si.com  Fri May 24 09:39:07 2019
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST-CSS/BSV-OS2))
Date: Fri, 24 May 2019 13:39:07 +0000
Subject: [keycloak-dev] User Consents via Account REST API
In-Reply-To: <CAJgngAeHX2aSQfu6XSahhc2LRibygYVTSdHjLPrPj9EQLs95YA@mail.gmail.com>
References: <7cc300612a8f4ec7b71cf0fb7449f081@bosch-si.com>
	<CAJgngAeHX2aSQfu6XSahhc2LRibygYVTSdHjLPrPj9EQLs95YA@mail.gmail.com>
Message-ID: <e0d9bea9e39d428f98727e5e6b78e19e@bosch-si.com>

Will do!

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | 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
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic



Von: Stian Thorgersen <sthorger at redhat.com>
Gesendet: Donnerstag, 23. Mai 2019 09:57
An: Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster at bosch-si.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>; Lanzendoerfer Jonas (AE-EB/ICO2) <Jonas.Lanzendoerfer at de.bosch.com>
Betreff: Re: [keycloak-dev] User Consents via Account REST API

I assume it's not the third party application that is installing the plugins, but rather some internal user management application? Having a third-party app being able to manage consents would obviously defeat the whole purpose of consent.

I don't have any issue with adding endpoints to be able to manage applications and the introduction of fine-grained roles. Fine-grained roles should be added for everything though, not just consents. Also, the applications endpoint does more than just manage consents it also manages offline access to applications, so that needs to be considered.

Would be good with a design proposal around this, to continue the discussion there rather than fragmented on the ML.

On Wed, 22 May 2019 at 17:02, Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>> wrote:
Hi everybody (and probably especially Stan and Stian),

In some of our projects we want to make heavy use of Keycloaks ability to obtain user consent to third parties to access user data in our APIs.
In one project, the third parties provide modules that plug into our app and the user should give his consent for this plugin at plugin installation time.
We plan to have one client for every plugin so the user can for every plugin decide which scope of backend API access it wants to grant to the plugin.
I would be cool if asking for consent would be possible from the app in its UI at the point when the user installs the plugin.

To do that, we would like to extend the account REST Api that?s currently in preview state so it

a)    covers the ?applications? functionality (this is currently a TODO)

b)    allows to create consents using the REST Api. I am well aware there might be security implications here for clients that are essentially public, e.g. a rogue app could manage consents of a user if he does not pay attention.

c)     use a finer-grained role model for the accounts service, e.g. at least splitting up view-account into view-profile+view-consents and manage-account into manage-profile+manage-consents so we can control which clients may invoke the consents functionality or we can prevent changing profile attributes
that come from an external IDP in our case.

What do you think about these changes/additions? Do they make sense? If yes, we would like to contribute them.

Thanks and best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com><mailto:Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic



_______________________________________________
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 marc.ewert at leverton.ai  Fri May 24 09:51:46 2019
From: marc.ewert at leverton.ai (Marc Ewert)
Date: Fri, 24 May 2019 13:51:46 +0000
Subject: [keycloak-dev] Providing idpHint in JavaScript Adapter JSON
 configuration
In-Reply-To: <CAJgngAeK5=qisbsrnv5t4kRLk7RSGVJOA0PcowrHzaGBa0-u1Q@mail.gmail.com>
References: <1feb1baf-a648-fc46-3bbf-cf77cfe73f52@leverton.ai>
	<CAJgngAeK5=qisbsrnv5t4kRLk7RSGVJOA0PcowrHzaGBa0-u1Q@mail.gmail.com>
Message-ID: <18fa22e3-4bf6-6b30-2da3-3065c51de190@leverton.ai>

That would also be a solution, which would allow us to tell the JavaScript Adapter the idpHint.

One benefit of the "JSON approach" compared to that would be, that there are no changes in the actual frontend clients needed. This can be achieved by just adding:

kc.idpHint = config['idp-hint'];

to the loadConfig() function in keycloak.js.

In the moment the configuration JSON contains for example the auth-server-url and the realm. At least for us the idp-hint is related to the auth-server-url, because each external party gets its own domain. For others I could imagine, that each external party gets its dedicated realm. In both cases it would be very comfortable, if we could provide the information just right in the JSON.

Otherwise the frontends has to duplicate the needed code for that decisions.

What do you think?

Best and thanks

Marc Ewert


Am 21.05.19 um 15:50 schrieb Stian Thorgersen:
I'm not too keen on adding little bits like this to keycloak.json on its own. Today we have the config split between keycloak.json and init. I'd be open to allow configuring what you can through init in Keycloak.json, but would have to be a complete pr with docs and tests.

On Tue, 21 May 2019, 14:37 Marc Ewert, <marc.ewert at leverton.ai<mailto:marc.ewert at leverton.ai>> wrote:
Hi,

we would like to create a very small PR for the JavaScript Adapter (keycloak.js).  This change would allow one to provide the idpHint via the JSON configuration which could of course then be dynamically served by a backend. By this everyone could generate a JSON of the following format:

{
  realm: "production",
  auth-server-url: "https://customer-a.example.com/auth"<https://customer-a.example.com/auth>,
  bearer-only: false,
  resource: "frontend-client",
  idp-hint: "customer-a",
}

The consumption of the idp-hint parameter could be done as an one-liner in keycloak.js. Would it be okay, if we create a PR with the needed change for letting that happen, or are there other as simple solutions, that we are missing?

Best

Marc Ewert

--
________________________________________________
Marc Ewert | Senior Engineering Manager
Leverton GmbH | Sch?neberger Str. 15 | 10963 Berlin | Germany
P +49 30 868 711 059
E marc.ewert at leverton.ai<mailto:marc.ewert at leverton.ai><mailto:marc.ewert at leverton.ai<mailto:marc.ewert at leverton.ai>>
https://www.leverton.ai/ | LinkedIn<https://www.linkedin.com/company/leverton>

District Court Berlin-Charlottenburg HRB 140028
Managing Directors: Florian Kuhlmann, Abhinav Somani
_______________________________________________
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
--
________________________________________________
Marc Ewert | Senior Engineering Manager
Leverton GmbH | Sch?neberger Str. 15 | 10963 Berlin | Germany
P +49 30 868 711 059
E marc.ewert at leverton.ai<mailto:marc.ewert at leverton.ai>
https://www.leverton.ai/ | LinkedIn<https://www.linkedin.com/company/leverton>

District Court Berlin-Charlottenburg HRB 140028
Managing Directors: Florian Kuhlmann, Abhinav Somani

From Daniel.Bowen at exciteit.com.au  Sun May 26 19:48:19 2019
From: Daniel.Bowen at exciteit.com.au (Bowen, Daniel (Excite))
Date: Sun, 26 May 2019 23:48:19 +0000
Subject: [keycloak-dev] Keycloak Demo
In-Reply-To: <60b29e1f6d9848e39b2d44a74c2a6617@EIT12EX01.exciteit.local>
References: <60b29e1f6d9848e39b2d44a74c2a6617@EIT12EX01.exciteit.local>
Message-ID: <d374e0c43e2146a5baac36c3fa1b5bc5@EIT12EX01.exciteit.local>

Hello,

We have a customer who would like to implement redhat keycloak single sign on authentication system, however they would to evaluate the following functionalities

*            Demo functionality of  RedHat KeyCloak single sign-on authentication system.
*            How to define a role for each user and enrol users to the security policies inside KeyCloak
*            How users are able to use nominated application using the KeyCloak deployed security policies.

Unfortunately we don't have the skills and are seeking out for someone to help us demonstrate this. We are based out of Sydney and are willing to pay for the services.
We have already setup the server and installed the application however it is not yet linked to any services to demonstrate it's functionality.
We will appreciate if someone form the community can assist us with this request.

Thank you,

Daniel Bowen| Service Desk Support Engineer
[cid:image003.jpg at 01CF6EA1.EE2C3BA0][cid:image008.png at 01D33C4C.E5E92800]

Excite IT Pty Ltd | www.exciteit.com.au<http://www.exciteit.com.au/>
75C Carnarvon Street, Silverwater NSW 2128 Australia
Phone: 1300 666 708
Email: daniel.bowen at exciteit.com.au<mailto:daniel.bowen at exciteit.com.au>

[facebook-transparent-logo-png-0 rrrr]<https://www.facebook.com/exciteitaus/>     [LinkedIn_Logodgfdsf] <https://www.linkedin.com/company/excite-it>    [in] <https://www.instagram.com/excite_it/>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6380 bytes
Desc: image001.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190526/d7af0df7/attachment-0002.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 10838 bytes
Desc: image002.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190526/d7af0df7/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 683 bytes
Desc: image003.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190526/d7af0df7/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 2539 bytes
Desc: image004.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190526/d7af0df7/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 898 bytes
Desc: image005.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20190526/d7af0df7/attachment-0003.jpg 

From mhajas at redhat.com  Mon May 27 04:09:24 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Mon, 27 May 2019 10:09:24 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
	<CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
Message-ID: <CACv4bCSd2GufZhdPp-537=LOjXjxCDYnC17UU2c3fjTta-NwCg@mail.gmail.com>

I agree. I sent PR to Node.js adapter already and I created a SPIKE [1] for
investigation which browser would be the best for replacing Phantomjs for
Java Arquillian testsuite. Feel free to comment or update.

Michal

[1] https://issues.jboss.org/browse/KEYCLOAK-10392

On Thu, May 23, 2019 at 9:48 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> +1 as long as chrome-headless works everywhere I'd rather see that as the
> default and stop using phantom-js and htmlunit (or whatever it's called).
> From looking at this a looooong time ago I seem to remember chrome-headless
> was faster than everything else.
>
> On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com> wrote:
>
>> I created an issue [1] and I will start to work on making it work on
>> Travis.
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
>>
>> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>> > Hi Michal, I'm not against changing the browser used for testing, as
>> > long as we keep Travis happy, like Va?ek mentioned.
>> >
>> > Before we make this decision, I suggest to first isolate the tests and
>> > give it a try with some headless browser (maybe chrome-headless). After
>> > that, we can decide whether or not we should drop phantomjs.
>> >
>> > On 2019-05-22, Michal Hajas wrote:
>> > > Hi all,
>> > >
>> > > currently, we are using phantomjs browser for running Node.js tests
>> [1].
>> > > However, we are experiencing some issues which seem to be caused by
>> > > phantomjs, so we are considering to change the default browser from
>> > > phantomjs to headless chrome.
>> > >
>> > > Do you have some objections why not to do so?
>> > >
>> > > [1]
>> > >
>> >
>> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
>> > > _______________________________________________
>> > > 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 ieugen at netdava.com  Mon May 27 04:24:52 2019
From: ieugen at netdava.com (Eugen Stan)
Date: Mon, 27 May 2019 11:24:52 +0300
Subject: [keycloak-dev] jdk7 for tomcat modules
In-Reply-To: <20190523131632.GE5458@abstractj.org>
References: <649fb747-8c55-0049-d8a6-c81e04637206@redhat.com>
	<20190523131632.GE5458@abstractj.org>
Message-ID: <a39841e9-31cd-e8fe-6b71-f4eca507cb0b@netdava.com>

+1.

La 23.05.2019 16:16, Bruno Oliveira a scris:
> No objections from me. 
>
> +1
>
> On 2019-05-21, Vlasta Ramik wrote:
>> Hey guys,
>>
>> I'm working on https://issues.jboss.org/browse/KEYCLOAK-9596 Remove 
>> Apache Tomcat 6.0.x adapter, as a side affect I plan to update jdk 
>> version for compiler from 1.6 to 1.7 for all modules related to tomcat 
>> adapter. Does anyone have any objections?
>>
>> Thanks,
>>
>> V.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Mon May 27 05:08:45 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 May 2019 11:08:45 +0200
Subject: [keycloak-dev] Keycloak Demo
In-Reply-To: <d374e0c43e2146a5baac36c3fa1b5bc5@EIT12EX01.exciteit.local>
References: <60b29e1f6d9848e39b2d44a74c2a6617@EIT12EX01.exciteit.local>
	<d374e0c43e2146a5baac36c3fa1b5bc5@EIT12EX01.exciteit.local>
Message-ID: <CAJgngAdjda-FKRwokMAxrdMs2UjTiYAb4Hz88vCoS81nKXZJ4Q@mail.gmail.com>

If you don't have the knowledge around Keycloak yourself I would suggest
contacting Red Hat sales to get your customer on the supported version of
Keycloak. Sales can also help with pre-sales with your customer.

By the way this mailing list is reserved for discussions related to
development of Keycloak, in the future please use the user mailing list for
questions like these.

On Mon, 27 May 2019 at 01:50, Bowen, Daniel (Excite) <
Daniel.Bowen at exciteit.com.au> wrote:

> Hello,
>
> We have a customer who would like to implement redhat keycloak single sign
> on authentication system, however they would to evaluate the following
> functionalities
>
> *            Demo functionality of  RedHat KeyCloak single sign-on
> authentication system.
> *            How to define a role for each user and enrol users to the
> security policies inside KeyCloak
> *            How users are able to use nominated application using the
> KeyCloak deployed security policies.
>
> Unfortunately we don't have the skills and are seeking out for someone to
> help us demonstrate this. We are based out of Sydney and are willing to pay
> for the services.
> We have already setup the server and installed the application however it
> is not yet linked to any services to demonstrate it's functionality.
> We will appreciate if someone form the community can assist us with this
> request.
>
> Thank you,
>
> Daniel Bowen| Service Desk Support Engineer
> [cid:image003.jpg at 01CF6EA1.EE2C3BA0][cid:image008.png at 01D33C4C.E5E92800]
>
> Excite IT Pty Ltd | www.exciteit.com.au<http://www.exciteit.com.au/>
> 75C Carnarvon Street, Silverwater NSW 2128 Australia
> Phone: 1300 666 708
> Email: daniel.bowen at exciteit.com.au<mailto:daniel.bowen at exciteit.com.au>
>
> [facebook-transparent-logo-png-0 rrrr]<
> https://www.facebook.com/exciteitaus/>     [LinkedIn_Logodgfdsf] <
> https://www.linkedin.com/company/excite-it>    [in] <
> https://www.instagram.com/excite_it/>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From vramik at redhat.com  Mon May 27 07:05:21 2019
From: vramik at redhat.com (Vlasta Ramik)
Date: Mon, 27 May 2019 13:05:21 +0200
Subject: [keycloak-dev] [keycloak-team] tomcat adapter
In-Reply-To: <CAJgngAd0dXotbMvd9oKGkQJxWJzAszLg5gxgFDRwdu_wxuP1aA@mail.gmail.com>
References: <d6cf56cf-f409-3866-8326-dc89a2ecffb5@redhat.com>
	<CAJgngAd0dXotbMvd9oKGkQJxWJzAszLg5gxgFDRwdu_wxuP1aA@mail.gmail.com>
Message-ID: <0ddaae40-a37d-f14b-fabd-27e54f954c1e@redhat.com>

On 5/27/19 1:04 PM, Stian Thorgersen wrote:
> Vlasta - can you send this to Keycloak dev as well please?
>
> On Mon, 27 May 2019 at 12:38, Vlasta Ramik <vramik at redhat.com 
> <mailto:vramik at redhat.com>> wrote:
>
>     Hey guys,
>
>     I'm currently working on KEYCLOAK-9598 Apache Tomcat 9.0.x
>     adapter. Adapter for tomcat8 works fine on tomcat9, it's currently
>     tested in pipeline. But in my opinion it's a bit strange install
>     something called tomca8-adapter to tomcat9 application server.
>
>     I can see several ways how to solve this.
>
>       * remove the specific version from the package and have common
>         tomcat-adapter and specific tomcat7-adapter, where
>         tomcat-adapter would be used for both tomcat8 and tomcat9,
>         this approach is the same what we have with Wildfly
>
> +1
>
>      *
>
>
>       * create a note in documentation that tomcat8 adapter is meant
>         to be used with tomcat9, but I don't like this option
>       * repackage the tomcat8 adapter:
>         https://github.com/keycloak/keycloak/pull/6068/files
>
>     WDYT?
>
>     V.
>

From sthorger at redhat.com  Mon May 27 07:24:46 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 May 2019 13:24:46 +0200
Subject: [keycloak-dev] Secure Credentials Store
Message-ID: <CAJgngAfAzA9m-7-XzU8Xpwq0YkfpHycc3suEiaVTGpG0oGerLQ@mail.gmail.com>

Currently we recommend encrypting credentials at the database layer, but
this is not well documented. It is also not a trivial thing to achieve and
may have performance implications.

With that in mind we are planning to introduce a secure credentials store.
It's very early days, but one thing is certain and that is we will
introduce a Vault SPI to allow plug-ability.

To join the discussion read the initial notes around the subject here
https://github.com/keycloak/keycloak-community/blob/master/design/secure-credentials-store.md

From rmartinc at redhat.com  Mon May 27 08:48:30 2019
From: rmartinc at redhat.com (Ricardo Martin Camarero)
Date: Mon, 27 May 2019 14:48:30 +0200
Subject: [keycloak-dev] Secure Credentials Store
In-Reply-To: <CAJgngAfAzA9m-7-XzU8Xpwq0YkfpHycc3suEiaVTGpG0oGerLQ@mail.gmail.com>
References: <CAJgngAfAzA9m-7-XzU8Xpwq0YkfpHycc3suEiaVTGpG0oGerLQ@mail.gmail.com>
Message-ID: <212a93ac-936f-d799-bba0-e4e81c65111e@redhat.com>

Hi Stian,

Remember that in EAP 7.1+ there is a new credential-store, vault is
considered legacy [1]. Think about using the credential-store API
instead of the vault.

Regards.


[1]
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.2/html-single/migration_guide/index#migrate_secure_vaults_and_properties


On 5/27/19 1:24 PM, Stian Thorgersen wrote:
> Currently we recommend encrypting credentials at the database layer, but
> this is not well documented. It is also not a trivial thing to achieve and
> may have performance implications.
> 
> With that in mind we are planning to introduce a secure credentials store.
> It's very early days, but one thing is certain and that is we will
> introduce a Vault SPI to allow plug-ability.
> 
> To join the discussion read the initial notes around the subject here
> https://github.com/keycloak/keycloak-community/blob/master/design/secure-credentials-store.md
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From sthorger at redhat.com  Mon May 27 09:38:47 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 May 2019 15:38:47 +0200
Subject: [keycloak-dev] Secure Credentials Store
In-Reply-To: <212a93ac-936f-d799-bba0-e4e81c65111e@redhat.com>
References: <CAJgngAfAzA9m-7-XzU8Xpwq0YkfpHycc3suEiaVTGpG0oGerLQ@mail.gmail.com>
	<212a93ac-936f-d799-bba0-e4e81c65111e@redhat.com>
Message-ID: <CAJgngAe7yB5jrQRCdGH1AAqctKbCwig2X--JnxB=ytruwCk3mQ@mail.gmail.com>

The Vault SPI we provide will be a Keycloak specific API and will not have
anything to do with APIs provided by EAP. We may provide a provider that
integrates with EAP credential-store, but that is also probably unlikely
due to most likely moving away from EAP in the future we don't want to tie
to much to the underlying container.

On Mon, 27 May 2019 at 14:48, Ricardo Martin Camarero <rmartinc at redhat.com>
wrote:

> Hi Stian,
>
> Remember that in EAP 7.1+ there is a new credential-store, vault is
> considered legacy [1]. Think about using the credential-store API
> instead of the vault.
>
> Regards.
>
>
> [1]
>
> https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.2/html-single/migration_guide/index#migrate_secure_vaults_and_properties
>
>
> On 5/27/19 1:24 PM, Stian Thorgersen wrote:
> > Currently we recommend encrypting credentials at the database layer, but
> > this is not well documented. It is also not a trivial thing to achieve
> and
> > may have performance implications.
> >
> > With that in mind we are planning to introduce a secure credentials
> store.
> > It's very early days, but one thing is certain and that is we will
> > introduce a Vault SPI to allow plug-ability.
> >
> > To join the discussion read the initial notes around the subject here
> >
> https://github.com/keycloak/keycloak-community/blob/master/design/secure-credentials-store.md
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>

From hmlnarik at redhat.com  Mon May 27 10:43:31 2019
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 27 May 2019 16:43:31 +0200
Subject: [keycloak-dev] [keycloak-team] tomcat adapter
In-Reply-To: <0ddaae40-a37d-f14b-fabd-27e54f954c1e@redhat.com>
References: <d6cf56cf-f409-3866-8326-dc89a2ecffb5@redhat.com>
	<CAJgngAd0dXotbMvd9oKGkQJxWJzAszLg5gxgFDRwdu_wxuP1aA@mail.gmail.com>
	<0ddaae40-a37d-f14b-fabd-27e54f954c1e@redhat.com>
Message-ID: <CAMvXD=FBUe=dCqMQ1TFz=4TXts=gwwHiRSf=osSOULiJSXYNeQ@mail.gmail.com>

On Mon, May 27, 2019 at 1:12 PM Vlasta Ramik <vramik at redhat.com> wrote:

> On 5/27/19 1:04 PM, Stian Thorgersen wrote:
> > Vlasta - can you send this to Keycloak dev as well please?
> >
> > On Mon, 27 May 2019 at 12:38, Vlasta Ramik <vramik at redhat.com
> > <mailto:vramik at redhat.com>> wrote:
> >
> >     Hey guys,
> >
> >     I'm currently working on KEYCLOAK-9598 Apache Tomcat 9.0.x
> >     adapter. Adapter for tomcat8 works fine on tomcat9, it's currently
> >     tested in pipeline. But in my opinion it's a bit strange install
> >     something called tomca8-adapter to tomcat9 application server.
> >
> >     I can see several ways how to solve this.
> >
> >       * remove the specific version from the package and have common
> >         tomcat-adapter and specific tomcat7-adapter, where
> >         tomcat-adapter would be used for both tomcat8 and tomcat9,
> >         this approach is the same what we have with Wildfly
> >
> > +1
>

+1


> >
> >       * create a note in documentation that tomcat8 adapter is meant
> >         to be used with tomcat9, but I don't like this option
> >       * repackage the tomcat8 adapter:
> >         https://github.com/keycloak/keycloak/pull/6068/files
> >
> >     WDYT?
> >
> >     V.
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Mon May 27 15:50:20 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 27 May 2019 21:50:20 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
 Phantomjs
In-Reply-To: <CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
	<CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
Message-ID: <071180ff-d8fe-d39d-d504-ddbf660b2a2d@redhat.com>

On 23/05/2019 09:48, Stian Thorgersen wrote:
> +1 as long as chrome-headless works everywhere I'd rather see that as the
> default and stop using phantom-js and htmlunit (or whatever it's called).
>  From looking at this a looooong time ago I seem to remember chrome-headless
> was faster than everything else.

I think? this is not the case when comparing to HtmlUnit.

HtmlUnit was far faster than other browsers due the fact that it's just 
wrapper over apache HTTP client. All the other web driver 
implementations are subclass of RemoteWebDriver and they use remote 
selenium server as another layer when communicating with the browser. 
This adds the most of the overhead as there is much more network 
communications here and there.

By using the HtmlUnit instead of phantomJS as default browser, the 
testsuite was made 2 times faster. AFAIR there wasn't any subtle 
difference between PhantomJS and other "real" browser WebDriver 
implementations as all just use selenium server. At least that was the 
case few years ago when I was looking at it.

The thing is, that HtmlUnit has quite bad javascript support, which can 
be an issue once we have new Account console and maybe some more 
javascript support in our authenticators.

Marek

>
> On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com> wrote:
>
>> I created an issue [1] and I will start to work on making it work on
>> Travis.
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
>>
>> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>>> Hi Michal, I'm not against changing the browser used for testing, as
>>> long as we keep Travis happy, like Va?ek mentioned.
>>>
>>> Before we make this decision, I suggest to first isolate the tests and
>>> give it a try with some headless browser (maybe chrome-headless). After
>>> that, we can decide whether or not we should drop phantomjs.
>>>
>>> On 2019-05-22, Michal Hajas wrote:
>>>> Hi all,
>>>>
>>>> currently, we are using phantomjs browser for running Node.js tests
>> [1].
>>>> However, we are experiencing some issues which seem to be caused by
>>>> phantomjs, so we are considering to change the default browser from
>>>> phantomjs to headless chrome.
>>>>
>>>> Do you have some objections why not to do so?
>>>>
>>>> [1]
>>>>
>> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
>>>> _______________________________________________
>>>> 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 sthorger at redhat.com  Tue May 28 03:14:12 2019
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 28 May 2019 09:14:12 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <071180ff-d8fe-d39d-d504-ddbf660b2a2d@redhat.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
	<CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
	<071180ff-d8fe-d39d-d504-ddbf660b2a2d@redhat.com>
Message-ID: <CAJgngAeosK9+-kK4Vc6UCjQSbhZUwvtrpXJ=YZGMAhd3rKc5zQ@mail.gmail.com>

The JS engine used in HtmlUnit is not very fast and also has other issues.

Perhaps the case is we should default to HtmlUnit when there is no JS
involved (login flows), and use Chrome Headless when there is JS involved
(account, admin, keycloak.js and node.js).

On Mon, 27 May 2019 at 21:50, Marek Posolda <mposolda at redhat.com> wrote:

> On 23/05/2019 09:48, Stian Thorgersen wrote:
> > +1 as long as chrome-headless works everywhere I'd rather see that as the
> > default and stop using phantom-js and htmlunit (or whatever it's called).
> >  From looking at this a looooong time ago I seem to remember
> chrome-headless
> > was faster than everything else.
>
> I think  this is not the case when comparing to HtmlUnit.
>
> HtmlUnit was far faster than other browsers due the fact that it's just
> wrapper over apache HTTP client. All the other web driver
> implementations are subclass of RemoteWebDriver and they use remote
> selenium server as another layer when communicating with the browser.
> This adds the most of the overhead as there is much more network
> communications here and there.
>
> By using the HtmlUnit instead of phantomJS as default browser, the
> testsuite was made 2 times faster. AFAIR there wasn't any subtle
> difference between PhantomJS and other "real" browser WebDriver
> implementations as all just use selenium server. At least that was the
> case few years ago when I was looking at it.
>
> The thing is, that HtmlUnit has quite bad javascript support, which can
> be an issue once we have new Account console and maybe some more
> javascript support in our authenticators.
>
> Marek
>
> >
> > On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com> wrote:
> >
> >> I created an issue [1] and I will start to work on making it work on
> >> Travis.
> >>
> >> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
> >>
> >> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org>
> >> wrote:
> >>
> >>> Hi Michal, I'm not against changing the browser used for testing, as
> >>> long as we keep Travis happy, like Va?ek mentioned.
> >>>
> >>> Before we make this decision, I suggest to first isolate the tests and
> >>> give it a try with some headless browser (maybe chrome-headless). After
> >>> that, we can decide whether or not we should drop phantomjs.
> >>>
> >>> On 2019-05-22, Michal Hajas wrote:
> >>>> Hi all,
> >>>>
> >>>> currently, we are using phantomjs browser for running Node.js tests
> >> [1].
> >>>> However, we are experiencing some issues which seem to be caused by
> >>>> phantomjs, so we are considering to change the default browser from
> >>>> phantomjs to headless chrome.
> >>>>
> >>>> Do you have some objections why not to do so?
> >>>>
> >>>> [1]
> >>>>
> >>
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> >>>> _______________________________________________
> >>>> 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 gvincent at redhat.com  Wed May 29 03:19:13 2019
From: gvincent at redhat.com (Guillaume Vincent)
Date: Wed, 29 May 2019 09:19:13 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <CAJgngAeosK9+-kK4Vc6UCjQSbhZUwvtrpXJ=YZGMAhd3rKc5zQ@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
	<CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
	<071180ff-d8fe-d39d-d504-ddbf660b2a2d@redhat.com>
	<CAJgngAeosK9+-kK4Vc6UCjQSbhZUwvtrpXJ=YZGMAhd3rKc5zQ@mail.gmail.com>
Message-ID: <CAJbDe2vcdSj1Q+XZ6poacDT2C=R4N_TLfi0fi6Ti0m9WYYzY1Q@mail.gmail.com>

Hello Michal,
you probably already see it but there is a section regarding chrome in the
travis doc
https://docs.travis-ci.com/user/gui-and-headless-browsers/#using-the-chrome-addon-in-the-headless-mode

If you are recording the test suite you will need a display server (xvfb
works great, also in the same doc)

Best

On Tue, May 28, 2019 at 9:15 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> The JS engine used in HtmlUnit is not very fast and also has other issues.
>
> Perhaps the case is we should default to HtmlUnit when there is no JS
> involved (login flows), and use Chrome Headless when there is JS involved
> (account, admin, keycloak.js and node.js).
>
> On Mon, 27 May 2019 at 21:50, Marek Posolda <mposolda at redhat.com> wrote:
>
> > On 23/05/2019 09:48, Stian Thorgersen wrote:
> > > +1 as long as chrome-headless works everywhere I'd rather see that as
> the
> > > default and stop using phantom-js and htmlunit (or whatever it's
> called).
> > >  From looking at this a looooong time ago I seem to remember
> > chrome-headless
> > > was faster than everything else.
> >
> > I think  this is not the case when comparing to HtmlUnit.
> >
> > HtmlUnit was far faster than other browsers due the fact that it's just
> > wrapper over apache HTTP client. All the other web driver
> > implementations are subclass of RemoteWebDriver and they use remote
> > selenium server as another layer when communicating with the browser.
> > This adds the most of the overhead as there is much more network
> > communications here and there.
> >
> > By using the HtmlUnit instead of phantomJS as default browser, the
> > testsuite was made 2 times faster. AFAIR there wasn't any subtle
> > difference between PhantomJS and other "real" browser WebDriver
> > implementations as all just use selenium server. At least that was the
> > case few years ago when I was looking at it.
> >
> > The thing is, that HtmlUnit has quite bad javascript support, which can
> > be an issue once we have new Account console and maybe some more
> > javascript support in our authenticators.
> >
> > Marek
> >
> > >
> > > On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com> wrote:
> > >
> > >> I created an issue [1] and I will start to work on making it work on
> > >> Travis.
> > >>
> > >> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
> > >>
> > >> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org>
> > >> wrote:
> > >>
> > >>> Hi Michal, I'm not against changing the browser used for testing, as
> > >>> long as we keep Travis happy, like Va?ek mentioned.
> > >>>
> > >>> Before we make this decision, I suggest to first isolate the tests
> and
> > >>> give it a try with some headless browser (maybe chrome-headless).
> After
> > >>> that, we can decide whether or not we should drop phantomjs.
> > >>>
> > >>> On 2019-05-22, Michal Hajas wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> currently, we are using phantomjs browser for running Node.js tests
> > >> [1].
> > >>>> However, we are experiencing some issues which seem to be caused by
> > >>>> phantomjs, so we are considering to change the default browser from
> > >>>> phantomjs to headless chrome.
> > >>>>
> > >>>> Do you have some objections why not to do so?
> > >>>>
> > >>>> [1]
> > >>>>
> > >>
> >
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> > >>>> _______________________________________________
> > >>>> 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
> >
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

Guillaume Vincent

Senior Software Engineer

Red Hat <https://www.redhat.com>
<https://www.redhat.com>

From mhajas at redhat.com  Wed May 29 03:42:04 2019
From: mhajas at redhat.com (Michal Hajas)
Date: Wed, 29 May 2019 09:42:04 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
	Phantomjs
In-Reply-To: <CAJbDe2vcdSj1Q+XZ6poacDT2C=R4N_TLfi0fi6Ti0m9WYYzY1Q@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
	<CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
	<071180ff-d8fe-d39d-d504-ddbf660b2a2d@redhat.com>
	<CAJgngAeosK9+-kK4Vc6UCjQSbhZUwvtrpXJ=YZGMAhd3rKc5zQ@mail.gmail.com>
	<CAJbDe2vcdSj1Q+XZ6poacDT2C=R4N_TLfi0fi6Ti0m9WYYzY1Q@mail.gmail.com>
Message-ID: <CACv4bCRtF3k1z28znH-e9fqj=ie88EZGznOFFspp_e63Xpwi3Q@mail.gmail.com>

Hi Guillaume,

thank you very much for the suggestion. At the moment we are not recording
our testsuite, so we do not need xvfb. However, it is good to know there is
a possibility of running a full browser in Travis.

On Wed, May 29, 2019 at 9:22 AM Guillaume Vincent <gvincent at redhat.com>
wrote:

> Hello Michal,
> you probably already see it but there is a section regarding chrome in the
> travis doc
>
> https://docs.travis-ci.com/user/gui-and-headless-browsers/#using-the-chrome-addon-in-the-headless-mode
>
> If you are recording the test suite you will need a display server (xvfb
> works great, also in the same doc)
>
> Best
>
> On Tue, May 28, 2019 at 9:15 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > The JS engine used in HtmlUnit is not very fast and also has other
> issues.
> >
> > Perhaps the case is we should default to HtmlUnit when there is no JS
> > involved (login flows), and use Chrome Headless when there is JS involved
> > (account, admin, keycloak.js and node.js).
> >
> > On Mon, 27 May 2019 at 21:50, Marek Posolda <mposolda at redhat.com> wrote:
> >
> > > On 23/05/2019 09:48, Stian Thorgersen wrote:
> > > > +1 as long as chrome-headless works everywhere I'd rather see that as
> > the
> > > > default and stop using phantom-js and htmlunit (or whatever it's
> > called).
> > > >  From looking at this a looooong time ago I seem to remember
> > > chrome-headless
> > > > was faster than everything else.
> > >
> > > I think  this is not the case when comparing to HtmlUnit.
> > >
> > > HtmlUnit was far faster than other browsers due the fact that it's just
> > > wrapper over apache HTTP client. All the other web driver
> > > implementations are subclass of RemoteWebDriver and they use remote
> > > selenium server as another layer when communicating with the browser.
> > > This adds the most of the overhead as there is much more network
> > > communications here and there.
> > >
> > > By using the HtmlUnit instead of phantomJS as default browser, the
> > > testsuite was made 2 times faster. AFAIR there wasn't any subtle
> > > difference between PhantomJS and other "real" browser WebDriver
> > > implementations as all just use selenium server. At least that was the
> > > case few years ago when I was looking at it.
> > >
> > > The thing is, that HtmlUnit has quite bad javascript support, which can
> > > be an issue once we have new Account console and maybe some more
> > > javascript support in our authenticators.
> > >
> > > Marek
> > >
> > > >
> > > > On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com>
> wrote:
> > > >
> > > >> I created an issue [1] and I will start to work on making it work on
> > > >> Travis.
> > > >>
> > > >> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
> > > >>
> > > >> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira <bruno at abstractj.org
> >
> > > >> wrote:
> > > >>
> > > >>> Hi Michal, I'm not against changing the browser used for testing,
> as
> > > >>> long as we keep Travis happy, like Va?ek mentioned.
> > > >>>
> > > >>> Before we make this decision, I suggest to first isolate the tests
> > and
> > > >>> give it a try with some headless browser (maybe chrome-headless).
> > After
> > > >>> that, we can decide whether or not we should drop phantomjs.
> > > >>>
> > > >>> On 2019-05-22, Michal Hajas wrote:
> > > >>>> Hi all,
> > > >>>>
> > > >>>> currently, we are using phantomjs browser for running Node.js
> tests
> > > >> [1].
> > > >>>> However, we are experiencing some issues which seem to be caused
> by
> > > >>>> phantomjs, so we are considering to change the default browser
> from
> > > >>>> phantomjs to headless chrome.
> > > >>>>
> > > >>>> Do you have some objections why not to do so?
> > > >>>>
> > > >>>> [1]
> > > >>>>
> > > >>
> > >
> >
> https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
> > > >>>> _______________________________________________
> > > >>>> 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
> > >
> > >
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
>
> Guillaume Vincent
>
> Senior Software Engineer
>
> Red Hat <https://www.redhat.com>
> <https://www.redhat.com>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Wed May 29 04:00:34 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 May 2019 10:00:34 +0200
Subject: [keycloak-dev] Running Node.js tests with Chrome instead of
 Phantomjs
In-Reply-To: <CAJgngAeosK9+-kK4Vc6UCjQSbhZUwvtrpXJ=YZGMAhd3rKc5zQ@mail.gmail.com>
References: <CACv4bCS55LxgQtsoR=tAu52J9j5iA_vvBjS8PjwyBHDQhKLG6A@mail.gmail.com>
	<20190522174607.GC5458@abstractj.org>
	<CACv4bCSJ7jgnbRz6hc+Z=hTxGB5MA+1pgkaTMNO0xMjF-krrSQ@mail.gmail.com>
	<CAJgngAeUgvzsbmWAnNnPzg3kXgjxyYKrcNubT6hX_OWORmgUjQ@mail.gmail.com>
	<071180ff-d8fe-d39d-d504-ddbf660b2a2d@redhat.com>
	<CAJgngAeosK9+-kK4Vc6UCjQSbhZUwvtrpXJ=YZGMAhd3rKc5zQ@mail.gmail.com>
Message-ID: <a2f1ec9f-72e9-fd60-206d-988f17a9ba79@redhat.com>

On 28/05/2019 09:14, Stian Thorgersen wrote:
> The JS engine used in HtmlUnit is not very fast and also has other 
> issues.
>
> Perhaps the case is we should default to HtmlUnit when there is no JS 
> involved (login flows), and use Chrome Headless when there is JS 
> involved (account, admin, keycloak.js and node.js).

+1

Marek

>
> On Mon, 27 May 2019 at 21:50, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 23/05/2019 09:48, Stian Thorgersen wrote:
>     > +1 as long as chrome-headless works everywhere I'd rather see
>     that as the
>     > default and stop using phantom-js and htmlunit (or whatever it's
>     called).
>     >? From looking at this a looooong time ago I seem to remember
>     chrome-headless
>     > was faster than everything else.
>
>     I think? this is not the case when comparing to HtmlUnit.
>
>     HtmlUnit was far faster than other browsers due the fact that it's
>     just
>     wrapper over apache HTTP client. All the other web driver
>     implementations are subclass of RemoteWebDriver and they use remote
>     selenium server as another layer when communicating with the browser.
>     This adds the most of the overhead as there is much more network
>     communications here and there.
>
>     By using the HtmlUnit instead of phantomJS as default browser, the
>     testsuite was made 2 times faster. AFAIR there wasn't any subtle
>     difference between PhantomJS and other "real" browser WebDriver
>     implementations as all just use selenium server. At least that was
>     the
>     case few years ago when I was looking at it.
>
>     The thing is, that HtmlUnit has quite bad javascript support,
>     which can
>     be an issue once we have new Account console and maybe some more
>     javascript support in our authenticators.
>
>     Marek
>
>     >
>     > On Thu, 23 May 2019 at 08:51, Michal Hajas <mhajas at redhat.com
>     <mailto:mhajas at redhat.com>> wrote:
>     >
>     >> I created an issue [1] and I will start to work on making it
>     work on
>     >> Travis.
>     >>
>     >> [1] https://issues.jboss.org/browse/KEYCLOAK-10359
>     >>
>     >> On Wed, May 22, 2019 at 7:46 PM Bruno Oliveira
>     <bruno at abstractj.org <mailto:bruno at abstractj.org>>
>     >> wrote:
>     >>
>     >>> Hi Michal, I'm not against changing the browser used for
>     testing, as
>     >>> long as we keep Travis happy, like Va?ek mentioned.
>     >>>
>     >>> Before we make this decision, I suggest to first isolate the
>     tests and
>     >>> give it a try with some headless browser (maybe
>     chrome-headless). After
>     >>> that, we can decide whether or not we should drop phantomjs.
>     >>>
>     >>> On 2019-05-22, Michal Hajas wrote:
>     >>>> Hi all,
>     >>>>
>     >>>> currently, we are using phantomjs browser for running Node.js
>     tests
>     >> [1].
>     >>>> However, we are experiencing some issues which seem to be
>     caused by
>     >>>> phantomjs, so we are considering to change the default
>     browser from
>     >>>> phantomjs to headless chrome.
>     >>>>
>     >>>> Do you have some objections why not to do so?
>     >>>>
>     >>>> [1]
>     >>>>
>     >>
>     https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/utils/webdriver.js#L25
>     >>>> _______________________________________________
>     >>>> 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
>     >>> --
>     >>>
>     >>> abstractj
>     >>>
>     >> _______________________________________________
>     >> keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From mposolda at redhat.com  Fri May 31 03:30:38 2019
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 31 May 2019 09:30:38 +0200
Subject: [keycloak-dev] Encrypted OIDC ID Tokens support and admin console
Message-ID: <16330b65-4097-65f6-8ebe-f663db5175c0@redhat.com>

We have PR for introducing encryption support for OIDC ID Tokens. See 
[1] and [2].

IMO The PR is great contribution and is quite complete. There is support 
for manage encryption keys through the REST API or through the OIDC 
client registration, which is probably sufficient for have the OIDC FAPI 
support happy. However one thing, which seems to be missing, is better 
admin console support for seeing and managing the encryption keys of the 
client.

Regarding the admin console, the PR just introduces 2 new options for 
the client for choosing the algorithms for encryption of ID Tokens.

For more details, admin console doesn't have support for "hardcode" the 
client encryption key/certificate. It has support for downloading the 
key from the client's JWKS URL, but the JWKS URL is configured on the 
bit strange place. Right now, it is configured under tab "Credentials", 
then you need to choose "Signed-JWT" and then you can configure the JWKS 
URL. This was OK, when only point of JWKS URL was used just for 
signed-jwt client authentication. But now with adding the encrypted ID 
tokens support, this is not very appropriate place IMO. For example if 
you want to use encrypted ID Tokens together with traditional client 
authentication based on clientId/clientSecret, you shouldn't be required 
to go to "Credentials -> Signed JWT Authenticator" at all.

So not sure, if we shoud do some small re-design of admin console now? 
For example, for SAML clients, there is tab "SAML Keys" where you can 
see/generate/import/export keys used for SAML. I can imagine something 
like that for OIDC clients too. We can introduce tab "OIDC Keys" or just 
"Keys" . That will allow to have switch "Use JWKS URL" and then 
configure JWKS URL (optional) or alternatively the client keys used for 
SIG and ENC, which will be required just if "Use JWKS URL" is OFF 
similarly like it is currently in the "Credentials -> Signed JWT". Then 
in the tab "Credentials -> Signed JWT", there will be just info that you 
need to configure JWKS URL or Signing key in the tab "Keys" - so no 
configuration options on this page. Similarly the tooltips for the new 
options for ID Token support will contain the tooltip, that you should 
configure JWKS URL or "hardcode" encryption key in the tab "Keys" .

The bonus point will be the possibility to view the keys downloaded from 
JWKS URL and the ability to invalidate the keys of the individual client 
from the cache (currently it's possible to invalidate just globally for 
the whole realm AFAIK).

TBH I am not sure whether to add admin console support in this PR or 
have the follow-up PR.

WDYT?

[1] https://issues.jboss.org/browse/KEYCLOAK-6768
[2] https://github.com/keycloak/keycloak/pull/5779

Marek


From ece8537 at upnet.gr  Fri May 31 05:06:19 2019
From: ece8537 at upnet.gr (Konstantinos Schoinas)
Date: Fri, 31 May 2019 12:06:19 +0300
Subject: [keycloak-dev] Nodejs-Adapter-Update
Message-ID: <ae01db52891f15d306c781a64ab1c0a8@upnet.gr>

Hi everyone,

I would like to discuss about an bug ( and a possible update ) in 
keycloak-connect Node-js Module.

At the moment when a user session is expired keycloak-connect will try 
to redirect the user in the login page ( A flow that is compltetly fine 
) .But when you perform an AJAX request with an expired session 
keycloak-connect doesn't handle
this AJAX request properly. When a session is invalidated 
keycloak-connect takes a set of actions in order to make the user to
re-login. The last function that is called in this flow is the 
forceLogin() function in the protect.js file.

The problem here is that AJAX request can't handle the redirection by 
its nature ( 302 HTTP Code).

I have already created a JIRA Ticket for this issue --> 
https://issues.jboss.org/browse/KEYCLOAK-10264

I have uploaded there some instructions & an example with code in order 
to reproduce this issue.

In addition i have made a workaround for this issue that i also have 
implemented in the code in JIRA. I would like to contribute my changes 
in the  keycloak-connect module to a feature version (if they get 
approved )  but i don't know the specific process i have to follow in 
order to submit my updates.

I would really appreciate if someone could take a look at this issue or 
either describe me a way for contributing to keycloak-connect repository 
with my updates.

Thanks for your time,

Konstantinos

From jeroen.ter.voorde at simacan.com  Fri May 31 05:36:52 2019
From: jeroen.ter.voorde at simacan.com (Jeroen ter Voorde)
Date: Fri, 31 May 2019 11:36:52 +0200
Subject: [keycloak-dev] Support for briefRepresentation on the group members
	endpoint
Message-ID: <CAJoYZT5hk9jZig2-m0V-GHrCxZbGG=9ejS7E33y8OnL3PLH4=g@mail.gmail.com>

Hi,

I added a PR to support the briefRepresentation parameter on the
groups/{id}/members endpoint. I hope this can be included in the 7.0
release.
The reason is is that i need to request the full member list for multiple
groups and returning the full representation is quite slow.

I could not find where to update the documentation. Is this autogenerated
from the annotations?

Issue: https://issues.jboss.org/browse/KEYCLOAK-10419

Thanks,
Jeroen