From marc.tempelmeier at flane.de  Sat Jul  1 08:29:09 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Sat, 1 Jul 2017 12:29:09 +0000
Subject: [keycloak-user] Sign out on account page
Message-ID: <382856b8a5954c7480a8fa9fcd992491@derzex2013.europe.flane.local>

Hi,

Just a short question, the Sign out on the account page, should that terminate the client sessions too or just log out from account page?

Best regards

Marc


From thomas at recloux.fr  Sat Jul  1 14:03:01 2017
From: thomas at recloux.fr (Thomas Recloux)
Date: Sat, 01 Jul 2017 20:03:01 +0200
Subject: [keycloak-user] Sign out on account page
In-Reply-To: <382856b8a5954c7480a8fa9fcd992491@derzex2013.europe.flane.local>
References: <382856b8a5954c7480a8fa9fcd992491@derzex2013.europe.flane.local>
Message-ID: <1498932181.1919657.1027538152.4C08F904@webmail.messagingengine.com>

On Sat, Jul 1, 2017, at 14:29, Marc Tempelmeier wrote:
> Hi,

Hi Marc,

> Just a short question, the Sign out on the account page, should that
> terminate the client sessions too or just log out from account page?

It's a global logout.

Thomas

From aswin88us at gmail.com  Sun Jul  2 12:47:37 2017
From: aswin88us at gmail.com (Karthik Jayaraman)
Date: Sun, 2 Jul 2017 09:47:37 -0700
Subject: [keycloak-user] Error when keycloak.js is bundled with application
	but not otherwise
Message-ID: <CAL41MesuTcTebVa+TDHs1yE0e=DXy_QwEaUBO-QBsB1uNWRnbA@mail.gmail.com>

Hi all,

I am having the following issue:

Scenario 1:

In my application index.html (bundled in a JAR file and deployed in Jetty),
I have the following code:

<script src="keycloak.js"></script>

<script>
    var keycloak = Keycloak(
    {
    "realm": "master",
    "clientId": "client1",
    "auth-server-url": "http://
<<keycloak-server-ip>>:<<keycloak-server-port>>/auth",
    "public-client": true
    });

    keycloak.init({
        onLoad: 'login-required'
    }).success(function () {
       alert("login success");
    });

</script>

And I have the following client configuration in Keycloak server

Client Protocol - openid-connect
Access Type - public
Standard Flow Enabled - ON
Implicit Flow Enabled - OFF
Direct Access Grants Enabled - ON
Authorization Enabled - OFF
Root URL -
Valid Redirect URIs - http://
<<myapplicationIP>>:<<myapplicationPort>>/admin/*
Base URL - http://<<myapplicationIP>>:<<myapplicationPort>>/admin
Admin URL -
Web Origins -

With this configuration, the first time when I hit
http://<<myapplicationIP>>:<<myapplicationPort>>/admin/
, I am getting redirected to http://
<<myapplicationIP>>:<<myapplicationPort>>/realms/master/protocol/openid-connect
/auth?client_id=client1&redirect_uri=http%3A%2F%2F<<myapplicationIP>>%3A<<myapplicationPort>>%2Fadmin%2F&state=c524eb6c-9245-4f82-87e9-e767dd733b0d&nonce=760809b5-b2d5-4c3e-9d76-40cd43bdef0d&response_mode=fragment&response_type=code&scope=openid

and I get 404 which is expected since keycloak is trying to redirect to
 http://<<myapplicationIP>>:<<myapplicationPort>>/realms/... which does not
exist in our application.

Scenario 2:

When I do the same thing as scenario 1 except the way keycloak.js is
loaded, everything works as expected.

<script src="http://
<<keycloakServerIP>>:<<keycloakServerPort>>/auth/js/keycloak.js"></script>

So, what is operationally different between bundling keycloak.js and
loading it at run time ?

- Karthik

From mitya at cargosoft.ru  Sun Jul  2 21:44:12 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 03 Jul 2017 04:44:12 +0300
Subject: [keycloak-user] ProviderFactory::postInit not called with hot
 deployment
In-Reply-To: <CAJgngAeaFzSynDZHhZr_Z03eDK7zEgs4qPsBmX9TLb36XatVJw@mail.gmail.com>
References: <1498613746.13078.1.camel@cargosoft.ru>
	<CAJgngAeaFzSynDZHhZr_Z03eDK7zEgs4qPsBmX9TLb36XatVJw@mail.gmail.com>
Message-ID: <1499046252.11005.1.camel@cargosoft.ru>

https://issues.jboss.org/browse/https://issues.jboss.org/browse/KEYCLOA
K-5131
https://github.com/keycloak/keycloak/pull/4282

> The PR fixes the bug, however, the ProviderFactory::postInit invoked
> this way will have limitations, e.g. won't be able to access
> java:comp?JNDI namespace; the other stuff like accessing the data
> model works?well nevertheless. This is because the code is executed
> in WildFly's?"MSC service thread", unlike application code that uses
> "ServerService?Thread Pool".
> 
> If we are to get rid of this limitation, I think there exists an
> approach that will by the way fix KEYCLOAK-5132 too. Let me know if
> this is topical, so we can discuss it further.

Dmitry

? Wed, 28/06/2017 ? 07:15 +0200, Stian Thorgersen ?????:
> Yep, seems like a bug
> 
> On 28 June 2017 at 03:35, Dmitry Telegin <mitya at cargosoft.ru> wrote:
> > Hi,
> > 
> > Seems like o.k.provider.ProviderFactory::postInit() is called only
> > upon
> > server startup, no matter which way the provider has been deployed,
> > as
> > a module or via the deployments dir. However, if the provider is
> > hot
> > (re)deployed on the running server, the method is not called.
> > (ProviderFactory::init() is called always, but it's insufficient
> > for
> > most init phase tasks since normally a KeycloakSessionFactory
> > instance
> > is required.)
> > 
> > Indeed, o.k.services.DefaultKeycloakSessionFactory::deploy()
> > doesn't
> > contain mentions of postInit, contrary to
> > DefaultKeycloakSessionFactory::init(). Seems like a bug to me, OK
> > to
> > file JIRA issue and PR?
> > 
> > Regards,
> > Dmitry
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > 
> 
> 

From mitya at cargosoft.ru  Sun Jul  2 21:50:03 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 03 Jul 2017 04:50:03 +0300
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <1498673904.3162.1.camel@cargosoft.ru>
References: <1498673904.3162.1.camel@cargosoft.ru>
Message-ID: <1499046603.11005.3.camel@cargosoft.ru>

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

Meanwhile I've found a workaround - just run a transaction in a new
thread. However, this should be a "managed thread" - see issue details
& comments for more info.

? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
> Hi,
> 
> (TL;DR) if a KeycloakTransaction is opened from
> ProviderFactory::postInit, sometimes the transaction is already
> active
> on the underlying
> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection, which leads
> to errors.
> 
> (full version) I think it's essential for the providers to be able to
> access realm data in postInit(). For that, a transaction is required;
> using KeycloakModelUtils.runJobInTransaction() is a convenient method
> to do that:
> 
> ????@Override
> ????public void postInit(KeycloakSessionFactory factory) {
> ????????KeycloakModelUtils.runJobInTransaction(factory,
> (KeycloakSession session) -> {
> ????????????List<RealmModel> realms = session.realms().getRealms();
> ????????????// do stuff
> ????????});
> ????}
> 
> When such a provider is deployed, in about half of cases Keycloak
> fails
> to start due to the following exception:
> 
> java.sql.SQLException: IJ031017: You cannot set autocommit during a
> managed transaction
> 
> (see full stacktrace here https://pastebin.com/ETtPqXQk)
> 
> I've managed to track it down to something that looks like
> transaction
> clash over a single instance of
> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection. What
> happens
> is that the two treads at the same time begin two
> KeycloakTransactions
> which end up with the same instance of LocalManagedConnection. The
> above exception results from the second begin() call.
> 
> There's a system property called "ironjacamar.jdbc.ignoreautocommit"
> that allows to ignore the situation, but I think it's dangerous
> because
> it doesn't eliminate the transaction clash, just suppresses the
> check.
> If I'm not mistaken, this began to happen around Keycloak 2.2.x,
> which
> coincides with the changes to Keycloak transaction management. That
> said, do I need now some additional transaction coordination with the
> rest of Keycloak, or is it a bug? If former, how do I do that? If
> latter, how do we fix it?
> 
> I hope we'll sort it out, since the ability to access the data at
> every
> phase of provider's lifecycle seems something fundamental to me.
> 
> Regards,
> Dmitry
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From sthorger at redhat.com  Sun Jul  2 23:14:05 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Jul 2017 05:14:05 +0200
Subject: [keycloak-user] Error when keycloak.js is bundled with
 application but not otherwise
In-Reply-To: <CAL41MesuTcTebVa+TDHs1yE0e=DXy_QwEaUBO-QBsB1uNWRnbA@mail.gmail.com>
References: <CAL41MesuTcTebVa+TDHs1yE0e=DXy_QwEaUBO-QBsB1uNWRnbA@mail.gmail.com>
Message-ID: <CAJgngAfXSQHP6y7K4OzgTzLrSgaoVBGB-cSM4xQgBhGSJcSqHQ@mail.gmail.com>

On 2 July 2017 at 18:47, Karthik Jayaraman <aswin88us at gmail.com> wrote:

> Hi all,
>
> I am having the following issue:
>
> Scenario 1:
>
> In my application index.html (bundled in a JAR file and deployed in Jetty),
> I have the following code:
>
> <script src="keycloak.js"></script>
>
> <script>
>     var keycloak = Keycloak(
>     {
>     "realm": "master",
>     "clientId": "client1",
>     "auth-server-url": "http://
> <<keycloak-server-ip>>:<<keycloak-server-port>>/auth",
>     "public-client": true
>     });
>

Check
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/javascript-adapter.html.
You should use 'url' instead of 'auth-server-url' when passing arguments
directly to constructor instead of using keycloak.json file.


>
>     keycloak.init({
>         onLoad: 'login-required'
>     }).success(function () {
>        alert("login success");
>     });
>
> </script>
>
> And I have the following client configuration in Keycloak server
>
> Client Protocol - openid-connect
> Access Type - public
> Standard Flow Enabled - ON
> Implicit Flow Enabled - OFF
> Direct Access Grants Enabled - ON
> Authorization Enabled - OFF
> Root URL -
> Valid Redirect URIs - http://
> <<myapplicationIP>>:<<myapplicationPort>>/admin/*
> Base URL - http://<<myapplicationIP>>:<<myapplicationPort>>/admin
> Admin URL -
> Web Origins -
>
> With this configuration, the first time when I hit
> http://<<myapplicationIP>>:<<myapplicationPort>>/admin/
> , I am getting redirected to http://
> <<myapplicationIP>>:<<myapplicationPort>>/realms/
> master/protocol/openid-connect
> /auth?client_id=client1&redirect_uri=http%3A%2F%2F<<myapplicationIP>>%3A<<
> myapplicationPort>>%2Fadmin%2F&state=c524eb6c-9245-4f82-
> 87e9-e767dd733b0d&nonce=760809b5-b2d5-4c3e-9d76-
> 40cd43bdef0d&response_mode=fragment&response_type=code&scope=openid
>
> and I get 404 which is expected since keycloak is trying to redirect to
>  http://<<myapplicationIP>>:<<myapplicationPort>>/realms/... which does
> not
> exist in our application.
>
> Scenario 2:
>
> When I do the same thing as scenario 1 except the way keycloak.js is
> loaded, everything works as expected.
>
> <script src="http://
> <<keycloakServerIP>>:<<keycloakServerPort>>/auth/js/keycloak.js"></script>
>
> So, what is operationally different between bundling keycloak.js and
> loading it at run time ?
>
> - Karthik
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From sthorger at redhat.com  Sun Jul  2 23:21:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Jul 2017 05:21:27 +0200
Subject: [keycloak-user] Review Chinese translations PR
Message-ID: <CAJgngAd9PriB560mgmgtDEd+dmamAra=UytRY4Qg_GyUGs82Rw@mail.gmail.com>

Can someone please review PR for Chinese translations?

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

From dcorbett at expedia.com  Mon Jul  3 00:32:39 2017
From: dcorbett at expedia.com (Dan Corbett)
Date: Mon, 3 Jul 2017 04:32:39 +0000
Subject: [keycloak-user] Infinispan JMX Cache Stats return zero?
Message-ID: <D57ADE08.42A3F%dcorbett@expedia.com>

We have a Keycloak 3.1.0 standalone cluster of 3 instances in docker.
I?m trying to get Infinispan distributed cache stats out (via JMX) for operational monitoring.

We are getting 0?s for all values on the cache metrics when we review.

We?ve set  <cache-container statistics-enabled="true? ? /> on all cache-managers in standalone xml.

Via JMX we set statisticsEnabled == true for ?jboss.infinispan:type=Cache,name="loginFailures(dist_sync)",manager="keycloak",component=ClusterCacheStats?.
(We do that programatically after startup ?)

Any tips or good info/docs on getting stats out for all the Keycloak distributed caches.
Any other options for getting cache metrics out?

Thanks!
Dan

From kullervo16 at gmail.com  Mon Jul  3 04:25:10 2017
From: kullervo16 at gmail.com (Jef Verelst)
Date: Mon, 3 Jul 2017 10:25:10 +0200
Subject: [keycloak-user] REST identity propagation
Message-ID: <CAKf1x6mCRMajpAcRivrxBVEYJ9oTVqD1o4JFEOvK9_J1gk1nuw@mail.gmail.com>

Hello,

I would like to present a usecase to you where we struggle a bit to see how
to implement it properly using keycloak... We are creating a solution where
we have some legacy components using X.509 and SAML to identify users in
our front-end applications. These applications now need to call some REST
services, and pass on the identity. Our front-end system would call the
REST service by presenting a token obtained via client credentials grant,
based on a signed JWT. This way, we can establish a circle of trust between
the front-end applications and the REST service. The REST service is
prepared to accept that the user is the one that our front-end applications
vow that he is.

Question is now : how do we transport this claim from the front-end to the
backend REST service? We have found an RFC in internet-draft status that
addresses this problem :
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-08. But since
this is not yet approved, I assume you do not support this yet.

One way of solving this problem is sending the identity of the user
out-of-band, in an HTTP header. This is however a bit of a pain, since then
we need to make the REST service aware that for certain users (our
frontends), the header needs to be interpreted. However, for other callers
(both machine and user), this HTTP header must not be interpreted (we do
not want a normal user adding this header and impersonating who he wants).
So we are moving the configuration of who may impersonate/delegate to the
business service... which is not great. Also, when we want to pass on the
token, we need to repeat/set the header as well, which means we could
potentially change the content... and the idea is that our front-end is
stating that this is the user, not that any intermediate service can alter
that.

So it would be nice to have this in the token, taking over a value set in
the initial signed JWT that we present to keycloak. Is this possible (I
cannot seem to find if you pass any of the token information on the user
session so that we could map this)? Furthermore, we would like to get some
control on that value... because we would like to be able to place
restrictions on who is impersonated (not every front-end has the same
audience, so we should be able to limit for which persons they are making
claims). Is this possible with the current extension points? If so, could
you give us a hint on which one(s) to use?

Thanks in advance.

Jef

From mposolda at redhat.com  Mon Jul  3 06:10:41 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 3 Jul 2017 12:10:41 +0200
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <1499046603.11005.3.camel@cargosoft.ru>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
Message-ID: <1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>

Hi,

I think it's not good to directly start transactions from postInit. 
Among the issues you mentioned, various initial steps (eg. migration 
from previous version, export/import) may not be yet finished at this 
stage. Probably you can either:
- Register listener for PostMigrationEvent in your postInit. See the 
testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/authentication/PushButtonAuthenticator.java 
for inspiration.
- Use the pattern with "lazyInit" like for example here 
https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java#L78 
, which is called 1st time before your provider is actually needed.

Maybe we can improve by provide more callback methods to 
ProviderFactory/Provider to avoid the lazyInit pattern directly in 
providers, but rather integrate it better with the Provider framework. 
But for now, I think that some of the workaround above should work for 
you IMO.

Marek

On 03/07/17 03:50, Dmitry Telegin wrote:
> https://issues.jboss.org/browse/KEYCLOAK-5132
>
> Meanwhile I've found a workaround - just run a transaction in a new
> thread. However, this should be a "managed thread" - see issue details
> & comments for more info.
>
> ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
>> Hi,
>>
>> (TL;DR) if a KeycloakTransaction is opened from
>> ProviderFactory::postInit, sometimes the transaction is already
>> active
>> on the underlying
>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection, which leads
>> to errors.
>>
>> (full version) I think it's essential for the providers to be able to
>> access realm data in postInit(). For that, a transaction is required;
>> using KeycloakModelUtils.runJobInTransaction() is a convenient method
>> to do that:
>>
>>      @Override
>>      public void postInit(KeycloakSessionFactory factory) {
>>          KeycloakModelUtils.runJobInTransaction(factory,
>> (KeycloakSession session) -> {
>>              List<RealmModel> realms = session.realms().getRealms();
>>              // do stuff
>>          });
>>      }
>>
>> When such a provider is deployed, in about half of cases Keycloak
>> fails
>> to start due to the following exception:
>>
>> java.sql.SQLException: IJ031017: You cannot set autocommit during a
>> managed transaction
>>
>> (see full stacktrace here https://pastebin.com/ETtPqXQk)
>>
>> I've managed to track it down to something that looks like
>> transaction
>> clash over a single instance of
>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection. What
>> happens
>> is that the two treads at the same time begin two
>> KeycloakTransactions
>> which end up with the same instance of LocalManagedConnection. The
>> above exception results from the second begin() call.
>>
>> There's a system property called "ironjacamar.jdbc.ignoreautocommit"
>> that allows to ignore the situation, but I think it's dangerous
>> because
>> it doesn't eliminate the transaction clash, just suppresses the
>> check.
>> If I'm not mistaken, this began to happen around Keycloak 2.2.x,
>> which
>> coincides with the changes to Keycloak transaction management. That
>> said, do I need now some additional transaction coordination with the
>> rest of Keycloak, or is it a bug? If former, how do I do that? If
>> latter, how do we fix it?
>>
>> I hope we'll sort it out, since the ability to access the data at
>> every
>> phase of provider's lifecycle seems something fundamental to me.
>>
>> Regards,
>> Dmitry
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mitya at cargosoft.ru  Mon Jul  3 07:01:01 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 03 Jul 2017 14:01:01 +0300
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
	<1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
Message-ID: <1499079661.2825.2.camel@cargosoft.ru>

Hi Marek,

Thanks for the hint, looks very reasonable. I think the
PostMigrationEvent approach is more suitable for heavyweight stuff like
checking and creating database entries etc., while lazyInit is good for
more lightweight tasks like opening connections etc.

However, there's an interesting case when the postInit method is called
on hot (re)deploy (no PostMigrationEvent obviously) *and* some
heavyweight stuff needs to be done right away. (ATM postInit is not
called on hot deploy, but I hope that will be fixed soon, see KEYCLOAK-
5131 and PR #4282.)
Luckily, in this case transactions just work, so everything could be
done straightforwardly. The only question is how to distinguish between
server startup and hot (re)deploy inside postInit. There are some
indirect signs like thread name, presence/absence of specific JNDI
entries etc., but this seems hacky. Any suggestions?

Cheers,
Dmitry

> Hi,
> 
> I think it's not good to directly start transactions from postInit.?
> Among the issues you mentioned, various initial steps (eg. migration?
> from previous version, export/import) may not be yet finished at
> this?
> stage. Probably you can either:
> - Register listener for PostMigrationEvent in your postInit. See the?
> testsuite/integration-arquillian/servers/auth-
> server/services/testsuite-
> providers/src/main/java/org/keycloak/testsuite/authentication/PushBut
> tonAuthenticator.java?
> for inspiration.
> - Use the pattern with "lazyInit" like for example here?
> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/j
> ava/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.
> java#L78?
> , which is called 1st time before your provider is actually needed.
> 
> Maybe we can improve by provide more callback methods to?
> ProviderFactory/Provider to avoid the lazyInit pattern directly in?
> providers, but rather integrate it better with the Provider
> framework.?
> But for now, I think that some of the workaround above should work
> for?
> you IMO.
> 
> Marek
> 
> On 03/07/17 03:50, Dmitry Telegin wrote:
> > https://issues.jboss.org/browse/KEYCLOAK-5132
> > 
> > Meanwhile I've found a workaround - just run a transaction in a new
> > thread. However, this should be a "managed thread" - see issue
> > details
> > & comments for more info.
> > 
> > ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
> > > Hi,
> > > 
> > > (TL;DR) if a KeycloakTransaction is opened from
> > > ProviderFactory::postInit, sometimes the transaction is already
> > > active
> > > on the underlying
> > > org.jboss.jca.adapters.jdbc.local.LocalManagedConnection, which
> > > leads
> > > to errors.
> > > 
> > > (full version) I think it's essential for the providers to be
> > > able to
> > > access realm data in postInit(). For that, a transaction is
> > > required;
> > > using KeycloakModelUtils.runJobInTransaction() is a convenient
> > > method
> > > to do that:
> > > 
> > > ?????@Override
> > > ?????public void postInit(KeycloakSessionFactory factory) {
> > > ?????????KeycloakModelUtils.runJobInTransaction(factory,
> > > (KeycloakSession session) -> {
> > > ?????????????List<RealmModel> realms =
> > > session.realms().getRealms();
> > > ?????????????// do stuff
> > > ?????????});
> > > ?????}
> > > 
> > > When such a provider is deployed, in about half of cases Keycloak
> > > fails
> > > to start due to the following exception:
> > > 
> > > java.sql.SQLException: IJ031017: You cannot set autocommit during
> > > a
> > > managed transaction
> > > 
> > > (see full stacktrace here https://pastebin.com/ETtPqXQk)
> > > 
> > > I've managed to track it down to something that looks like
> > > transaction
> > > clash over a single instance of
> > > org.jboss.jca.adapters.jdbc.local.LocalManagedConnection. What
> > > happens
> > > is that the two treads at the same time begin two
> > > KeycloakTransactions
> > > which end up with the same instance of LocalManagedConnection.
> > > The
> > > above exception results from the second begin() call.
> > > 
> > > There's a system property called
> > > "ironjacamar.jdbc.ignoreautocommit"
> > > that allows to ignore the situation, but I think it's dangerous
> > > because
> > > it doesn't eliminate the transaction clash, just suppresses the
> > > check.
> > > If I'm not mistaken, this began to happen around Keycloak 2.2.x,
> > > which
> > > coincides with the changes to Keycloak transaction management.
> > > That
> > > said, do I need now some additional transaction coordination with
> > > the
> > > rest of Keycloak, or is it a bug? If former, how do I do that? If
> > > latter, how do we fix it?
> > > 
> > > I hope we'll sort it out, since the ability to access the data at
> > > every
> > > phase of provider's lifecycle seems something fundamental to me.
> > > 
> > > Regards,
> > > Dmitry
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > 
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 

From mposolda at redhat.com  Mon Jul  3 07:43:21 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 3 Jul 2017 13:43:21 +0200
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <1499079661.2825.2.camel@cargosoft.ru>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
	<1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
	<1499079661.2825.2.camel@cargosoft.ru>
Message-ID: <c6dd4262-23cd-fd52-82a2-2a9a95e5a46b@redhat.com>

On 03/07/17 13:01, Dmitry Telegin wrote:
> Hi Marek,
>
> Thanks for the hint, looks very reasonable. I think the 
> PostMigrationEvent approach is more suitable for heavyweight stuff 
> like checking and creating database entries etc., while lazyInit is 
> good for more lightweight tasks like opening connections etc.
>
> However, there's an interesting case when the postInit method is 
> called on hot (re)deploy (no PostMigrationEvent obviously) *and* some 
> heavyweight stuff needs to be done right away. (ATM postInit is not 
> called on hot deploy, but I hope that will be fixed soon, see 
> KEYCLOAK-5131 and PR #4282.)
> Luckily, in this case transactions just work, so everything could be 
> done straightforwardly. The only question is how to distinguish 
> between server startup and hot (re)deploy inside postInit. There are 
> some indirect signs like thread name, presence/absence of specific 
> JNDI entries etc., but this seems hacky. Any suggestions?
I don't have any good suggestions besides other workaround. You can 
create provider, which will be deployed "statically" and will track 
whether PostMigrationEvent was already sent. Since it is deployed at 
startup like builtin providers, the event will be always there. The 
"dynamic" providers will be then able either to ask this provider or 
listen to the event.

Maybe we need to have another lifecycle method on ProviderFactory for 
this usecase, not sure..

Marek
>
> Cheers,
> Dmitry
>
>> Hi,
>>
>> I think it's not good to directly start transactions from postInit.
>> Among the issues you mentioned, various initial steps (eg. migration
>> from previous version, export/import) may not be yet finished at this
>> stage. Probably you can either:
>> - Register listener for PostMigrationEvent in your postInit. See the
>> testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/authentication/PushButtonAuthenticator.java 
>>
>> for inspiration.
>> - Use the pattern with "lazyInit" like for example here
>> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java#L78 
>>
>> , which is called 1st time before your provider is actually needed.
>>
>> Maybe we can improve by provide more callback methods to
>> ProviderFactory/Provider to avoid the lazyInit pattern directly in
>> providers, but rather integrate it better with the Provider framework.
>> But for now, I think that some of the workaround above should work for
>> you IMO.
>>
>> Marek
>>
>> On 03/07/17 03:50, Dmitry Telegin wrote:
>>> https://issues.jboss.org/browse/KEYCLOAK-5132
>>>
>>> Meanwhile I've found a workaround - just run a transaction in a new
>>> thread. However, this should be a "managed thread" - see issue details
>>> & comments for more info.
>>>
>>> ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
>>>> Hi,
>>>>
>>>> (TL;DR) if a KeycloakTransaction is opened from
>>>> ProviderFactory::postInit, sometimes the transaction is already
>>>> active
>>>> on the underlying
>>>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection, which leads
>>>> to errors.
>>>>
>>>> (full version) I think it's essential for the providers to be able to
>>>> access realm data in postInit(). For that, a transaction is required;
>>>> using KeycloakModelUtils.runJobInTransaction() is a convenient method
>>>> to do that:
>>>>
>>>>      @Override
>>>>      public void postInit(KeycloakSessionFactory factory) {
>>>>          KeycloakModelUtils.runJobInTransaction(factory,
>>>> (KeycloakSession session) -> {
>>>>              List<RealmModel> realms = session.realms().getRealms();
>>>>              // do stuff
>>>>          });
>>>>      }
>>>>
>>>> When such a provider is deployed, in about half of cases Keycloak
>>>> fails
>>>> to start due to the following exception:
>>>>
>>>> java.sql.SQLException: IJ031017: You cannot set autocommit during a
>>>> managed transaction
>>>>
>>>> (see full stacktrace here https://pastebin.com/ETtPqXQk)
>>>>
>>>> I've managed to track it down to something that looks like
>>>> transaction
>>>> clash over a single instance of
>>>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection. What
>>>> happens
>>>> is that the two treads at the same time begin two
>>>> KeycloakTransactions
>>>> which end up with the same instance of LocalManagedConnection. The
>>>> above exception results from the second begin() call.
>>>>
>>>> There's a system property called "ironjacamar.jdbc.ignoreautocommit"
>>>> that allows to ignore the situation, but I think it's dangerous
>>>> because
>>>> it doesn't eliminate the transaction clash, just suppresses the
>>>> check.
>>>> If I'm not mistaken, this began to happen around Keycloak 2.2.x,
>>>> which
>>>> coincides with the changes to Keycloak transaction management. That
>>>> said, do I need now some additional transaction coordination with the
>>>> rest of Keycloak, or is it a bug? If former, how do I do that? If
>>>> latter, how do we fix it?
>>>>
>>>> I hope we'll sort it out, since the ability to access the data at
>>>> every
>>>> phase of provider's lifecycle seems something fundamental to me.
>>>>
>>>> Regards,
>>>> Dmitry
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>


From mitya at cargosoft.ru  Mon Jul  3 09:05:41 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 03 Jul 2017 16:05:41 +0300
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <c6dd4262-23cd-fd52-82a2-2a9a95e5a46b@redhat.com>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
	<1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
	<1499079661.2825.2.camel@cargosoft.ru>
	<c6dd4262-23cd-fd52-82a2-2a9a95e5a46b@redhat.com>
Message-ID: <1499087141.2825.5.camel@cargosoft.ru>

On Mon, 03/07/2017 13:43 +0200, Marek Posolda wrote:
> On 03/07/17 13:01, Dmitry Telegin wrote:
> > Hi Marek,
> > 
> > Thanks for the hint, looks very reasonable. I think the
> > PostMigrationEvent approach is more suitable for heavyweight stuff
> > like checking and creating database entries etc., while lazyInit is
> > good for more lightweight tasks like opening connections etc.
> > 
> > However, there's an interesting case when the postInit method is
> > called on hot (re)deploy (no PostMigrationEvent obviously) *and*
> > some heavyweight stuff needs to be done right away. (ATM postInit
> > is not called on hot deploy, but I hope that will be fixed soon,
> > see KEYCLOAK-5131 and PR #4282.)
> > Luckily, in this case transactions just work, so everything could
> > be done straightforwardly. The only question is how to distinguish
> > between server startup and hot (re)deploy inside postInit. There
> > are some indirect signs like thread name, presence/absence of
> > specific JNDI entries etc., but this seems hacky. Any suggestions?
> ?I don't have any good suggestions besides other workaround. You can
> create provider, which will be deployed "statically" and will track
> whether PostMigrationEvent was already sent. Since it is deployed at
> startup like builtin providers, the event will be always there. The
> "dynamic" providers will be then able either to ask this provider or
> listen to the event.

Another (simpler) approach is to query Resteasy for the
presence/absence of Keycloak-specific classes, because Resteasy
deployment happens right after PostMigrateEvent, but this seems very
hacky too :-\

> 
> Maybe we need to have another lifecycle method on ProviderFactory for
> this usecase, not sure..

How about ProviderFactory::postInit(KeycloakSessionFactory factory,
boolean hot) with default implementation delegating to
postInit(KeycloakSessionFactory factory)?

Dmitry

> 
> Marek
> > Cheers,
> > Dmitry
> > 
> > > Hi,
> > > 
> > > I think it's not good to directly start transactions from
> > > postInit.?
> > > Among the issues you mentioned, various initial steps (eg.
> > > migration?
> > > from previous version, export/import) may not be yet finished at
> > > this?
> > > stage. Probably you can either:
> > > - Register listener for PostMigrationEvent in your postInit. See
> > > the?
> > > testsuite/integration-arquillian/servers/auth-
> > > server/services/testsuite-
> > > providers/src/main/java/org/keycloak/testsuite/authentication/Pus
> > > hButtonAuthenticator.java?
> > > for inspiration.
> > > - Use the pattern with "lazyInit" like for example here?
> > > https://github.com/keycloak/keycloak/blob/master/model/jpa/src/ma
> > > in/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider
> > > Factory.java#L78?
> > > , which is called 1st time before your provider is actually
> > > needed.
> > > 
> > > Maybe we can improve by provide more callback methods to?
> > > ProviderFactory/Provider to avoid the lazyInit pattern directly
> > > in?
> > > providers, but rather integrate it better with the Provider
> > > framework.?
> > > But for now, I think that some of the workaround above should
> > > work for?
> > > you IMO.
> > > 
> > > Marek
> > > 
> > > On 03/07/17 03:50, Dmitry Telegin wrote:
> > > > https://issues.jboss.org/browse/KEYCLOAK-5132
> > > > 
> > > > Meanwhile I've found a workaround - just run a transaction in a
> > > > new
> > > > thread. However, this should be a "managed thread" - see issue
> > > > details
> > > > & comments for more info.
> > > > 
> > > > ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
> > > > > Hi,
> > > > > 
> > > > > (TL;DR) if a KeycloakTransaction is opened from
> > > > > ProviderFactory::postInit, sometimes the transaction is
> > > > > already
> > > > > active
> > > > > on the underlying
> > > > > org.jboss.jca.adapters.jdbc.local.LocalManagedConnection,
> > > > > which leads
> > > > > to errors.
> > > > > 
> > > > > (full version) I think it's essential for the providers to be
> > > > > able to
> > > > > access realm data in postInit(). For that, a transaction is
> > > > > required;
> > > > > using KeycloakModelUtils.runJobInTransaction() is a
> > > > > convenient method
> > > > > to do that:
> > > > > 
> > > > > ?????@Override
> > > > > ?????public void postInit(KeycloakSessionFactory factory) {
> > > > > ?????????KeycloakModelUtils.runJobInTransaction(factory,
> > > > > (KeycloakSession session) -> {
> > > > > ?????????????List<RealmModel> realms =
> > > > > session.realms().getRealms();
> > > > > ?????????????// do stuff
> > > > > ?????????});
> > > > > ?????}
> > > > > 
> > > > > When such a provider is deployed, in about half of cases
> > > > > Keycloak
> > > > > fails
> > > > > to start due to the following exception:
> > > > > 
> > > > > java.sql.SQLException: IJ031017: You cannot set autocommit
> > > > > during a
> > > > > managed transaction
> > > > > 
> > > > > (see full stacktrace here https://pastebin.com/ETtPqXQk)
> > > > > 
> > > > > I've managed to track it down to something that looks like
> > > > > transaction
> > > > > clash over a single instance of
> > > > > org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.
> > > > > What
> > > > > happens
> > > > > is that the two treads at the same time begin two
> > > > > KeycloakTransactions
> > > > > which end up with the same instance of
> > > > > LocalManagedConnection. The
> > > > > above exception results from the second begin() call.
> > > > > 
> > > > > There's a system property called
> > > > > "ironjacamar.jdbc.ignoreautocommit"
> > > > > that allows to ignore the situation, but I think it's
> > > > > dangerous
> > > > > because
> > > > > it doesn't eliminate the transaction clash, just suppresses
> > > > > the
> > > > > check.
> > > > > If I'm not mistaken, this began to happen around Keycloak
> > > > > 2.2.x,
> > > > > which
> > > > > coincides with the changes to Keycloak transaction
> > > > > management. That
> > > > > said, do I need now some additional transaction coordination
> > > > > with the
> > > > > rest of Keycloak, or is it a bug? If former, how do I do
> > > > > that? If
> > > > > latter, how do we fix it?
> > > > > 
> > > > > I hope we'll sort it out, since the ability to access the
> > > > > data at
> > > > > every
> > > > > phase of provider's lifecycle seems something fundamental to
> > > > > me.
> > > > > 
> > > > > Regards,
> > > > > Dmitry
> > > > > _______________________________________________
> > > > > keycloak-user mailing list
> > > > > keycloak-user at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > 
> > > > _______________________________________________
> > > > keycloak-user mailing list
> > > > keycloak-user at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > 
> > > 
> 
> 

From antoine at saagie.com  Mon Jul  3 09:29:28 2017
From: antoine at saagie.com (Antoine Carton)
Date: Mon, 3 Jul 2017 15:29:28 +0200
Subject: [keycloak-user] Workflow Refresh token
Message-ID: <CAMghK0YgbxOYyeeGHA237RrFT0pU4h2GBaXBhxH=RYNzmQujZg@mail.gmail.com>

Hello,

Suppose a client "C" sends a request with an expired access token, to an
application "A".
Suppose that application "A" has the refresh token of client "C" and that
"A" automatically uses this refresh token so that everything is transparent
for client "C" until the refresh token expires as well.

The trouble is that a leak of the access token (yes, access token) of
client "C" will have the same result as a leak of the refresh token.

Is it a good practice to implement automatic refresh of the token? If it's
not, how should we use the refresh token?

The Oauth 2.0 RFC (https://tools.ietf.org/html/rfc6819#section-5.2.2.2)
explains that we have to bind the refresh token to the client_id to avoid
this situation. However, I am not able to understand what it means for
application "A"?

Thanks!

From mposolda at redhat.com  Mon Jul  3 10:43:59 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 3 Jul 2017 16:43:59 +0200
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <1499087141.2825.5.camel@cargosoft.ru>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
	<1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
	<1499079661.2825.2.camel@cargosoft.ru>
	<c6dd4262-23cd-fd52-82a2-2a9a95e5a46b@redhat.com>
	<1499087141.2825.5.camel@cargosoft.ru>
Message-ID: <c300b38b-1de4-9137-5b97-769ea451b2f6@redhat.com>

On 03/07/17 15:05, Dmitry Telegin wrote:
> On Mon, 03/07/2017 13:43 +0200, Marek Posolda wrote:
>> On 03/07/17 13:01, Dmitry Telegin wrote:
>>> Hi Marek,
>>>
>>> Thanks for the hint, looks very reasonable. I think the 
>>> PostMigrationEvent approach is more suitable for heavyweight stuff 
>>> like checking and creating database entries etc., while lazyInit is 
>>> good for more lightweight tasks like opening connections etc.
>>>
>>> However, there's an interesting case when the postInit method is 
>>> called on hot (re)deploy (no PostMigrationEvent obviously) *and* 
>>> some heavyweight stuff needs to be done right away. (ATM postInit is 
>>> not called on hot deploy, but I hope that will be fixed soon, see 
>>> KEYCLOAK-5131 and PR #4282.)
>>> Luckily, in this case transactions just work, so everything could be 
>>> done straightforwardly. The only question is how to distinguish 
>>> between server startup and hot (re)deploy inside postInit. There are 
>>> some indirect signs like thread name, presence/absence of specific 
>>> JNDI entries etc., but this seems hacky. Any suggestions?
>>  I don't have any good suggestions besides other workaround. You can 
>> create provider, which will be deployed "statically" and will track 
>> whether PostMigrationEvent was already sent. Since it is deployed at 
>> startup like builtin providers, the event will be always there. The 
>> "dynamic" providers will be then able either to ask this provider or 
>> listen to the event.
>
> Another (simpler) approach is to query Resteasy for the 
> presence/absence of Keycloak-specific classes, because Resteasy 
> deployment happens right after PostMigrateEvent, but this seems very 
> hacky too :-\
>
>>
>> Maybe we need to have another lifecycle method on ProviderFactory for 
>> this usecase, not sure..
>
> How about ProviderFactory::postInit(KeycloakSessionFactory factory, 
> boolean hot) with default implementation delegating to 
> postInit(KeycloakSessionFactory factory)?
Not sure TBH.

I personally don't know how the deployer lifecycle works and if 
ProviderFactory.postInit for the "deployer" providers still can't be 
called earlier than auth-server is fully bootstrapped. Also you would 
need some "if" checks in the postInit method to differentiate between 
both cases, which doesn't look so great to me personally.

Having new method should be good from backwards compatibility 
perspective, as we have JDK8 and you can easily add new empty "default" 
method to the ProviderFactory interface without affect existing 
providers, which already use current "postInit" method with current 
signature.

Maybe will be good to move the discussion to keycloak-dev though. 
Perhaps you can start the thread here?

Thanks,
Marek
>
> Dmitry
>
>>
>> Marek
>>> Cheers,
>>> Dmitry
>>>
>>>> Hi,
>>>>
>>>> I think it's not good to directly start transactions from postInit.
>>>> Among the issues you mentioned, various initial steps (eg. migration
>>>> from previous version, export/import) may not be yet finished at this
>>>> stage. Probably you can either:
>>>> - Register listener for PostMigrationEvent in your postInit. See the
>>>> testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/authentication/PushButtonAuthenticator.java 
>>>>
>>>> for inspiration.
>>>> - Use the pattern with "lazyInit" like for example here
>>>> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java#L78 
>>>>
>>>> , which is called 1st time before your provider is actually needed.
>>>>
>>>> Maybe we can improve by provide more callback methods to
>>>> ProviderFactory/Provider to avoid the lazyInit pattern directly in
>>>> providers, but rather integrate it better with the Provider framework.
>>>> But for now, I think that some of the workaround above should work for
>>>> you IMO.
>>>>
>>>> Marek
>>>>
>>>> On 03/07/17 03:50, Dmitry Telegin wrote:
>>>>> https://issues.jboss.org/browse/KEYCLOAK-5132
>>>>>
>>>>> Meanwhile I've found a workaround - just run a transaction in a new
>>>>> thread. However, this should be a "managed thread" - see issue details
>>>>> & comments for more info.
>>>>>
>>>>> ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
>>>>>> Hi,
>>>>>>
>>>>>> (TL;DR) if a KeycloakTransaction is opened from
>>>>>> ProviderFactory::postInit, sometimes the transaction is already
>>>>>> active
>>>>>> on the underlying
>>>>>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection, which leads
>>>>>> to errors.
>>>>>>
>>>>>> (full version) I think it's essential for the providers to be able to
>>>>>> access realm data in postInit(). For that, a transaction is required;
>>>>>> using KeycloakModelUtils.runJobInTransaction() is a convenient method
>>>>>> to do that:
>>>>>>
>>>>>>      @Override
>>>>>>      public void postInit(KeycloakSessionFactory factory) {
>>>>>>          KeycloakModelUtils.runJobInTransaction(factory,
>>>>>> (KeycloakSession session) -> {
>>>>>>              List<RealmModel> realms = session.realms().getRealms();
>>>>>>              // do stuff
>>>>>>          });
>>>>>>      }
>>>>>>
>>>>>> When such a provider is deployed, in about half of cases Keycloak
>>>>>> fails
>>>>>> to start due to the following exception:
>>>>>>
>>>>>> java.sql.SQLException: IJ031017: You cannot set autocommit during a
>>>>>> managed transaction
>>>>>>
>>>>>> (see full stacktrace here https://pastebin.com/ETtPqXQk)
>>>>>>
>>>>>> I've managed to track it down to something that looks like
>>>>>> transaction
>>>>>> clash over a single instance of
>>>>>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection. What
>>>>>> happens
>>>>>> is that the two treads at the same time begin two
>>>>>> KeycloakTransactions
>>>>>> which end up with the same instance of LocalManagedConnection. The
>>>>>> above exception results from the second begin() call.
>>>>>>
>>>>>> There's a system property called "ironjacamar.jdbc.ignoreautocommit"
>>>>>> that allows to ignore the situation, but I think it's dangerous
>>>>>> because
>>>>>> it doesn't eliminate the transaction clash, just suppresses the
>>>>>> check.
>>>>>> If I'm not mistaken, this began to happen around Keycloak 2.2.x,
>>>>>> which
>>>>>> coincides with the changes to Keycloak transaction management. That
>>>>>> said, do I need now some additional transaction coordination with the
>>>>>> rest of Keycloak, or is it a bug? If former, how do I do that? If
>>>>>> latter, how do we fix it?
>>>>>>
>>>>>> I hope we'll sort it out, since the ability to access the data at
>>>>>> every
>>>>>> phase of provider's lifecycle seems something fundamental to me.
>>>>>>
>>>>>> Regards,
>>>>>> Dmitry
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>
>>


From jeremy.safont at insidegroup.fr  Mon Jul  3 10:56:27 2017
From: jeremy.safont at insidegroup.fr (Jeremy SAFONT)
Date: Mon, 3 Jul 2017 16:56:27 +0200
Subject: [keycloak-user] Get "username" field in credential model for
	hashing password
Message-ID: <CADJgPvRsFhsSqEu8=NzagtcfyOib07SnRa74-8TYfje4-qFF-g@mail.gmail.com>

Hi everybody,

I have to modify the behavior of the hash process in order to use username
+ password in order to match encryption of legacy passwords from imported
users.

I understood I have to implement PasswordHashProvider.

The blocking point is that the credentialModel object does not allow me to
get the login information.
I debugged keycloak to find where the model is filled and I find the
"toModel" method into "JpaUserProvider" class.
I would like to add "username" field into this function and this model but
I don't know how to proceed in order to get it in the PasswordHashProvider.
Someone have a detailed process to achieve this please ?

Thank you a lot !

-- 
*J?r?my S.*
*D?veloppeur applications web*

From chexxor at gmail.com  Mon Jul  3 12:16:39 2017
From: chexxor at gmail.com (Alex Berg)
Date: Mon, 3 Jul 2017 11:16:39 -0500
Subject: [keycloak-user] Workflow Refresh token
In-Reply-To: <CAMghK0YgbxOYyeeGHA237RrFT0pU4h2GBaXBhxH=RYNzmQujZg@mail.gmail.com>
References: <CAMghK0YgbxOYyeeGHA237RrFT0pU4h2GBaXBhxH=RYNzmQujZg@mail.gmail.com>
Message-ID: <CABgV3qvTfU8nuiAyRi4ERTMWUdvbUGJ=HZfo12YrbNRawC8h-A@mail.gmail.com>

Here's my view, FWIW. If the client C is a full OIC client, it should be
responsible for refreshing. It sounds like you're serving the client, which
is a web app. If it's a web app you're serving, and you are giving the
user's browser a session, then your app server is responsible for
refreshing. I put the access token in an HTTP-only cookie, so I would need
to apply same rules for securing a session token as securing the access
token.

On Jul 3, 2017 9:38 AM, "Antoine Carton" <antoine at saagie.com> wrote:

> Hello,
>
> Suppose a client "C" sends a request with an expired access token, to an
> application "A".
> Suppose that application "A" has the refresh token of client "C" and that
> "A" automatically uses this refresh token so that everything is transparent
> for client "C" until the refresh token expires as well.
>
> The trouble is that a leak of the access token (yes, access token) of
> client "C" will have the same result as a leak of the refresh token.
>
> Is it a good practice to implement automatic refresh of the token? If it's
> not, how should we use the refresh token?
>
> The Oauth 2.0 RFC (https://tools.ietf.org/html/rfc6819#section-5.2.2.2)
> explains that we have to bind the refresh token to the client_id to avoid
> this situation. However, I am not able to understand what it means for
> application "A"?
>
> Thanks!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From bburke at redhat.com  Mon Jul  3 12:48:25 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 3 Jul 2017 12:48:25 -0400
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <c300b38b-1de4-9137-5b97-769ea451b2f6@redhat.com>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
	<1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
	<1499079661.2825.2.camel@cargosoft.ru>
	<c6dd4262-23cd-fd52-82a2-2a9a95e5a46b@redhat.com>
	<1499087141.2825.5.camel@cargosoft.ru>
	<c300b38b-1de4-9137-5b97-769ea451b2f6@redhat.com>
Message-ID: <246d17c2-e534-8de2-2ca7-9102096a357d@redhat.com>

I think the problem is that 
DefaultJpaConnectionProviderFactory.checkJtaEnabled() is called after 
your provider's postInit method.  The error you are seeing is that JPA 
is trying to use a JDBC connection features within a JTA transaction 
that it is not supposed to.

I think you might be able to call checkJtaEnabled within 
DefaultJpaConnectionProviderFactory.lazyInit and that will solve the 
problem.


On 7/3/17 10:43 AM, Marek Posolda wrote:
> On 03/07/17 15:05, Dmitry Telegin wrote:
>> On Mon, 03/07/2017 13:43 +0200, Marek Posolda wrote:
>>> On 03/07/17 13:01, Dmitry Telegin wrote:
>>>> Hi Marek,
>>>>
>>>> Thanks for the hint, looks very reasonable. I think the
>>>> PostMigrationEvent approach is more suitable for heavyweight stuff
>>>> like checking and creating database entries etc., while lazyInit is
>>>> good for more lightweight tasks like opening connections etc.
>>>>
>>>> However, there's an interesting case when the postInit method is
>>>> called on hot (re)deploy (no PostMigrationEvent obviously) *and*
>>>> some heavyweight stuff needs to be done right away. (ATM postInit is
>>>> not called on hot deploy, but I hope that will be fixed soon, see
>>>> KEYCLOAK-5131 and PR #4282.)
>>>> Luckily, in this case transactions just work, so everything could be
>>>> done straightforwardly. The only question is how to distinguish
>>>> between server startup and hot (re)deploy inside postInit. There are
>>>> some indirect signs like thread name, presence/absence of specific
>>>> JNDI entries etc., but this seems hacky. Any suggestions?
>>>   I don't have any good suggestions besides other workaround. You can
>>> create provider, which will be deployed "statically" and will track
>>> whether PostMigrationEvent was already sent. Since it is deployed at
>>> startup like builtin providers, the event will be always there. The
>>> "dynamic" providers will be then able either to ask this provider or
>>> listen to the event.
>> Another (simpler) approach is to query Resteasy for the
>> presence/absence of Keycloak-specific classes, because Resteasy
>> deployment happens right after PostMigrateEvent, but this seems very
>> hacky too :-\
>>
>>> Maybe we need to have another lifecycle method on ProviderFactory for
>>> this usecase, not sure..
>> How about ProviderFactory::postInit(KeycloakSessionFactory factory,
>> boolean hot) with default implementation delegating to
>> postInit(KeycloakSessionFactory factory)?
> Not sure TBH.
>
> I personally don't know how the deployer lifecycle works and if
> ProviderFactory.postInit for the "deployer" providers still can't be
> called earlier than auth-server is fully bootstrapped. Also you would
> need some "if" checks in the postInit method to differentiate between
> both cases, which doesn't look so great to me personally.
>
> Having new method should be good from backwards compatibility
> perspective, as we have JDK8 and you can easily add new empty "default"
> method to the ProviderFactory interface without affect existing
> providers, which already use current "postInit" method with current
> signature.
>
> Maybe will be good to move the discussion to keycloak-dev though.
> Perhaps you can start the thread here?
>
> Thanks,
> Marek
>> Dmitry
>>
>>> Marek
>>>> Cheers,
>>>> Dmitry
>>>>
>>>>> Hi,
>>>>>
>>>>> I think it's not good to directly start transactions from postInit.
>>>>> Among the issues you mentioned, various initial steps (eg. migration
>>>>> from previous version, export/import) may not be yet finished at this
>>>>> stage. Probably you can either:
>>>>> - Register listener for PostMigrationEvent in your postInit. See the
>>>>> testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/authentication/PushButtonAuthenticator.java
>>>>>
>>>>> for inspiration.
>>>>> - Use the pattern with "lazyInit" like for example here
>>>>> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java#L78
>>>>>
>>>>> , which is called 1st time before your provider is actually needed.
>>>>>
>>>>> Maybe we can improve by provide more callback methods to
>>>>> ProviderFactory/Provider to avoid the lazyInit pattern directly in
>>>>> providers, but rather integrate it better with the Provider framework.
>>>>> But for now, I think that some of the workaround above should work for
>>>>> you IMO.
>>>>>
>>>>> Marek
>>>>>
>>>>> On 03/07/17 03:50, Dmitry Telegin wrote:
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-5132
>>>>>>
>>>>>> Meanwhile I've found a workaround - just run a transaction in a new
>>>>>> thread. However, this should be a "managed thread" - see issue details
>>>>>> & comments for more info.
>>>>>>
>>>>>> ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
>>>>>>> Hi,
>>>>>>>
>>>>>>> (TL;DR) if a KeycloakTransaction is opened from
>>>>>>> ProviderFactory::postInit, sometimes the transaction is already
>>>>>>> active
>>>>>>> on the underlying
>>>>>>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection, which leads
>>>>>>> to errors.
>>>>>>>
>>>>>>> (full version) I think it's essential for the providers to be able to
>>>>>>> access realm data in postInit(). For that, a transaction is required;
>>>>>>> using KeycloakModelUtils.runJobInTransaction() is a convenient method
>>>>>>> to do that:
>>>>>>>
>>>>>>>       @Override
>>>>>>>       public void postInit(KeycloakSessionFactory factory) {
>>>>>>>           KeycloakModelUtils.runJobInTransaction(factory,
>>>>>>> (KeycloakSession session) -> {
>>>>>>>               List<RealmModel> realms = session.realms().getRealms();
>>>>>>>               // do stuff
>>>>>>>           });
>>>>>>>       }
>>>>>>>
>>>>>>> When such a provider is deployed, in about half of cases Keycloak
>>>>>>> fails
>>>>>>> to start due to the following exception:
>>>>>>>
>>>>>>> java.sql.SQLException: IJ031017: You cannot set autocommit during a
>>>>>>> managed transaction
>>>>>>>
>>>>>>> (see full stacktrace here https://pastebin.com/ETtPqXQk)
>>>>>>>
>>>>>>> I've managed to track it down to something that looks like
>>>>>>> transaction
>>>>>>> clash over a single instance of
>>>>>>> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection. What
>>>>>>> happens
>>>>>>> is that the two treads at the same time begin two
>>>>>>> KeycloakTransactions
>>>>>>> which end up with the same instance of LocalManagedConnection. The
>>>>>>> above exception results from the second begin() call.
>>>>>>>
>>>>>>> There's a system property called "ironjacamar.jdbc.ignoreautocommit"
>>>>>>> that allows to ignore the situation, but I think it's dangerous
>>>>>>> because
>>>>>>> it doesn't eliminate the transaction clash, just suppresses the
>>>>>>> check.
>>>>>>> If I'm not mistaken, this began to happen around Keycloak 2.2.x,
>>>>>>> which
>>>>>>> coincides with the changes to Keycloak transaction management. That
>>>>>>> said, do I need now some additional transaction coordination with the
>>>>>>> rest of Keycloak, or is it a bug? If former, how do I do that? If
>>>>>>> latter, how do we fix it?
>>>>>>>
>>>>>>> I hope we'll sort it out, since the ability to access the data at
>>>>>>> every
>>>>>>> phase of provider's lifecycle seems something fundamental to me.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Dmitry
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From mposolda at redhat.com  Mon Jul  3 15:18:54 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 3 Jul 2017 21:18:54 +0200
Subject: [keycloak-user] Keycloak offline token
In-Reply-To: <CAEC2WbwfSUN_vqPjJ7LtkiNnjr5VTT4h3AsZxDTAGyB3FESzsg@mail.gmail.com>
References: <CAEC2WbwfSUN_vqPjJ7LtkiNnjr5VTT4h3AsZxDTAGyB3FESzsg@mail.gmail.com>
Message-ID: <c978610d-a87d-a4bf-22db-abb2857f422a@redhat.com>

Not sure you need offline token. Offline token is useful if you need to 
do something on behalf of user when this user is not online (eg. some 
background task). Here the user will be always online AFAIK?

Also the offline token is kind of refresh token, which is useful just 
for refreshing the access token. But offline token (or refresh token) 
itself is not intended to be used as bearer token from the 
authentication of one application to other.

I am not sure I understand your usecase, but maybe you can:
- Login into app A and then invoke the REST endpoint on app B with the 
access token used as bearer token
- Or secure app B with Keycloak too and authenticate with "prompt=none" 
parameter, which will mean that app B will be authenticated just if user 
is already authenticated in SSO session. Otherwise Keycloak login form 
won't be shown and app B will need to be authenticated some other way.

Marek

On 23/06/17 19:05, Sherminator Kasuga wrote:
> I have a web app (called A) that is using Keycloak to login in.
> There is another external web app (called B) that uses an own system as
> login.
>
> Now I need to create a link between A to B that automatic logins into web
> app B without keycloak login form (auto-login).
>
> How can i reproduce this behavior?
> I have user and a password for B , and i am thinking to use an offline
> token could help me with this objective.
>
> username=bburke&password=geheim&grant_type=password&scope=offline_access
>
> Saving into the database of A the offline token at the first time that
> i use the link and then using this offline token for the next.
>
> could it be possible?
>
>
> my idea is something like:
>
> If database.offlinetoken = empty
>      LINK_TO_GENERATE_OFFLINE_TOKEN  --- save this token into db after login in B
>
> else
>
>      LINK_USING_OFFLINETOKEN
> endif
>
>
> Do you have any example about how to build above links? Thanks in advance :)
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mitya at cargosoft.ru  Mon Jul  3 18:34:16 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Tue, 04 Jul 2017 01:34:16 +0300
Subject: [keycloak-user] ProviderFactory::postInit + transactions =
 startup failure
In-Reply-To: <246d17c2-e534-8de2-2ca7-9102096a357d@redhat.com>
References: <1498673904.3162.1.camel@cargosoft.ru>
	<1499046603.11005.3.camel@cargosoft.ru>
	<1c5c3041-754f-9767-98f1-8da4aa91b839@redhat.com>
	<1499079661.2825.2.camel@cargosoft.ru>
	<c6dd4262-23cd-fd52-82a2-2a9a95e5a46b@redhat.com>
	<1499087141.2825.5.camel@cargosoft.ru>
	<c300b38b-1de4-9137-5b97-769ea451b2f6@redhat.com>
	<246d17c2-e534-8de2-2ca7-9102096a357d@redhat.com>
Message-ID: <1499121256.4095.2.camel@cargosoft.ru>

Hi Bill, thanks for the suggestion,

> I think the problem is that?
> DefaultJpaConnectionProviderFactory.checkJtaEnabled() is called
> after?
> your provider's postInit method.??The error you are seeing is that
> JPA?
> is trying to use a JDBC connection features within a JTA transaction?
> that it is not supposed to.
> 
> I think you might be able to call checkJtaEnabled within?
> DefaultJpaConnectionProviderFactory.lazyInit and that will solve the?
> problem.

I?think you meant DefaultJpaConnectionProviderFactory.postInit? (since
lazyInit is private and doesn't call checkJtaEnabled)

Indeed, I've added the following lines to my postInit:

????????ProviderFactory<JpaConnectionProvider> jpa =
factory.getProviderFactory(JpaConnectionProvider.class);
????????jpa.postInit(factory);
        // now do the real stuff
        KeycloakModelUtils.runJobInTransaction(factory,
(KeycloakSession session) -> { ... }

...and this worked, the result is very stable, no exceptions are
thrown. However, as Marek has noted, postInit is called really very
early. For example, on the very first run it is invoked even before
database schema is created and master realm is initialized, so it ends
up with an empty list of realms.

To sum up, we have the following three approaches:
1. if absolutely needed, transactions can be used in postInit right
away after the explicit call to
DefaultJpaConnectionProviderFactory.postInit(). Should be used at one's
risk since it is called early;
2. listen for PostMigrationEvent;
3. implement lazyInit pattern.

If this situation with checkJtaEnabled() is kind of by design, I think
KEYCLOAK-5132 can be closed w/o resolution, provided that we document
the above approaches somewhere.

Thanks again for your help!
Dmitry


> 
> 
> On 7/3/17 10:43 AM, Marek Posolda wrote:
> > On 03/07/17 15:05, Dmitry Telegin wrote:
> > > On Mon, 03/07/2017 13:43 +0200, Marek Posolda wrote:
> > > > On 03/07/17 13:01, Dmitry Telegin wrote:
> > > > > Hi Marek,
> > > > > 
> > > > > Thanks for the hint, looks very reasonable. I think the
> > > > > PostMigrationEvent approach is more suitable for heavyweight
> > > > > stuff
> > > > > like checking and creating database entries etc., while
> > > > > lazyInit is
> > > > > good for more lightweight tasks like opening connections etc.
> > > > > 
> > > > > However, there's an interesting case when the postInit method
> > > > > is
> > > > > called on hot (re)deploy (no PostMigrationEvent obviously)
> > > > > *and*
> > > > > some heavyweight stuff needs to be done right away. (ATM
> > > > > postInit is
> > > > > not called on hot deploy, but I hope that will be fixed soon,
> > > > > see
> > > > > KEYCLOAK-5131 and PR #4282.)
> > > > > Luckily, in this case transactions just work, so everything
> > > > > could be
> > > > > done straightforwardly. The only question is how to
> > > > > distinguish
> > > > > between server startup and hot (re)deploy inside postInit.
> > > > > There are
> > > > > some indirect signs like thread name, presence/absence of
> > > > > specific
> > > > > JNDI entries etc., but this seems hacky. Any suggestions?
> > > > 
> > > > ? I don't have any good suggestions besides other workaround.
> > > > You can
> > > > create provider, which will be deployed "statically" and will
> > > > track
> > > > whether PostMigrationEvent was already sent. Since it is
> > > > deployed at
> > > > startup like builtin providers, the event will be always there.
> > > > The
> > > > "dynamic" providers will be then able either to ask this
> > > > provider or
> > > > listen to the event.
> > > 
> > > Another (simpler) approach is to query Resteasy for the
> > > presence/absence of Keycloak-specific classes, because Resteasy
> > > deployment happens right after PostMigrateEvent, but this seems
> > > very
> > > hacky too :-\
> > > 
> > > > Maybe we need to have another lifecycle method on
> > > > ProviderFactory for
> > > > this usecase, not sure..
> > > 
> > > How about ProviderFactory::postInit(KeycloakSessionFactory
> > > factory,
> > > boolean hot) with default implementation delegating to
> > > postInit(KeycloakSessionFactory factory)?
> > 
> > Not sure TBH.
> > 
> > I personally don't know how the deployer lifecycle works and if
> > ProviderFactory.postInit for the "deployer" providers still can't
> > be
> > called earlier than auth-server is fully bootstrapped. Also you
> > would
> > need some "if" checks in the postInit method to differentiate
> > between
> > both cases, which doesn't look so great to me personally.
> > 
> > Having new method should be good from backwards compatibility
> > perspective, as we have JDK8 and you can easily add new empty
> > "default"
> > method to the ProviderFactory interface without affect existing
> > providers, which already use current "postInit" method with current
> > signature.
> > 
> > Maybe will be good to move the discussion to keycloak-dev though.
> > Perhaps you can start the thread here?
> > 
> > Thanks,
> > Marek
> > > Dmitry
> > > 
> > > > Marek
> > > > > Cheers,
> > > > > Dmitry
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I think it's not good to directly start transactions from
> > > > > > postInit.
> > > > > > Among the issues you mentioned, various initial steps (eg.
> > > > > > migration
> > > > > > from previous version, export/import) may not be yet
> > > > > > finished at this
> > > > > > stage. Probably you can either:
> > > > > > - Register listener for PostMigrationEvent in your
> > > > > > postInit. See the
> > > > > > testsuite/integration-arquillian/servers/auth-
> > > > > > server/services/testsuite-
> > > > > > providers/src/main/java/org/keycloak/testsuite/authenticati
> > > > > > on/PushButtonAuthenticator.java
> > > > > > 
> > > > > > for inspiration.
> > > > > > - Use the pattern with "lazyInit" like for example here
> > > > > > https://github.com/keycloak/keycloak/blob/master/model/jpa/
> > > > > > src/main/java/org/keycloak/connections/jpa/DefaultJpaConnec
> > > > > > tionProviderFactory.java#L78
> > > > > > 
> > > > > > , which is called 1st time before your provider is actually
> > > > > > needed.
> > > > > > 
> > > > > > Maybe we can improve by provide more callback methods to
> > > > > > ProviderFactory/Provider to avoid the lazyInit pattern
> > > > > > directly in
> > > > > > providers, but rather integrate it better with the Provider
> > > > > > framework.
> > > > > > But for now, I think that some of the workaround above
> > > > > > should work for
> > > > > > you IMO.
> > > > > > 
> > > > > > Marek
> > > > > > 
> > > > > > On 03/07/17 03:50, Dmitry Telegin wrote:
> > > > > > > https://issues.jboss.org/browse/KEYCLOAK-5132
> > > > > > > 
> > > > > > > Meanwhile I've found a workaround - just run a
> > > > > > > transaction in a new
> > > > > > > thread. However, this should be a "managed thread" - see
> > > > > > > issue details
> > > > > > > & comments for more info.
> > > > > > > 
> > > > > > > ? Wed, 28/06/2017 ? 21:18 +0300, Dmitry Telegin ?????:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > (TL;DR) if a KeycloakTransaction is opened from
> > > > > > > > ProviderFactory::postInit, sometimes the transaction is
> > > > > > > > already
> > > > > > > > active
> > > > > > > > on the underlying
> > > > > > > > org.jboss.jca.adapters.jdbc.local.LocalManagedConnectio
> > > > > > > > n, which leads
> > > > > > > > to errors.
> > > > > > > > 
> > > > > > > > (full version) I think it's essential for the providers
> > > > > > > > to be able to
> > > > > > > > access realm data in postInit(). For that, a
> > > > > > > > transaction is required;
> > > > > > > > using KeycloakModelUtils.runJobInTransaction() is a
> > > > > > > > convenient method
> > > > > > > > to do that:
> > > > > > > > 
> > > > > > > > ??????@Override
> > > > > > > > ??????public void postInit(KeycloakSessionFactory
> > > > > > > > factory) {
> > > > > > > > ??????????KeycloakModelUtils.runJobInTransaction(factor
> > > > > > > > y,
> > > > > > > > (KeycloakSession session) -> {
> > > > > > > > ??????????????List<RealmModel> realms =
> > > > > > > > session.realms().getRealms();
> > > > > > > > ??????????????// do stuff
> > > > > > > > ??????????});
> > > > > > > > ??????}
> > > > > > > > 
> > > > > > > > When such a provider is deployed, in about half of
> > > > > > > > cases Keycloak
> > > > > > > > fails
> > > > > > > > to start due to the following exception:
> > > > > > > > 
> > > > > > > > java.sql.SQLException: IJ031017: You cannot set
> > > > > > > > autocommit during a
> > > > > > > > managed transaction
> > > > > > > > 
> > > > > > > > (see full stacktrace here https://pastebin.com/ETtPqXQk
> > > > > > > > )
> > > > > > > > 
> > > > > > > > I've managed to track it down to something that looks
> > > > > > > > like
> > > > > > > > transaction
> > > > > > > > clash over a single instance of
> > > > > > > > org.jboss.jca.adapters.jdbc.local.LocalManagedConnectio
> > > > > > > > n. What
> > > > > > > > happens
> > > > > > > > is that the two treads at the same time begin two
> > > > > > > > KeycloakTransactions
> > > > > > > > which end up with the same instance of
> > > > > > > > LocalManagedConnection. The
> > > > > > > > above exception results from the second begin() call.
> > > > > > > > 
> > > > > > > > There's a system property called
> > > > > > > > "ironjacamar.jdbc.ignoreautocommit"
> > > > > > > > that allows to ignore the situation, but I think it's
> > > > > > > > dangerous
> > > > > > > > because
> > > > > > > > it doesn't eliminate the transaction clash, just
> > > > > > > > suppresses the
> > > > > > > > check.
> > > > > > > > If I'm not mistaken, this began to happen around
> > > > > > > > Keycloak 2.2.x,
> > > > > > > > which
> > > > > > > > coincides with the changes to Keycloak transaction
> > > > > > > > management. That
> > > > > > > > said, do I need now some additional transaction
> > > > > > > > coordination with the
> > > > > > > > rest of Keycloak, or is it a bug? If former, how do I
> > > > > > > > do that? If
> > > > > > > > latter, how do we fix it?
> > > > > > > > 
> > > > > > > > I hope we'll sort it out, since the ability to access
> > > > > > > > the data at
> > > > > > > > every
> > > > > > > > phase of provider's lifecycle seems something
> > > > > > > > fundamental to me.
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Dmitry
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-user mailing list
> > > > > > > > keycloak-user at lists.jboss.org <mailto:keycloak-
> > > > > > > > user at lists.jboss.org>
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > keycloak-user mailing list
> > > > > > > keycloak-user at lists.jboss.org <mailto:keycloak-
> > > > > > > user at lists.jboss.org>
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > 
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From akaya at expedia.com  Tue Jul  4 02:41:31 2017
From: akaya at expedia.com (Sarp Kaya)
Date: Tue, 4 Jul 2017 06:41:31 +0000
Subject: [keycloak-user] Keycloak very slow on retrieving "events"
Message-ID: <BAC94174-F401-4448-BD5D-B19DCD842454@expedia.com>

Hello,

When I click on Events, it takes very long time (more than a minute) just to display first 5 events. I checked what endpoint it uses and it?s using this:

"/auth/admin/realms/<realm-id>/events?first=0&max=5? endpoint.

I believe that there is something broken with the filtering option as it should never take more than a minute to just retrieve 5 results.

I?m using Keycloak 3.1.0 and MySQL for the database.

From antoine at saagie.com  Tue Jul  4 05:45:52 2017
From: antoine at saagie.com (Antoine Carton)
Date: Tue, 4 Jul 2017 11:45:52 +0200
Subject: [keycloak-user] Workflow Refresh token
In-Reply-To: <CABgV3qvTfU8nuiAyRi4ERTMWUdvbUGJ=HZfo12YrbNRawC8h-A@mail.gmail.com>
References: <CAMghK0YgbxOYyeeGHA237RrFT0pU4h2GBaXBhxH=RYNzmQujZg@mail.gmail.com>
	<CABgV3qvTfU8nuiAyRi4ERTMWUdvbUGJ=HZfo12YrbNRawC8h-A@mail.gmail.com>
Message-ID: <CAMghK0b19Z4Fu+W-pNPxQ_cQCe+v=yjY_dL6AwSsgdnXBYeLdA@mail.gmail.com>

Hello Alex,

Indeed, it seems that HTTP-only and Secure flags on the cookie seems to be
the best solution. However, it seems strange that this is the main workflow
of refresh tokens?

Thanks!

2017-07-03 18:16 GMT+02:00 Alex Berg <chexxor at gmail.com>:

> Here's my view, FWIW. If the client C is a full OIC client, it should be
> responsible for refreshing. It sounds like you're serving the client, which
> is a web app. If it's a web app you're serving, and you are giving the
> user's browser a session, then your app server is responsible for
> refreshing. I put the access token in an HTTP-only cookie, so I would need
> to apply same rules for securing a session token as securing the access
> token.
>
> On Jul 3, 2017 9:38 AM, "Antoine Carton" <antoine at saagie.com> wrote:
>
>> Hello,
>>
>> Suppose a client "C" sends a request with an expired access token, to an
>> application "A".
>> Suppose that application "A" has the refresh token of client "C" and that
>> "A" automatically uses this refresh token so that everything is
>> transparent
>> for client "C" until the refresh token expires as well.
>>
>> The trouble is that a leak of the access token (yes, access token) of
>> client "C" will have the same result as a leak of the refresh token.
>>
>> Is it a good practice to implement automatic refresh of the token? If it's
>> not, how should we use the refresh token?
>>
>> The Oauth 2.0 RFC (https://tools.ietf.org/html/rfc6819#section-5.2.2.2)
>> explains that we have to bind the refresh token to the client_id to avoid
>> this situation. However, I am not able to understand what it means for
>> application "A"?
>>
>> Thanks!
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>

From marc.tempelmeier at flane.de  Tue Jul  4 08:18:44 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Tue, 4 Jul 2017 12:18:44 +0000
Subject: [keycloak-user] Workflow Refresh token
In-Reply-To: <CAMghK0b19Z4Fu+W-pNPxQ_cQCe+v=yjY_dL6AwSsgdnXBYeLdA@mail.gmail.com>
References: <CAMghK0YgbxOYyeeGHA237RrFT0pU4h2GBaXBhxH=RYNzmQujZg@mail.gmail.com>
	<CABgV3qvTfU8nuiAyRi4ERTMWUdvbUGJ=HZfo12YrbNRawC8h-A@mail.gmail.com>
	<CAMghK0b19Z4Fu+W-pNPxQ_cQCe+v=yjY_dL6AwSsgdnXBYeLdA@mail.gmail.com>
Message-ID: <c838d8a826824b72ba9aa2c417002809@dehamex2013.europe.flane.local>

Hi,

Is k_logout supported with SAML Implementation?

BR

Marc


From nikolaj at majorov.biz  Tue Jul  4 11:35:38 2017
From: nikolaj at majorov.biz (Nikolaj Majorov)
Date: Tue, 4 Jul 2017 17:35:38 +0200
Subject: [keycloak-user] Consent Required how it works exatly
Message-ID: <CAHSaR+912pr6jtgGPDHqEJ=wogX15P6+0ibkh_TJ0EQZ7D95eQ@mail.gmail.com>

Hi all,

I see that for sample app-jee-html5 application in the  the client
configuration the property
"Consent Required" is configured. How does it implemented ? doest it
mean that application get cookie first after user logged-in with
user-name password  or other js Iframe ? and only after login with
user-name& password the  client can ask for token ?

From tech at psynd.net  Tue Jul  4 12:42:40 2017
From: tech at psynd.net (Tech)
Date: Tue, 4 Jul 2017 18:42:40 +0200
Subject: [keycloak-user] Application to application: could Keycloak
	implement this?
Message-ID: <7d4227a7-9bc4-0a93-dffb-c1daa725b0fa@psynd.net>

Dear experts,

I want to bring you this use case to understand if you might be able to 
support me.

Our architecture is based in java, where we might have two kind of clients:

  * Fat java clients
  * Browsers

Application servers with:

  * Web containers performing local and remote EJB calls + remote WS calls
  * EJB container performing local and remote EJB calls + remote WS calls
  * A remote EJB server performing local and remote EJB calls + remote
    WS calls
  * Ws implemeting SOAP or REST
  * Server SSO able to protect what described above

The goal is to allow the clients (thin and fat) to authenticate on the 
SSO server and to propagate the user identity on these requests:

  * Fat client authenticated -> EJB secure -> WS secure
  * Browser authenticated -> Web container -> EJB secure -> WS secure

The solution could use a secure token OAuth, OIDC or SAML.

The token propagation should be based on standards JAAS and WS-Security.

We saw that is possible to implement something similar in some SAML 
Login Modules on JBoss Enterprise server, but we are not finding 
anything equivalent in Keycloak.

We cannot neither find, for example, not neither for a STS server, that 
are the required elements to transform this kind of tokens.


Did anybody faced a similar experience?

Thanks for your support!


From sthorger at redhat.com  Tue Jul  4 13:56:13 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 4 Jul 2017 19:56:13 +0200
Subject: [keycloak-user] Keycloak very slow on retrieving "events"
In-Reply-To: <BAC94174-F401-4448-BD5D-B19DCD842454@expedia.com>
References: <BAC94174-F401-4448-BD5D-B19DCD842454@expedia.com>
Message-ID: <CAJgngAeZHTHACc8sdFw_Uw3oVgw-1tKjZ02AVDCbyqau-Pp8=w@mail.gmail.com>

That's not good, it should be much quicker than that. Do you have a lot of
events?

On 4 July 2017 at 08:41, Sarp Kaya <akaya at expedia.com> wrote:

> Hello,
>
> When I click on Events, it takes very long time (more than a minute) just
> to display first 5 events. I checked what endpoint it uses and it?s using
> this:
>
> "/auth/admin/realms/<realm-id>/events?first=0&max=5? endpoint.
>
> I believe that there is something broken with the filtering option as it
> should never take more than a minute to just retrieve 5 results.
>
> I?m using Keycloak 3.1.0 and MySQL for the database.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From matija.mazi at gmail.com  Tue Jul  4 14:10:53 2017
From: matija.mazi at gmail.com (Matija Mazi)
Date: Tue, 04 Jul 2017 18:10:53 +0000
Subject: [keycloak-user] KeycloakSession users() returns UserRepresentation
 with no name after REGISTER event
In-Reply-To: <CAB6=Ntah+wxPBp=j7hV3r0f6ErFijd1QD5n19AsbMf_+dCbMqw@mail.gmail.com>
References: <CAB6=Nta1gG9K2rV+9or92J=HT7n8m9WiOicNXQyL+A6CYmeP3g@mail.gmail.com>
	<CAB6=Ntah+wxPBp=j7hV3r0f6ErFijd1QD5n19AsbMf_+dCbMqw@mail.gmail.com>
Message-ID: <CAB6=NtZ9rxA+wTSCMOfToOT7wPGcD8MkA2p4V1yiae7F7twp9A@mail.gmail.com>

Hi,

I'm using an EventListenerProvider to catch user registration events (when
the user registers via Keycloak's Registration Form) and send the
registered user's details to an outside system.

Here's the relevant code:

public class LocoinsEventListenerProvider implements EventListenerProvider {
    private final KeycloakSession session; // provided in constructor

@Override public void onEvent(Event evt) {
    if (evt.getType() == EventType.REGISTER &&
Objects.equals(evt.getRealmId(), this.realm)) {
        final String userId = evt.getUserId();
        final RealmModel realm = session.realms().getRealm(evt.getRealmId());

final UserModel user = session.users().getUserById(userId, realm);
log.info("Customer registered, notifying application: id = {}, name = {}
{}, email = {}", userId, user.getFirstName(), user.getLastName(),
user.getEmail());
} } }

The problem is that user.getFirstName(), user.getLastName() are both
null (but user.getEmail() holds the correct value).

If I check the Keycloak database directly after this (table
USER_ENTITY), FIRST_NAME and LAST_NAME are both there.

Any ideas why this might be? How should I get what the first and last
name entered by the users?

Thanks!

P.S. If I create the user via the Keycloak REST API client and then
catch the corresponding Admin event (I don't get a REGISTER event in
this case),
the UserRepresentation obtained in the same way as above holds all the
data (first, last name etc.):

final UserRepresentation user = new UserRepresentation();
user.setUsername(email);
user.setEmail(email);
user.setFirstName(name);

kc.realm(*"MyRealm"*).users().create(user);

From jasonspittel at yahoo.com  Tue Jul  4 17:51:50 2017
From: jasonspittel at yahoo.com (Jason Spittel)
Date: Tue, 4 Jul 2017 21:51:50 +0000 (UTC)
Subject: [keycloak-user] Problems logging out using JEE to keycloak to SAML
 (ADFS) (better formatted)
References: <2140990500.5387792.1499205110788.ref@mail.yahoo.com>
Message-ID: <2140990500.5387792.1499205110788@mail.yahoo.com>

Apparently my formatting was lost. So I'm reposting this in a more readable format:

Hello,

I'm having difficulty completing a logout. 
SETUP: 
JEE webapp to keycloak to IdP (ADFS (SAML))

WORKFLOW: 
1) On logout in the webapp 
externalContext.redirect(externalContext.getRequestContextPath() + "?GLO=true");

2) User is sent to ADFS letting them know they have successfully logged out.

3) However, there is still a keycloak user session alive (seen in the admin console)

4) Hitting a protected resource in the webapp lets user in without having to log back in.

Debugging the keycloak server, I found this bit of code in AuthenticationManager.browserLogout() line 262:

String brokerId = userSession.getNote(Details.IDENTITY_PROVIDER); 

if (brokerId != null) {???? 
?? IdentityProvider identityProvider = IdentityBrokerService.getIdentityProvider(session, realm, brokerId);???? 
?? Response response = identityProvider.keycloakInitiatedBrowserLogout(session, userSession, uriInfo, realm);???? 
?? if (response != null) return response; 
} 

return finishBrowserLogout(session, realm, userSession, uriInfo, connection, headers);

I think, unless I'm misunderstanding it, that I need to hit the finishBrowserLogout method, to clear the keycloak user session. 
But the way this is written makes it so it never will. Is keycloak expecting ADFS to clear its user session? Am I logging out incorrectly?
Thanks, 
Jason

From akaya at expedia.com  Tue Jul  4 19:10:40 2017
From: akaya at expedia.com (Sarp Kaya)
Date: Tue, 4 Jul 2017 23:10:40 +0000
Subject: [keycloak-user] Keycloak very slow on retrieving "events"
In-Reply-To: <CAJgngAeZHTHACc8sdFw_Uw3oVgw-1tKjZ02AVDCbyqau-Pp8=w@mail.gmail.com>
References: <BAC94174-F401-4448-BD5D-B19DCD842454@expedia.com>
	<CAJgngAeZHTHACc8sdFw_Uw3oVgw-1tKjZ02AVDCbyqau-Pp8=w@mail.gmail.com>
Message-ID: <A14BE085-CCB4-40F2-94FD-807ECDCD2CC7@expedia.com>

Yes, I have a lot of events, but I thought it shouldn?t matter when picking the first 5 events.

Thanks,
Sarp

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Wednesday, July 5, 2017 at 3:56 AM
To: Abdullah Sarp <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Keycloak very slow on retrieving "events"

That's not good, it should be much quicker than that. Do you have a lot of events?

On 4 July 2017 at 08:41, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Hello,

When I click on Events, it takes very long time (more than a minute) just to display first 5 events. I checked what endpoint it uses and it?s using this:

"/auth/admin/realms/<realm-id>/events?first=0&max=5? endpoint.

I believe that there is something broken with the filtering option as it should never take more than a minute to just retrieve 5 results.

I?m using Keycloak 3.1.0 and MySQL for the database.
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user


From sthorger at redhat.com  Wed Jul  5 01:29:51 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 07:29:51 +0200
Subject: [keycloak-user] Keycloak very slow on retrieving "events"
In-Reply-To: <A14BE085-CCB4-40F2-94FD-807ECDCD2CC7@expedia.com>
References: <BAC94174-F401-4448-BD5D-B19DCD842454@expedia.com>
	<CAJgngAeZHTHACc8sdFw_Uw3oVgw-1tKjZ02AVDCbyqau-Pp8=w@mail.gmail.com>
	<A14BE085-CCB4-40F2-94FD-807ECDCD2CC7@expedia.com>
Message-ID: <CAJgngAeu5BvdD0f-DZnbExbvO1mNnK6eDdQ6xsq5huRJjiqbZg@mail.gmail.com>

Can you create a bug report please? Include as much info as you can so it's
easy for us to reproduce the problem (how many events you have, what the
query is you're running, etc..)

On 5 July 2017 at 01:10, Sarp Kaya <akaya at expedia.com> wrote:

> Yes, I have a lot of events, but I thought it shouldn?t matter when
> picking the first 5 events.
>
> Thanks,
> Sarp
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: Wednesday, July 5, 2017 at 3:56 AM
> To: Abdullah Sarp <akaya at expedia.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Keycloak very slow on retrieving "events"
>
> That's not good, it should be much quicker than that. Do you have a lot of
> events?
>
> On 4 July 2017 at 08:41, Sarp Kaya <akaya at expedia.com> wrote:
>
>> Hello,
>>
>> When I click on Events, it takes very long time (more than a minute) just
>> to display first 5 events. I checked what endpoint it uses and it?s using
>> this:
>>
>> "/auth/admin/realms/<realm-id>/events?first=0&max=5? endpoint.
>>
>> I believe that there is something broken with the filtering option as it
>> should never take more than a minute to just retrieve 5 results.
>>
>> I?m using Keycloak 3.1.0 and MySQL for the database.
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>

From sthorger at redhat.com  Wed Jul  5 01:33:04 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 07:33:04 +0200
Subject: [keycloak-user] Chinese translations
Message-ID: <CAJgngAcKqKSakC02ZYbuseN0WJ28okwa=0_AzajL=9ba==emZw@mail.gmail.com>

I'm trying once more. Is there someone out there that knows Chinese that
can review PR for translations?

The PR is here:
https://github.com/keycloak/keycloak/pull/4251

From johan.heylen.public at gmail.com  Wed Jul  5 03:08:38 2017
From: johan.heylen.public at gmail.com (Johan Heylen)
Date: Wed, 5 Jul 2017 09:08:38 +0200
Subject: [keycloak-user] Keycloak very slow on retrieving "events" (Sarp
	Kaya)
Message-ID: <CADLc4EFoEQqN0jKns9b=S344tCx2cgBmZmEHqvKfxiZDJRgt9g@mail.gmail.com>

We faced the same problem and added a series of indexes on the events table.

CREATE INDEX idx_event_entity_user_id_realm_id_dnsbelgium ON event_entity
USING btree (user_id, realm_id);
CREATE INDEX idx_event_entity_user_id_type_dnsbelgium ON event_entity USING
btree (user_id, type);
CREATE INDEX idx_event_entity_type_dnsbelgium ON event_entity USING btree
(type);
CREATE INDEX idx_event_entity_realm_id_dnsbelgium ON event_entity USING
btree (realm_id);
CREATE INDEX idx_event_entity_client_id_dnsbelgium ON event_entity USING
btree (client_id);
CREATE INDEX idx_event_entity_user_id_dnsbelgium ON event_entity USING
btree (user_id);

and now queries are working fast

Johan

On 4 July 2017 at 08:41, Sarp Kaya <akaya at expedia.com> wrote:

> Hello,
>
> When I click on Events, it takes very long time (more than a minute) just
> to display first 5 events. I checked what endpoint it uses and it?s using
> this:
>
> "/auth/admin/realms/<realm-id>/events?first=0&max=5? endpoint.
>
> I believe that there is something broken with the filtering option as it
> should never take more than a minute to just retrieve 5 results.
>
> I?m using Keycloak 3.1.0 and MySQL for the database.

From sthorger at redhat.com  Wed Jul  5 03:39:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 09:39:57 +0200
Subject: [keycloak-user] Keycloak 3.2.0.Final Released
Message-ID: <CAJgngAeSY1riVyHD8wBTo77r9yzBDw0aQYdDqe+AqUOx452CqQ@mail.gmail.com>

Keycloak 3.2.0.Final has just been released.

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

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

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

From marc.tempelmeier at flane.de  Wed Jul  5 04:09:43 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Wed, 5 Jul 2017 08:09:43 +0000
Subject: [keycloak-user] Keycloak 3.2.0.Final Released
In-Reply-To: <CAJgngAeSY1riVyHD8wBTo77r9yzBDw0aQYdDqe+AqUOx452CqQ@mail.gmail.com>
References: <CAJgngAeSY1riVyHD8wBTo77r9yzBDw0aQYdDqe+AqUOx452CqQ@mail.gmail.com>
Message-ID: <f30fec3dd46443e6b1b9baf6a59c4ef0@dehamex2013.europe.flane.local>

Hi,

I get the following error with the new version in Domain Controlled Mode:

slave3_1            | [Server:slave3] 08:08:40,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "keycloak-server.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.ValidatorFactory is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.ModuleName is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.deployment.unit.\"keycloak-server.war\".jca.cachedConnectionManagerSetupProcessor is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.InAppClientContainer is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.app.auth is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.concurrent.ee.context.config.auth.auth is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.InstanceName is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.deployment.unit.\"keycloak-server.war\".INSTALL is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.Validator is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.app.auth.AppName is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.deployment.unit.\"keycloak-server.war\".ejb3.client-context.registration-service is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]"

BR

Marc

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] Im Auftrag von Stian Thorgersen
Gesendet: Wednesday, July 5, 2017 9:40 AM
An: keycloak-user <keycloak-user at lists.jboss.org>
Betreff: [keycloak-user] Keycloak 3.2.0.Final Released

Keycloak 3.2.0.Final has just been released.

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

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

Before you upgrade remember to backup your database and check the migration guide <https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
.
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user


From marc.tempelmeier at flane.de  Wed Jul  5 04:31:09 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Wed, 5 Jul 2017 08:31:09 +0000
Subject: [keycloak-user] Keycloak 3.2.0.Final Released
In-Reply-To: <f30fec3dd46443e6b1b9baf6a59c4ef0@dehamex2013.europe.flane.local>
References: <CAJgngAeSY1riVyHD8wBTo77r9yzBDw0aQYdDqe+AqUOx452CqQ@mail.gmail.com>
	<f30fec3dd46443e6b1b9baf6a59c4ef0@dehamex2013.europe.flane.local>
Message-ID: <b848a183102345ab9dba8e24b3bb6d22@dehamex2013.europe.flane.local>

Nevermind, 

I missed the new settings in domain.xml :)

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] Im Auftrag von Marc Tempelmeier
Gesendet: Wednesday, July 5, 2017 10:10 AM
An: stian at redhat.com; keycloak-user <keycloak-user at lists.jboss.org>
Betreff: Re: [keycloak-user] Keycloak 3.2.0.Final Released

Hi,

I get the following error with the new version in Domain Controlled Mode:

slave3_1            | [Server:slave3] 08:08:40,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "keycloak-server.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.ValidatorFactory is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.ModuleName is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.deployment.unit.\"keycloak-server.war\".jca.cachedConnectionManagerSetupProcessor is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.InAppClientContainer is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.app.auth is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.concurrent.ee.context.config.auth.auth is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.InstanceName is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.deployment.unit.\"keycloak-server.war\".INSTALL is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.module.auth.auth.Validator is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.naming.context.java.app.auth.AppName is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]",
slave3_1            | [Server:slave3]     "jboss.deployment.unit.\"keycloak-server.war\".ejb3.client-context.registration-service is missing [jboss.infinispan.keycloak.actionTokens, jboss.infinispan.keycloak.authenticationSessions]"

BR

Marc

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] Im Auftrag von Stian Thorgersen
Gesendet: Wednesday, July 5, 2017 9:40 AM
An: keycloak-user <keycloak-user at lists.jboss.org>
Betreff: [keycloak-user] Keycloak 3.2.0.Final Released

Keycloak 3.2.0.Final has just been released.

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

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

Before you upgrade remember to backup your database and check the migration guide <https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
.
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

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


From tdudgeon.ml at gmail.com  Wed Jul  5 05:24:20 2017
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Wed, 5 Jul 2017 10:24:20 +0100
Subject: [keycloak-user] reverse proxy woes
Message-ID: <476026f2-9022-a73f-34b3-fa1f569c009c@gmail.com>

Hi All,

I'm having a problem with running keycloak behind an nginx reverse proxy.

I've had this running for some time now without problems, but have now 
stood up a new system in a networking environment that I don't have much 
control over, and for some reason things are not working.

My nginx proxy forwarding looks like this:

     location /auth/ {
         proxy_pass                http://keycloak:8080/auth/;
         proxy_set_header        Host $host;
         proxy_set_header        X-Real-IP $remote_addr;
         proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header        X-Forwarded-Proto $scheme;
         proxy_redirect            off;
         proxy_connect_timeout    75s;
     }

Similar for the app that is using keycloak for SSO (this is a tomcat 
based servlet app).

In my keycloak's standalone.xml the http-listener element has had 
proxy-address-forwarding="true" added.
This has all been fine, but in this new environment its not working.

I get the keycloak login prompt, and can login OK. But when I look in 
the session in Keycloack the From IP address is 10.0.0.10 not the actual 
IP address of the machine where the browser resides.

And the app using Keycloak denies access with this exception in the logs:

05-Jul-2017 08:53:31.679 ERROR [http-nio-8080-exec-4] 
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode failed to 
turn code into token
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668)
at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532)
at 
org.keycloak.adapters.SniSSLSocketFactory.connectSocket(SniSSLSocketFactory.java:109)
at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at 
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
at 
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107)
at 
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:327)
at 
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:273)
at 
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:130)
at 
org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:206)
at 
org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve.authenticate(KeycloakAuthenticatorValve.java:48)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:471)
at 
org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.invoke(AbstractKeycloakAuthenticatorValve.java:187)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
at 
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:240)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

Can anyone shed any light on what might be wrong here?
Note this is using quite an old version of keycloak (2.1.0) though I 
don't think this is the problem.

Thanks

Tim



From thomas.darimont at googlemail.com  Wed Jul  5 05:38:21 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 5 Jul 2017 11:38:21 +0200
Subject: [keycloak-user] reverse proxy woes
In-Reply-To: <476026f2-9022-a73f-34b3-fa1f569c009c@gmail.com>
References: <476026f2-9022-a73f-34b3-fa1f569c009c@gmail.com>
Message-ID: <CAK-7U1gs7BMiyEadpQ9zyySJgbxLeA1NfmZoDLLneAEDjjahKw@mail.gmail.com>

Hi Tim,

did you specify proxy-address-forwarding="true" for the <http-listener>
element in the undertow subsystem of you standalone(-ha).xml?
https://keycloak.gitbooks.io/documentation/server_installation/topics/clustering/load-balancer.html

Cheers,
Thomas

2017-07-05 11:24 GMT+02:00 Tim Dudgeon <tdudgeon.ml at gmail.com>:

> Hi All,
>
> I'm having a problem with running keycloak behind an nginx reverse proxy.
>
> I've had this running for some time now without problems, but have now
> stood up a new system in a networking environment that I don't have much
> control over, and for some reason things are not working.
>
> My nginx proxy forwarding looks like this:
>
>      location /auth/ {
>          proxy_pass                http://keycloak:8080/auth/;
>          proxy_set_header        Host $host;
>          proxy_set_header        X-Real-IP $remote_addr;
>          proxy_set_header        X-Forwarded-For
> $proxy_add_x_forwarded_for;
>          proxy_set_header        X-Forwarded-Proto $scheme;
>          proxy_redirect            off;
>          proxy_connect_timeout    75s;
>      }
>
> Similar for the app that is using keycloak for SSO (this is a tomcat
> based servlet app).
>
> In my keycloak's standalone.xml the http-listener element has had
> proxy-address-forwarding="true" added.
> This has all been fine, but in this new environment its not working.
>
> I get the keycloak login prompt, and can login OK. But when I look in
> the session in Keycloack the From IP address is 10.0.0.10 not the actual
> IP address of the machine where the browser resides.
>
> And the app using Keycloak denies access with this exception in the logs:
>
> 05-Jul-2017 08:53:31.679 ERROR [http-nio-8080-exec-4]
> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode failed to
> turn code into token
> java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:
> 350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(
> AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(
> SSLSocketFactory.java:532)
> at
> org.keycloak.adapters.SniSSLSocketFactory.connectSocket(
> SniSSLSocketFactory.java:109)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(
> SSLSocketFactory.java:409)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(
> DefaultClientConnectionOperator.java:177)
> at
> org.apache.http.impl.conn.AbstractPoolEntry.open(
> AbstractPoolEntry.java:144)
> at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(
> AbstractPooledConnAdapter.java:131)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(
> DefaultRequestDirector.java:611)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(
> DefaultRequestDirector.java:446)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(
> AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(
> CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(
> CloseableHttpClient.java:107)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(
> CloseableHttpClient.java:55)
> at
> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(
> ServerRequest.java:107)
> at
> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(
> OAuthRequestAuthenticator.java:327)
> at
> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(
> OAuthRequestAuthenticator.java:273)
> at
> org.keycloak.adapters.RequestAuthenticator.authenticate(
> RequestAuthenticator.java:130)
> at
> org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorV
> alve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:206)
> at
> org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve.authenticate(
> KeycloakAuthenticatorValve.java:48)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(
> AuthenticatorBase.java:471)
> at
> org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.invoke(
> AbstractKeycloakAuthenticatorValve.java:187)
> at
> org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.authenticator.SingleSignOn.
> invoke(SingleSignOn.java:240)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:521)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(
> AbstractHttp11Processor.java:1096)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
> process(AbstractProtocol.java:674)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> doRun(NioEndpoint.java:1500)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
> run(NioEndpoint.java:1456)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> Can anyone shed any light on what might be wrong here?
> Note this is using quite an old version of keycloak (2.1.0) though I
> don't think this is the problem.
>
> Thanks
>
> Tim
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From thomas.darimont at googlemail.com  Wed Jul  5 05:39:36 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 5 Jul 2017 11:39:36 +0200
Subject: [keycloak-user] reverse proxy woes
In-Reply-To: <CAK-7U1gs7BMiyEadpQ9zyySJgbxLeA1NfmZoDLLneAEDjjahKw@mail.gmail.com>
References: <476026f2-9022-a73f-34b3-fa1f569c009c@gmail.com>
	<CAK-7U1gs7BMiyEadpQ9zyySJgbxLeA1NfmZoDLLneAEDjjahKw@mail.gmail.com>
Message-ID: <CAK-7U1hfs9vipO_dDT78T5Aedijsv5qjx=xFW=i3cdPmwb4KTg@mail.gmail.com>

... never mind - I missed the part in your email...

2017-07-05 11:38 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hi Tim,
>
> did you specify proxy-address-forwarding="true" for the <http-listener>
> element in the undertow subsystem of you standalone(-ha).xml?
> https://keycloak.gitbooks.io/documentation/server_installation/topics/
> clustering/load-balancer.html
>
> Cheers,
> Thomas
>
> 2017-07-05 11:24 GMT+02:00 Tim Dudgeon <tdudgeon.ml at gmail.com>:
>
>> Hi All,
>>
>> I'm having a problem with running keycloak behind an nginx reverse proxy.
>>
>> I've had this running for some time now without problems, but have now
>> stood up a new system in a networking environment that I don't have much
>> control over, and for some reason things are not working.
>>
>> My nginx proxy forwarding looks like this:
>>
>>      location /auth/ {
>>          proxy_pass                http://keycloak:8080/auth/;
>>          proxy_set_header        Host $host;
>>          proxy_set_header        X-Real-IP $remote_addr;
>>          proxy_set_header        X-Forwarded-For
>> $proxy_add_x_forwarded_for;
>>          proxy_set_header        X-Forwarded-Proto $scheme;
>>          proxy_redirect            off;
>>          proxy_connect_timeout    75s;
>>      }
>>
>> Similar for the app that is using keycloak for SSO (this is a tomcat
>> based servlet app).
>>
>> In my keycloak's standalone.xml the http-listener element has had
>> proxy-address-forwarding="true" added.
>> This has all been fine, but in this new environment its not working.
>>
>> I get the keycloak login prompt, and can login OK. But when I look in
>> the session in Keycloack the From IP address is 10.0.0.10 not the actual
>> IP address of the machine where the browser resides.
>>
>> And the app using Keycloak denies access with this exception in the logs:
>>
>> 05-Jul-2017 08:53:31.679 ERROR [http-nio-8080-exec-4]
>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode failed to
>> turn code into token
>> java.net.ConnectException: Connection refused
>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>> at
>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>> etImpl.java:350)
>> at
>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>> ainSocketImpl.java:206)
>> at
>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>> Impl.java:188)
>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>> at java.net.Socket.connect(Socket.java:589)
>> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668)
>> at
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLS
>> ocketFactory.java:532)
>> at
>> org.keycloak.adapters.SniSSLSocketFactory.connectSocket(SniS
>> SLSocketFactory.java:109)
>> at
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLS
>> ocketFactory.java:409)
>> at
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.
>> openConnection(DefaultClientConnectionOperator.java:177)
>> at
>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoo
>> lEntry.java:144)
>> at
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(Abs
>> tractPooledConnAdapter.java:131)
>> at
>> org.apache.http.impl.client.DefaultRequestDirector.tryConnec
>> t(DefaultRequestDirector.java:611)
>> at
>> org.apache.http.impl.client.DefaultRequestDirector.execute(D
>> efaultRequestDirector.java:446)
>> at
>> org.apache.http.impl.client.AbstractHttpClient.doExecute(Abs
>> tractHttpClient.java:882)
>> at
>> org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>> eableHttpClient.java:82)
>> at
>> org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>> eableHttpClient.java:107)
>> at
>> org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>> eableHttpClient.java:55)
>> at
>> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(
>> ServerRequest.java:107)
>> at
>> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(
>> OAuthRequestAuthenticator.java:327)
>> at
>> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate
>> (OAuthRequestAuthenticator.java:273)
>> at
>> org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>> estAuthenticator.java:130)
>> at
>> org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorVa
>> lve.authenticateInternal(AbstractKeycloakAuthenticatorValve.java:206)
>> at
>> org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve.auth
>> enticate(KeycloakAuthenticatorValve.java:48)
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
>> uthenticatorBase.java:471)
>> at
>> org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorVa
>> lve.invoke(AbstractKeycloakAuthenticatorValve.java:187)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHo
>> stValve.java:141)
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
>> rtValve.java:79)
>> at
>> org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abs
>> tractAccessLogValve.java:616)
>> at
>> org.apache.catalina.authenticator.SingleSignOn.invoke(
>> SingleSignOn.java:240)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(Standard
>> EngineValve.java:88)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAd
>> apter.java:521)
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(Abs
>> tractHttp11Processor.java:1096)
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
>> .process(AbstractProtocol.java:674)
>> at
>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>> (NioEndpoint.java:1500)
>> at
>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(
>> NioEndpoint.java:1456)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.
>> run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> Can anyone shed any light on what might be wrong here?
>> Note this is using quite an old version of keycloak (2.1.0) though I
>> don't think this is the problem.
>>
>> Thanks
>>
>> Tim
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From marc.tempelmeier at flane.de  Wed Jul  5 06:20:09 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Wed, 5 Jul 2017 10:20:09 +0000
Subject: [keycloak-user] Failed executing GET /admin/realms:
 org.jboss.resteasy.spi.UnauthorizedException: Bearer
Message-ID: <fa55f5d67b7c495989df28c639b725b5@dehamex2013.europe.flane.local>

Hi,

now to a real problem :)

We have a 3 Node cluster, I always the error after login, sometimes directly at the login. I promptly got logged out.
It?s basicly this error: https://issues.jboss.org/browse/KEYCLOAK-3586
But we get it on login to admin console.

Any ideas? 

[Server:slave3] 10:14:09,847 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-2) RESTEASY002005: Failed executing GET /admin/realms: org.jboss.resteasy.spi.UnauthorizedException: Bearer
[Server:slave3]         at org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:180)
[Server:slave3]         at org.keycloak.services.resources.admin.AdminRoot.getRealmsAdmin(AdminRoot.java:211)
[Server:slave3]         at sun.reflect.GeneratedMethodAccessor376.invoke(Unknown Source)
[Server:slave3]         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[Server:slave3]         at java.lang.reflect.Method.invoke(Method.java:498)
[Server:slave3]         at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79)
[Server:slave3]         at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58)
[Server:slave3]         at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
[Server:slave3]         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
[Server:slave3]         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
[Server:slave3]         at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
[Server:slave3]         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
[Server:slave3]         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
[Server:slave3]         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
[Server:slave3]         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
[Server:slave3]         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
[Server:slave3]         at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
[Server:slave3]         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[Server:slave3]         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[Server:slave3]         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
[Server:slave3]         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
[Server:slave3]         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[Server:slave3]         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
[Server:slave3]         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[Server:slave3]         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
[Server:slave3]         at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
[Server:slave3]         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[Server:slave3]         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
[Server:slave3]         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[Server:slave3]         at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
[Server:slave3]         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
[Server:slave3]         at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
[Server:slave3]         at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
[Server:slave3]         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[Server:slave3]         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
[Server:slave3]         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[Server:slave3]         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[Server:slave3]         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
[Server:slave3]         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
[Server:slave3]         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
[Server:slave3]         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
[Server:slave3]         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
[Server:slave3]         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
[Server:slave3]         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:slave3]         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:slave3]         at java.lang.Thread.run(Thread.java:748)



From federico at info.nl  Wed Jul  5 07:33:52 2017
From: federico at info.nl (Federico Navarro Polo - Info.nl)
Date: Wed, 5 Jul 2017 11:33:52 +0000
Subject: [keycloak-user] Internal System Error on screens when a code is
	expired
Message-ID: <63F53E4C-3933-4C90-A137-DB30CD000EA5@info.nl>

Hello,

There are some screens / links generated by Keycloak that make use of an authorization code, like registration link, forgotten password link, verification link, etc. When those codes expire or a code is already used, the feedback to the user will be just an Internal Server Error screen.

This is not very user friendly, since the user doesn?t know what he has done wrong (eg: a simple refresh on the register page will trigger the issue). I wonder if there is a simple way to modify this behavior, and for instance show a different error message informing of the actual problem (eg: the code is invalid. Please go to {link} to restart the process), or this is really a new functionality to be requested to the Keycloak team via JIRA.



Regards,
Federico

From galserg at gmail.com  Wed Jul  5 08:16:46 2017
From: galserg at gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCT0LDQu9GO0LfQuNC9?=)
Date: Wed, 5 Jul 2017 15:16:46 +0300
Subject: [keycloak-user] keycloak saml logout
Message-ID: <CAPabm0bDxvafAeZ=1Wph37JkkiBrFtaG=4EAuH3-HHZA5FhK3A@mail.gmail.com>

hi all!

i try use Keycloak as IDP for gitlab via SAML protocol.
autentification is work well.
but i can't configure integration with logout service
gillab can redirect user after logout to customizable url
if it redirect to main SAML entry point (
root/realms/{realm}/protocol/saml/) i see error "invalid request"
if i try type anybody to field "Logout Service POST Binding URL" and
redirect to this url - i see error 404 or blank screen.
In the documentation this service is practically not described.

Is there a standard entry point for logout servise (like standart SSO point
root/realms/{realm}/protocol/saml/clients/{url name}) ?

From galserg at gmail.com  Wed Jul  5 12:17:43 2017
From: galserg at gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCT0LDQu9GO0LfQuNC9?=)
Date: Wed, 5 Jul 2017 19:17:43 +0300
Subject: [keycloak-user] saml logout
Message-ID: <CAPabm0bv6PaOx9pY0qF1uNDq=jihHUZueuXpo-L6Ef9677zVVg@mail.gmail.com>

hi all!

i try use Keycloak as IDP for gitlab via SAML protocol.
autentification is work well.
but i can't configure integration with logout service
gillab can redirect user after logout to customizable url
if it redirect to main SAML entry point ( root/realms/{realm}/protocol/saml/)
i see error "invalid request"
if i try type anybody to field "Logout Service POST Binding URL" and
redirect to this url - i see error 404 or blank screen.
In the documentation this service is practically not described.

Is there a standard entry point for logout servise (like standart SSO point
root/realms/{realm}/protocol/saml/clients/{url name}) ?

From sthorger at redhat.com  Wed Jul  5 14:35:36 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 20:35:36 +0200
Subject: [keycloak-user] Internal System Error on screens when a code is
	expired
In-Reply-To: <63F53E4C-3933-4C90-A137-DB30CD000EA5@info.nl>
References: <63F53E4C-3933-4C90-A137-DB30CD000EA5@info.nl>
Message-ID: <CAJgngAf2TN6wDk9yyuTyvCYzd=GoNDU3Bd0YPiGq61jTbdXMZw@mail.gmail.com>

Try 3.2 there's been improvements around this

On 5 July 2017 at 13:33, Federico Navarro Polo - Info.nl <federico at info.nl>
wrote:

> Hello,
>
> There are some screens / links generated by Keycloak that make use of an
> authorization code, like registration link, forgotten password link,
> verification link, etc. When those codes expire or a code is already used,
> the feedback to the user will be just an Internal Server Error screen.
>
> This is not very user friendly, since the user doesn?t know what he has
> done wrong (eg: a simple refresh on the register page will trigger the
> issue). I wonder if there is a simple way to modify this behavior, and for
> instance show a different error message informing of the actual problem
> (eg: the code is invalid. Please go to {link} to restart the process), or
> this is really a new functionality to be requested to the Keycloak team via
> JIRA.
>
>
>
> Regards,
> Federico
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From jasonspittel at yahoo.com  Wed Jul  5 14:40:48 2017
From: jasonspittel at yahoo.com (Jason Spittel)
Date: Wed, 5 Jul 2017 18:40:48 +0000 (UTC)
Subject: [keycloak-user] SAML HttpServletRequest.logout() support
References: <1263738321.6142511.1499280048359.ref@mail.yahoo.com>
Message-ID: <1263738321.6142511.1499280048359@mail.yahoo.com>

I'm having trouble with SAML Logout. ?I have a JEE app that uses Keycloak as an identity broker to ADFS.
Following these instructions:Logout | Keycloak Documentation


| 
| 
|  | 
Logout | Keycloak Documentation


 |

 |

 |



I should be able to just call HttpServletRequest.logout(). But that doesn't do anything.
Searching Jira I see this a reported issue.
[KEYCLOAK-2191] SAML HttpServletRequest.logout() support - JBoss Issue Tracker


| 
| 
|  | 
[KEYCLOAK-2191] SAML HttpServletRequest.logout() support - JBoss Issue T...


 |

 |

 |



While that's being worked on, are there workarounds to do a SAML logout through Keycloak?

Thanks,
Jason

From mitya at cargosoft.ru  Wed Jul  5 16:54:19 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Wed, 05 Jul 2017 23:54:19 +0300
Subject: [keycloak-user] Permission related issues in 3.2.0
Message-ID: <1499288059.2978.1.camel@cargosoft.ru>

Hi,
After upgrade to 3.2.0, I've noticed the following issues that may all
be permissions-related:
* in 3.2.0, if you create a (non-master) realm, add a user, assign
realm-management.realm-admin client role, click impersonate (or simply
relogin) to access the account page - in the Applications tab you'll
see only Account itself, and neither Security Admin Console nor Admin
CLI like in 3.1.0. This is a bit confusing since the user?actually is
able to access admin console and CLI;
* in 3.2.0, if you log in as a master realm admin, create a role in a
non-master realm, turn it into composite and try to add roles to it,
you'll get an exception:
23:12:52,654 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
task-12) RESTEASY002005: Failed executing POST
/admin/realms/foobar/roles-by-id/3e38af68-5aef-482c-868e-
461f12e11592/composites: org.keycloak.services.ForbiddenException	
at
org.keycloak.services.resources.admin.permissions.RolePermissions.requi
reMapComposite(RolePermissions.java:383)	at
org.keycloak.services.resources.admin.RoleResource.addComposites(RoleRe
source.java:70)	at
org.keycloak.services.resources.admin.RoleByIdResource.addComposites(Ro
leByIdResource.java:161)
I didn't manage to find a working combination of permissions to solve
this. Anyway, one might expect this to work out of the box, like it
used to in 3.1.0.
Dmitry

From mitya at cargosoft.ru  Wed Jul  5 17:10:29 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Thu, 06 Jul 2017 00:10:29 +0300
Subject: [keycloak-user] LDAP attributes & caching
Message-ID: <1499289029.2978.3.camel@cargosoft.ru>

Hi,

I've got a LDAP federation configured with Import Users = ON and
mappers like firstName/lastName having Always Read Value From LDAP =
ON.

If the corresponding attribute is changed in LDAP, it will show
immediately in the "View all users" list. However, it won't be
reflected in user details, top-right corner or account page until user
cache is cleared.

Dmitry


From john.bartko at drillinginfo.com  Wed Jul  5 19:37:00 2017
From: john.bartko at drillinginfo.com (John Bartko)
Date: Wed, 5 Jul 2017 23:37:00 +0000
Subject: [keycloak-user] saml logout
In-Reply-To: <CAPabm0bv6PaOx9pY0qF1uNDq=jihHUZueuXpo-L6Ef9677zVVg@mail.gmail.com>
References: <CAPabm0bv6PaOx9pY0qF1uNDq=jihHUZueuXpo-L6Ef9677zVVg@mail.gmail.com>
Message-ID: <BL2PR18MB076941774E430475F09C819388D40@BL2PR18MB0769.namprd18.prod.outlook.com>

This GitLab issue [1] seems relevant. It may be the case that GitLab does not support SAML SP-initiated global logout at this time.


You mentioned that GitLab can redirect users to a URI after performing its own logout procedure. This problem then seems to be another instance of KEYCLOAK-3476 [2], i.e. GitLab may be a SAML SP that cannot process LogoutRequest messages but does offer arbitrary redirection. In theory, GitLab can redirect to the OIDC Logout Endpoint [3] which would destroy the Keycloak IdP session that was initially started by a SAML client.


Here's a *major* catch -- In my experience with Keycloak v1.9.8.Final, once an invalid configuration has be placed in the "Logout Service POST Binding URL" field for SAML clients lacking LogoutRequest support, that client is now "polluted" and must be deleted and recreated before GLO will work! Subsequently blanking the field would result in Keycloak throwing NPEs. I cannot speak to whether this behaviour is present in more recent versions of Keycloak.


Hope that helps,

-John Bartko


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/25854

[2] https://issues.jboss.org/browse/KEYCLOAK-3476

[3] <https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/oidc-generic.html> https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/oidc-generic.html#_logout_endpoint

________________________________
From: keycloak-user-bounces at lists.jboss.org <keycloak-user-bounces at lists.jboss.org> on behalf of ?????? ??????? <galserg at gmail.com>
Sent: Wednesday, July 5, 2017 11:17:43 AM
To: keycloak-user at lists.jboss.org
Subject: [keycloak-user] saml logout

hi all!

i try use Keycloak as IDP for gitlab via SAML protocol.
autentification is work well.
but i can't configure integration with logout service
gillab can redirect user after logout to customizable url
if it redirect to main SAML entry point ( root/realms/{realm}/protocol/saml/)
i see error "invalid request"
if i try type anybody to field "Logout Service POST Binding URL" and
redirect to this url - i see error 404 or blank screen.
In the documentation this service is practically not described.

Is there a standard entry point for logout servise (like standart SSO point
root/realms/{realm}/protocol/saml/clients/{url name}) ?
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user<https://lists.jboss.org/mailman/listinfo/keycloak-user>

From thomas_connolly at yahoo.com  Wed Jul  5 23:27:09 2017
From: thomas_connolly at yahoo.com (Thomas Connolly)
Date: Thu, 6 Jul 2017 03:27:09 +0000 (UTC)
Subject: [keycloak-user] Direct Connect API call results in JWT with missing
	idtoken?
References: <1331295271.6505433.1499311629505.ref@mail.yahoo.com>
Message-ID: <1331295271.6505433.1499311629505@mail.yahoo.com>

Hi All

I've just raised the following ticket for a potential bug in KC 3.2.0.Final and KC 3.2.0.CR1. 
https://issues.jboss.org/browse/KEYCLOAK-5145

I'd really appreciate if you could determine if I've missed something or there is an actual bug.
As per bug description using an unconfigured KC.

Regards 
Tom Connolly.

From sthorger at redhat.com  Thu Jul  6 02:08:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 6 Jul 2017 08:08:57 +0200
Subject: [keycloak-user] Direct Connect API call results in JWT with
 missing idtoken?
In-Reply-To: <1331295271.6505433.1499311629505@mail.yahoo.com>
References: <1331295271.6505433.1499311629505.ref@mail.yahoo.com>
	<1331295271.6505433.1499311629505@mail.yahoo.com>
Message-ID: <CAJgngAekkgCzAGcmq-_Pga3GcLBAZOQqpdHk_z1tC2E57TeJjA@mail.gmail.com>

Please check the migration guide before upgrading
https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html

You need to add scope=openid otherwise the ID token won't be returned and
it will be counted as an OAuth2 request rather than an OpenID Connect
request.

On 6 July 2017 at 05:27, Thomas Connolly <thomas_connolly at yahoo.com> wrote:

> Hi All
>
> I've just raised the following ticket for a potential bug in KC
> 3.2.0.Final and KC 3.2.0.CR1.
> https://issues.jboss.org/browse/KEYCLOAK-5145
>
> I'd really appreciate if you could determine if I've missed something or
> there is an actual bug.
> As per bug description using an unconfigured KC.
>
> Regards
> Tom Connolly.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From mitya at cargosoft.ru  Thu Jul  6 06:46:06 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Thu, 06 Jul 2017 13:46:06 +0300
Subject: [keycloak-user] Permission related issues in 3.2.0
In-Reply-To: <1499288059.2978.1.camel@cargosoft.ru>
References: <1499288059.2978.1.camel@cargosoft.ru>
Message-ID: <1499337966.2966.1.camel@cargosoft.ru>

https://issues.jboss.org/browse/KEYCLOAK-5152
https://issues.jboss.org/browse/KEYCLOAK-5155


From mitya at cargosoft.ru  Thu Jul  6 06:46:27 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Thu, 06 Jul 2017 13:46:27 +0300
Subject: [keycloak-user] LDAP attributes & caching
In-Reply-To: <1499289029.2978.3.camel@cargosoft.ru>
References: <1499289029.2978.3.camel@cargosoft.ru>
Message-ID: <1499337987.2966.2.camel@cargosoft.ru>

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


From antoine at saagie.com  Thu Jul  6 08:55:29 2017
From: antoine at saagie.com (Antoine Carton)
Date: Thu, 6 Jul 2017 14:55:29 +0200
Subject: [keycloak-user] AdapterTokenStore: automatic refresh token
Message-ID: <CAMghK0ZcukoG3q=pqHe-gaEZMJGTqL_KcvQW70unbvqM1E5hwQ@mail.gmail.com>

Hello,

I have implemented an org.keycloak.adapters.AdapterTokenStore, like the
existing ones, for example:

- org.keycloak.adapters.jetty.core.JettyCookieTokenStore (from
keycloak-jetty-core 3.1.0.Final)
- org.keycloak.adapters.jetty.core.JettySessionTokenStore (from
keycloak-jetty-core 3.1.0.Final)

The purpose is that these AdapterTokenStores refresh the current access
token with the refreshToken they have stored, and then update the
org.keycloak.adapters.RefreshableKeycloakSecurityContext (see
refreshExpiredToken() of this context) with a new token.

All of this is triggered thanks to the checkCurrentToken, called in
org.keycloak.adapters.jetty.core.AbstractKeycloakJettyAuthenticator.

The trouble is that the current "Authorization" header of the Request
object is not updated with the new token.

Therefore, even if the security context has a new token, the current
request failed because of the old token that is still in the Authorization
header (the check is done in
BearerTokenRequestAuthenticator.authenticate(HttpFacade exchange)).

Any idea how to solve this issue? Does it mean the request must be done
twice even if the token is refreshed?
Otherwise, the alternative I see is to have a proxy that will be in charge
of refreshing the token by modifying the request header.

Thanks!

From inofi at gmx.net  Thu Jul  6 11:21:09 2017
From: inofi at gmx.net (Malte Finsterwalder)
Date: Thu, 6 Jul 2017 17:21:09 +0200
Subject: [keycloak-user] Fwd: Kerberos Authentication throws Exception
In-Reply-To: <0d8e7bae-a4b5-2b59-96f4-634e2635bc8e@finsterwalder.name>
References: <0d8e7bae-a4b5-2b59-96f4-634e2635bc8e@finsterwalder.name>
Message-ID: <CALS12-OE6mxooa5nF12hsa9k4Q--kHKOyRMXC0YywaLy1QDxGw@mail.gmail.com>

Hi there,

I tried to configure Keycloak to authenticate against Windows Active
Directory using Kerberos credentials.
But I keep getting an Exception.

Setup is as follows:

I created a docker image based on jboss/keycloak-ha-postgres:2.5.5.Final.
In addition I installed freeipa-client and added a /etc/krb5.conf file as
well as my keytab file.

But when I configure Kerberos as required in the browser flow, I get the
following Exception and the browser shows me a basic auth login dialog,
that does not allow me to log in at all.

Any ideas? How can gather more information?

13:26:25,796 INFO  [stdout] (default task-64) Debug is  true storeKey true
useTicketCache false useKeyTab true doNotPrompt true ticketCache is null
isInitiator false KeyTab is /keytabs/SVC_KEYCLOAK_CI20_HTTP_IDP-UI.keytab
refreshKrb5Config is false principal is HTTP/SVC_KEYCLOAK_CI20.HH.
HANSEMERKUR.DE at HH.HANSEMERKUR.DE tryFirstPass is false useFirstPass is
false storePass is false clearPass is false
13:26:25,796 INFO  [stdout] (default task-64) principal is
HTTP/SVC_KEYCLOAK_CI20.HH.HANSEMERKUR.DE at HH.HANSEMERKUR.DE
13:26:25,796 INFO  [stdout] (default task-64) Will use keytab
13:26:25,796 INFO  [stdout] (default task-64) Commit Succeeded
13:26:25,796 INFO  [stdout] (default task-64)

13:19:24,501 WARN  [org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator]
(default task-47) SPNEGO login failed: java.security.PrivilegedActionException:
GSSException: Defective token detected (Mechanism level: GSSHeader did not
find the right tag)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.authenticate(
SPNEGOAuthenticator.java:68)
at org.keycloak.storage.ldap.LDAPStorageProvider.authenticate(
LDAPStorageProvider.java:542)
at org.keycloak.credential.UserCredentialStoreManager.authenticate(
UserCredentialStoreManager.java:323)
at org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.
authenticate(SpnegoAuthenticator.java:90)
at org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(
DefaultAuthenticationFlow.java:184)
at org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(
AuthenticationProcessor.java:792)
at org.keycloak.authentication.AuthenticationProcessor.authenticate(
AuthenticationProcessor.java:667)
at org.keycloak.protocol.AuthorizationEndpointBase.
handleBrowserAuthenticationRequest(AuthorizationEndpointBase.java:123)
at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.
buildAuthorizationCodeAuthorizationResponse(AuthorizationEndpoint.java:317)
at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.build(
AuthorizationEndpoint.java:125)
at sun.reflect.GeneratedMethodAccessor615.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(
MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(
ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(
ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(
ResourceLocatorInvoker.java:138)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
ResourceLocatorInvoker.java:107)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(
ResourceLocatorInvoker.java:133)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
ResourceLocatorInvoker.java:101)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(
SynchronousDispatcher.java:395)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(
SynchronousDispatcher.java:202)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.
service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(
HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(
HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(
ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
doFilter(FilterHandler.java:129)
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(
KeycloakSessionServletFilter.java:90)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(
FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.
handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(
ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHand
ler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(
PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandl
er.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandl
er.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(
PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler
.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstrai
ntHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandle
r.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand
ler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(
NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssocia
tionHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(
PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.
handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(
PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(
PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(
ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(
ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$
000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(
ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(
ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: GSSException: Defective token detected (Mechanism level:
GSSHeader did not find the right tag)
at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97)
at sun.security.jgss.GSSContextImpl.acceptSecContext(
GSSContextImpl.java:306)
at sun.security.jgss.GSSContextImpl.acceptSecContext(
GSSContextImpl.java:285)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.
establishContext(SPNEGOAuthenticator.java:172)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$
AcceptSecContext.run(SPNEGOAuthenticator.java:135)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$
AcceptSecContext.run(SPNEGOAuthenticator.java:125)
... 60 more

13:26:25,798 INFO  [stdout] (default task-64)         [Krb5LoginModule]:
Entering logout
13:26:25,798 INFO  [stdout] (default task-64)         [Krb5LoginModule]:
logged out Subject

From petervn1 at yahoo.com  Thu Jul  6 12:10:47 2017
From: petervn1 at yahoo.com (Peter Nalyvayko)
Date: Thu, 6 Jul 2017 16:10:47 +0000 (UTC)
Subject: [keycloak-user] Identity provider,
	keycloak js adapter and session management
References: <1621377393.5523009.1499357447224.ref@mail.yahoo.com>
Message-ID: <1621377393.5523009.1499357447224@mail.yahoo.com>

Hi,

We've hit a bit of a snag while setting up our one page js client. Changing the value of the "sub" claim to anything other than the unique identifier of the keycloak user causes the keycloak adapter to detect the changes to the session and clear out the tokens, forcing the users to re-log in after every 5 seconds. 
 
We are using the version 2.3.0 of keycloak. Our app is set up to use keycloak.js adapter for all things related to OIDC. The adapter is configured to use the "code authorization" (standard) flow. The instance of keycloak is configured to use an external OIDC identity provider and the users are uniquely identified by their e-mails. Naturally, we wanted that the "sub" claim in the claim set returned by calling the keycloak's OIDC /token endpoint would return the unique identity of the external user rather than the internal identifier of the keycloak user, so we re-configured the keycloak client by adding a property mapper to map the user's email to the "sub" claim, here the example of the access token: 
{
   "sub": "user at company.com",
   "iat": 223235098325,
   "email": "user at company.com",
   ...
} 

Once we had implemented these changes on the keycloak side, our users were able to initially sign into the application, but when they tried to access any functionality within the app, they would be prompted to sign in again. The problem seems to related to the OIDC session management and the assumption and the "sub" claim always matches the keycloak user's unique identifier. 

We narrowed the problem down to four components:

- keycloak.js
- login-status-iframe.html
- services\srv\main\java\org\keycloak\protocol\oidc\endpoints\LoginStatusIframeEndpoint.java
- services\src\main\java\org\keycloak\services\managers\AuthenticationManager.java
 
In keycloak.js, line 637, the implementation creates a session id to be used to check the session state. Notice that the code uses the value from the "sub" claim: 
   var sessionId = kc.realm + "/" + kc.tokenParsed.sub;
  
In AuthenticationManager.createLoginCookie, line 306, the value of the "SESSION_COOKIE" is set to:

  String sessionCookieValue = realm.getName() + "/" + user.getId();

Sadly, in our configuration, the value returned of by user.getId() is not the same as the value stored in the "sub" claim, thus causing the session management code in login-status-iframe.html, line 53 to clear out any tokens and force the users to re-login the next time it checks the session state (default is 5 second intervals):

  var cookie = getCookie();
  if (sessionState == cookie) { ... } else { callback("changed"); }  

 
Looking at the LoginStatusIframeEndpoint.preCheck (LoginSatusIframeEndpoint.java, lines 71-93), we've noticed that the implementation does not even make use of the user identity, only the session id.

The workaround, at least temporary, for us was to add the "id" claim containing the user identity internal to keycloak, and modify the keycloak JS adapter code to look for the "id" claim and use its value instead of the value in the "sub" claim when creating the session id, i.e.:

  
   var sessionId;
   if (kc.tokenParsed.id) {
      sessionId = kc.realm + "/" + kc.tokenParsed.id;
   } else {
      sessionId = kc.realm + "/" + kc.tokenParsed.sub;
   }

Is this a bug, or does it work as intended, i.e. the users should never set the "sub" claim to anything other than the keycloak's user identity? If this is a bug, I can submit a JIRA request and a fix as long as the workaround above seems like an acceptable solution

Any comments are welcome
Regards,
Peter

From inofi at gmx.net  Thu Jul  6 13:19:35 2017
From: inofi at gmx.net (Malte Finsterwalder)
Date: Thu, 6 Jul 2017 19:19:35 +0200
Subject: [keycloak-user] Understanding "Server Principal" in Kerberos setup
Message-ID: <CALS12-PeEoHOH4xJxrWWApRvq5Q3ZU+2kDm3CRi_CJ=5hT6n4Q@mail.gmail.com>

Hi there,

I'm trying to set up Keycloak to use Kerberos with Active Directory.
But I'm not sure, I understand the Server Principal correctly.

Keycloak is running on a server, that is reachable under
keycloak.some.domain.com
The Kerberos Realm is whatever.else.com

So is the Server Principal correctly specified as:

HTTP/keycloak.some.domain.com at whatever.else.com

Or more general HTTP/<CLIENT HOST>@<Kerberos Realm>

And is <Kerberos Realm> in the Server Principal always the same as stated
in "Kerberos Realm" in the admin ui?

And does case matter anywhere?

Greetings,
    Malte

From inofi at gmx.net  Thu Jul  6 13:26:09 2017
From: inofi at gmx.net (Malte Finsterwalder)
Date: Thu, 6 Jul 2017 19:26:09 +0200
Subject: [keycloak-user] Kerberos Authentication throws Exception
In-Reply-To: <CALS12-OE6mxooa5nF12hsa9k4Q--kHKOyRMXC0YywaLy1QDxGw@mail.gmail.com>
References: <0d8e7bae-a4b5-2b59-96f4-634e2635bc8e@finsterwalder.name>
	<CALS12-OE6mxooa5nF12hsa9k4Q--kHKOyRMXC0YywaLy1QDxGw@mail.gmail.com>
Message-ID: <CALS12-NG8aJRCQHRbF62ARj0LD+Emy1kjNuriho09yEbtYKyQA@mail.gmail.com>

I tweaked my config a bit and fixed an error there. It still doesn't work
correctly, but now I get an ICMP Error, after the SPNEGO Failure and a try
to login with username and password;

17:23:54,184 INFO  [stdout] (default task-21) [Krb5LoginModule]
authentication failed
17:23:54,184 INFO  [stdout] (default task-21) ICMP Port Unreachable
17:23:54,185 WARN  [org.keycloak.services] (default task-21)
KC-SERVICES0013: Failed authentication: org.keycloak.models.ModelException:
Kerberos unreachable
at
org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.checkKerberosServerAvailable(KerberosUsernamePasswordAuthenticator.java:108)
at
org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.validUser(KerberosUsernamePasswordAuthenticator.java:94)
at
org.keycloak.storage.ldap.LDAPStorageProvider.validPassword(LDAPStorageProvider.java:512)
at
org.keycloak.storage.ldap.LDAPStorageProvider.isValid(LDAPStorageProvider.java:602)
at
org.keycloak.credential.UserCredentialStoreManager.validate(UserCredentialStoreManager.java:140)
at
org.keycloak.credential.UserCredentialStoreManager.isValid(UserCredentialStoreManager.java:121)
at
org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validatePassword(AbstractUsernameFormAuthenticator.java:175)
at
org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validateUserAndPassword(AbstractUsernameFormAuthenticator.java:151)
at
org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.validateForm(UsernamePasswordForm.java:56)
at
org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.action(UsernamePasswordForm.java:49)
at
org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:92)
at
org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:76)
at
org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:759)
at
org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:365)
at
org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:347)
at
org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:401)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.security.auth.login.LoginException: ICMP Port Unreachable
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:808)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
at
org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.authenticateSubject(KerberosUsernamePasswordAuthenticator.java:128)
at
org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.validUser(KerberosUsernamePasswordAuthenticator.java:90)
... 61 more
Caused by: java.net.PortUnreachableException: ICMP Port Unreachable
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
at
java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
at java.net.DatagramSocket.receive(DatagramSocket.java:812)
at sun.security.krb5.internal.UDPClient.receive(NetClient.java:206)
at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:411)
at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:364)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.krb5.KdcComm.send(KdcComm.java:348)
at sun.security.krb5.KdcComm.sendIfPossible(KdcComm.java:253)
at sun.security.krb5.KdcComm.send(KdcComm.java:229)
at sun.security.krb5.KdcComm.send(KdcComm.java:200)
at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316)
at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:766)
... 75 more


On 6 July 2017 at 17:21, Malte Finsterwalder <inofi at gmx.net> wrote:

> Hi there,
>
> I tried to configure Keycloak to authenticate against Windows Active
> Directory using Kerberos credentials.
> But I keep getting an Exception.
>
> Setup is as follows:
>
> I created a docker image based on jboss/keycloak-ha-postgres:2.5.5.Final.
> In addition I installed freeipa-client and added a /etc/krb5.conf file as
> well as my keytab file.
>
> But when I configure Kerberos as required in the browser flow, I get the
> following Exception and the browser shows me a basic auth login dialog,
> that does not allow me to log in at all.
>
> Any ideas? How can gather more information?
>
> 13:26:25,796 INFO  [stdout] (default task-64) Debug is  true storeKey true
> useTicketCache false useKeyTab true doNotPrompt true ticketCache is null
> isInitiator false KeyTab is /keytabs/SVC_KEYCLOAK_CI20_HTTP_IDP-UI.keytab
> refreshKrb5Config is false principal is HTTP/SVC_KEYCLOAK_CI20.HH.HANS
> EMERKUR.DE at HH.HANSEMERKUR.DE tryFirstPass is false useFirstPass is false
> storePass is false clearPass is false
> 13:26:25,796 INFO  [stdout] (default task-64) principal is
> HTTP/SVC_KEYCLOAK_CI20.HH.HANSEMERKUR.DE at HH.HANSEMERKUR.DE
> 13:26:25,796 INFO  [stdout] (default task-64) Will use keytab
> 13:26:25,796 INFO  [stdout] (default task-64) Commit Succeeded
> 13:26:25,796 INFO  [stdout] (default task-64)
>
> 13:19:24,501 WARN  [org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator]
> (default task-47) SPNEGO login failed: java.security.PrivilegedActionException:
> GSSException: Defective token detected (Mechanism level: GSSHeader did not
> find the right tag)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.au
> thenticate(SPNEGOAuthenticator.java:68)
> at org.keycloak.storage.ldap.LDAPStorageProvider.authenticate(L
> DAPStorageProvider.java:542)
> at org.keycloak.credential.UserCredentialStoreManager.authentic
> ate(UserCredentialStoreManager.java:323)
> at org.keycloak.authentication.authenticators.browser.SpnegoAut
> henticator.authenticate(SpnegoAuthenticator.java:90)
> at org.keycloak.authentication.DefaultAuthenticationFlow.proces
> sFlow(DefaultAuthenticationFlow.java:184)
> at org.keycloak.authentication.AuthenticationProcessor.authenti
> cateOnly(AuthenticationProcessor.java:792)
> at org.keycloak.authentication.AuthenticationProcessor.authenti
> cate(AuthenticationProcessor.java:667)
> at org.keycloak.protocol.AuthorizationEndpointBase.handleBrowse
> rAuthenticationRequest(AuthorizationEndpointBase.java:123)
> at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.b
> uildAuthorizationCodeAuthorizationResponse(AuthorizationEndpoint.java:317)
> at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.
> build(AuthorizationEndpoint.java:125)
> at sun.reflect.GeneratedMethodAccessor615.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje
> ctorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget
> (ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc
> eMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTarge
> tObject(ResourceLocatorInvoker.java:138)
> at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Resour
> ceLocatorInvoker.java:107)
> at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTarge
> tObject(ResourceLocatorInvoker.java:133)
> at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Resour
> ceLocatorInvoker.java:101)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
> nousDispatcher.java:395)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
> nousDispatcher.java:202)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
> spatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
> her.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
> her.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
> rvletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
> oFilter(FilterHandler.java:129)
> at org.keycloak.services.filters.KeycloakSessionServletFilter.d
> oFilter(KeycloakSessionServletFilter.java:90)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
> oFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
> terHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHan
> dler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handl
> eRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssoc
> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
> redicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociat
> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationC
> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
> redicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler
> .handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentiality
> ConstraintHandler.handleRequest(ServletConfident
> ialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandle
> r.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.ha
> ndleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssocia
> tionHandler.handleRequest(AbstractSecurityContextAssociation
> Handler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
> redicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
> ndler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
> redicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
> redicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
> stRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
> equest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
> 0(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
> equest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
> ge.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
> Executor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
> lExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: GSSException: Defective token detected (Mechanism level:
> GSSHeader did not find the right tag)
> at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContext
> Impl.java:306)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContext
> Impl.java:285)
> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.es
> tablishContext(SPNEGOAuthenticator.java:172)
> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$Ac
> ceptSecContext.run(SPNEGOAuthenticator.java:135)
> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$Ac
> ceptSecContext.run(SPNEGOAuthenticator.java:125)
> ... 60 more
>
> 13:26:25,798 INFO  [stdout] (default task-64)         [Krb5LoginModule]:
> Entering logout
> 13:26:25,798 INFO  [stdout] (default task-64)         [Krb5LoginModule]:
> logged out Subject
>
>

From glavoie at gmail.com  Thu Jul  6 14:45:05 2017
From: glavoie at gmail.com (Gabriel Lavoie)
Date: Thu, 6 Jul 2017 14:45:05 -0400
Subject: [keycloak-user] LDAP User Federation: Issue with Hardcoded Roles
Message-ID: <CAKp1Nw6owuPz7oHt8KRWDGM_k6s3eMX9q3PnSFDmHEbkLqmoOQ@mail.gmail.com>

Hi,
     I've been trying to setup a LDAP user federation with a hardcoded
admin role on Keycloak 2.1.0.Final, on the master realm. The role is
granted to the user as expected, but not the composite roles attached to
the "admin" role.

I tried reproducing the issue with the latest Keycloak but encountered a
different problem. When I try to add the hardcoded role mapper and add the
"admin" role to it, the role displays as "a" in the field (after
selection), and I get an error on save. I get the following exception in
the log:

2017-07-06 14:43:36,727 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-18) RESTEASY002005: Failed executing POST
/admin/realms/master/components: org.jboss.resteasy.spi.ReaderException:
com.fasterxml.jackson.databind.JsonMappingException: Can not deserialize
instance of java.util.ArrayList out of VALUE_STRING token
 at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 1611369f;
line: 1, column: 12] (through reference chain:
org.keycloak.representations.idm.ComponentRepresentation["config"]->org.keycloak.common.util.MultivaluedHashMap["role"])
        at
org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:184)
        at
org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:91)
        at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:114)
        at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
        at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
        at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
        at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
        at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
        at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
        at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
        at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
        at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
        at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
        at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
        at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
        at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
        at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
        at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
        at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
        at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
        at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
        at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
        at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
        at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
        at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
        at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
        at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
        at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Can not
deserialize instance of java.util.ArrayList out of VALUE_STRING token
 at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 1611369f;
line: 1, column: 12] (through reference chain:
org.keycloak.representations.idm.ComponentRepresentation["config"]->org.keycloak.common.util.MultivaluedHashMap["role"])
        at
com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:148)
        at
com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:835)
        at
com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:831)
        at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.handleNonArray(StringCollectionDeserializer.java:240)
        at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:171)
        at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:161)
        at
com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:19)
        at
com.fasterxml.jackson.databind.deser.std.MapDeserializer._readAndBindStringMap(MapDeserializer.java:485)
        at
com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:342)
        at
com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:26)
        at
com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:523)
        at
com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:95)
        at
com.fasterxml.jackson.databind.deser.impl.BeanPropertyMap.findDeserializeAndSet(BeanPropertyMap.java:285)
        at
com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:248)
        at
com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:136)
        at
com.fasterxml.jackson.databind.ObjectReader._bind(ObjectReader.java:1410)
        at
com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:860)
        at
org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.readFrom(ResteasyJackson2Provider.java:121)
        at
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:61)
        at
org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:60)
        at
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53)
        at
org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:34)
        at
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:55)
        at
org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59)
        at
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:55)
        at
org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:151)
        ... 48 more


Any idea of what could be wrong? Bug?

Thank you,

Gabriel

-- 
Gabriel Lavoie
glavoie at gmail.com

From lists at merit.unu.edu  Thu Jul  6 17:15:51 2017
From: lists at merit.unu.edu (mj)
Date: Thu, 6 Jul 2017 23:15:51 +0200
Subject: [keycloak-user] Understanding "Server Principal" in Kerberos
 setup
In-Reply-To: <CALS12-PeEoHOH4xJxrWWApRvq5Q3ZU+2kDm3CRi_CJ=5hT6n4Q@mail.gmail.com>
References: <CALS12-PeEoHOH4xJxrWWApRvq5Q3ZU+2kDm3CRi_CJ=5hT6n4Q@mail.gmail.com>
Message-ID: <3903e380-1a10-8ee7-8376-792e0bf29021@merit.unu.edu>

Hi,

I can only say that what I did, is add

"HTTP/keycloak.some.domain.com" to the AD account.

After exporting, the principal looks like:

HTTP/keycloak.some.domain.com at WHATEVER.ELSE.COM

I'm not sure if the upper case REALM matters.

Hope that helps,

MJ

On 07/06/2017 07:19 PM, Malte Finsterwalder wrote:
> Hi there,
> 
> I'm trying to set up Keycloak to use Kerberos with Active Directory.
> But I'm not sure, I understand the Server Principal correctly.
> 
> Keycloak is running on a server, that is reachable under
> keycloak.some.domain.com
> The Kerberos Realm is whatever.else.com
> 
> So is the Server Principal correctly specified as:
> 
> HTTP/keycloak.some.domain.com at whatever.else.com
> 
> Or more general HTTP/<CLIENT HOST>@<Kerberos Realm>
> 
> And is <Kerberos Realm> in the Server Principal always the same as stated
> in "Kerberos Realm" in the admin ui?
> 
> And does case matter anywhere?
> 
> Greetings,
>      Malte
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 

From akaya at expedia.com  Fri Jul  7 00:58:38 2017
From: akaya at expedia.com (Sarp Kaya)
Date: Fri, 7 Jul 2017 04:58:38 +0000
Subject: [keycloak-user] Keycloak very slow on retrieving "events"
In-Reply-To: <CAJgngAeu5BvdD0f-DZnbExbvO1mNnK6eDdQ6xsq5huRJjiqbZg@mail.gmail.com>
References: <BAC94174-F401-4448-BD5D-B19DCD842454@expedia.com>
	<CAJgngAeZHTHACc8sdFw_Uw3oVgw-1tKjZ02AVDCbyqau-Pp8=w@mail.gmail.com>
	<A14BE085-CCB4-40F2-94FD-807ECDCD2CC7@expedia.com>
	<CAJgngAeu5BvdD0f-DZnbExbvO1mNnK6eDdQ6xsq5huRJjiqbZg@mail.gmail.com>
Message-ID: <41473CD9-CF89-41E6-9051-6F569ED09429@expedia.com>

Hey again,

I checked the database there were 14 million events. After running some basic queries I noticed that even basic count query would take around 4 minutes.

One thing I realised is, if you want an instant result, you can use LIMIT, because UI uses 0-5 etc. it can definitely make use of it to make this faster.

How I fixed is by adding an index on Event_time:


 CREATE INDEX `idx_EVENT_ENTITY_EVENT_TIME`  ON `keycloak`.`EVENT_ENTITY` (EVENT_TIME) COMMENT '' ALGORITHM DEFAULT LOCK DEFAULT;


Now it works really quick. I am not going to create a ticket, but if you wish, you can add this to your liquibase for the next updates.


Thanks,

Sarp

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Wednesday, July 5, 2017 at 3:29 PM
To: Abdullah Sarp <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Keycloak very slow on retrieving "events"

Can you create a bug report please? Include as much info as you can so it's easy for us to reproduce the problem (how many events you have, what the query is you're running, etc..)

On 5 July 2017 at 01:10, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Yes, I have a lot of events, but I thought it shouldn?t matter when picking the first 5 events.

Thanks,
Sarp

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Wednesday, July 5, 2017 at 3:56 AM
To: Abdullah Sarp <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Keycloak very slow on retrieving "events"

That's not good, it should be much quicker than that. Do you have a lot of events?

On 4 July 2017 at 08:41, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Hello,

When I click on Events, it takes very long time (more than a minute) just to display first 5 events. I checked what endpoint it uses and it?s using this:

"/auth/admin/realms/<realm-id>/events?first=0&max=5? endpoint.

I believe that there is something broken with the filtering option as it should never take more than a minute to just retrieve 5 results.

I?m using Keycloak 3.1.0 and MySQL for the database.
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user



From steindl.bernhard94 at gmail.com  Fri Jul  7 06:16:31 2017
From: steindl.bernhard94 at gmail.com (Bernhard Steindl)
Date: Fri, 7 Jul 2017 12:16:31 +0200
Subject: [keycloak-user] Access Query Parameter in FreeMarker Template -
	Keycloak 2.1.0
Message-ID: <710618DE-5D82-4114-9C2F-D3992F48BD57@gmail.com>

Hello,

I must access Query Parameters passed to my keycloak login theme.

Neither was I able to obtain them using 

RequestParameters.paramName nor
request.getParameter(paramName)
	
in the login FreeMarker template.

Everytime I access a query parameter using these methods I get an FreeMarker error

2017-07-06 13:32:07,917 ERROR [freemarker.runtime] (default task-12) Error executing FreeMarker template: 
freemarker.core.InvalidReferenceException: The following has evaluated to null or missing

I also found that there is an url object visible which provides a few keys to access.

I am using Keycloak 2.1.0 which includes a FreeMarker jar version 2.3.20.


Can anybody support me in this issue?
I need to use query params to dynamically display information on the login theme.

Kind Regards,
Bernhard

From petervn1 at yahoo.com  Fri Jul  7 12:06:50 2017
From: petervn1 at yahoo.com (Peter Nalyvayko)
Date: Fri, 7 Jul 2017 16:06:50 +0000 (UTC)
Subject: [keycloak-user] Identity provider,
	keycloak js adapter and session management
References: <1727835614.580304.1499443610670.ref@mail.yahoo.com>
Message-ID: <1727835614.580304.1499443610670@mail.yahoo.com>

Some additional info: we can also reproduce the same behavior using the Pairwise subject identifier, i.e. users keep getting logged out after 5 seconds. 

--------------------------------------------
On Thu, 7/6/17, Peter Nalyvayko <petervn1 at yahoo.com> wrote:

 Subject: Identity provider, keycloak js adapter and session management
 To: keycloak-user at lists.jboss.org
 Date: Thursday, July 6, 2017, 12:10 PM
 
 Hi,
 
 We've hit a bit of a snag while setting
 up our one page js client. Changing the value of the "sub"
 claim to anything other than the unique identifier of the
 keycloak user causes the keycloak adapter to detect the
 changes to the session and clear out the tokens, forcing the
 users to re-log in after every 5 seconds. 
  
 We are using the version 2.3.0 of
 keycloak. Our app is set up to use keycloak.js adapter for
 all things related to OIDC. The adapter is configured to use
 the "code authorization" (standard) flow. The instance of
 keycloak is configured to use an external OIDC identity
 provider and the users are uniquely identified by their
 e-mails. Naturally, we wanted that the "sub" claim in the
 claim set returned by calling the keycloak's OIDC /token
 endpoint would return the unique identity of the external
 user rather than the internal identifier of the keycloak
 user, so we re-configured the keycloak client by adding a
 property mapper to map the user's email to the "sub" claim,
 here the example of the access token: 
 {
 ?  "sub": "user at company.com",
 ?  "iat": 223235098325,
 ?  "email": "user at company.com",
 ?  ...
 } 
 
 Once we had implemented these changes
 on the keycloak side, our users were able to initially sign
 into the application, but when they tried to access any
 functionality within the app, they would be prompted to sign
 in again. The problem seems to related to the OIDC session
 management and the assumption and the "sub" claim always
 matches the keycloak user's unique identifier. 
 
 We narrowed the problem down to four
 components:
 
 - keycloak.js
 - login-status-iframe.html
 -
 services\srv\main\java\org\keycloak\protocol\oidc\endpoints\LoginStatusIframeEndpoint.java
 -
 services\src\main\java\org\keycloak\services\managers\AuthenticationManager.java
  
 In keycloak.js, line 637, the
 implementation creates a session id to be used to check the
 session state. Notice that the code uses the value from the
 "sub" claim: 
 ?  var sessionId = kc.realm + "/"
 + kc.tokenParsed.sub;
 ? 
 In
 AuthenticationManager.createLoginCookie, line 306, the value
 of the "SESSION_COOKIE" is set to:
 
 ? String sessionCookieValue =
 realm.getName() + "/" + user.getId();
 
 Sadly, in our configuration, the value
 returned of by user.getId() is not the same as the value
 stored in the "sub" claim, thus causing the session
 management code in login-status-iframe.html, line 53 to
 clear out any tokens and force the users to re-login the
 next time it checks the session state (default is 5 second
 intervals):
 
 ? var cookie = getCookie();
 ? if (sessionState == cookie) {
 ... } else { callback("changed"); }? 
 
  
 Looking at the
 LoginStatusIframeEndpoint.preCheck
 (LoginSatusIframeEndpoint.java, lines 71-93), we've noticed
 that the implementation does not even make use of the user
 identity, only the session id.
 
 The workaround, at least temporary, for
 us was to add the "id" claim containing the user identity
 internal to keycloak, and modify the keycloak JS adapter
 code to look for the "id" claim and use its value instead of
 the value in the "sub" claim when creating the session id,
 i.e.:
 
 ? 
 ?  var sessionId;
 ?  if (kc.tokenParsed.id) {
 ? ? ? sessionId =
 kc.realm + "/" + kc.tokenParsed.id;
 ?  } else {
 ? ? ? sessionId =
 kc.realm + "/" + kc.tokenParsed.sub;
 ?  }
 
 Is this a bug, or does it work as
 intended, i.e. the users should never set the "sub" claim to
 anything other than the keycloak's user identity? If this is
 a bug, I can submit a JIRA request and a fix as long as the
 workaround above seems like an acceptable solution
 
 Any comments are welcome
 Regards,
 Peter
 


From nicolaouantonia at gmail.com  Fri Jul  7 15:29:00 2017
From: nicolaouantonia at gmail.com (Antonia Nicolaou)
Date: Fri, 7 Jul 2017 22:29:00 +0300
Subject: [keycloak-user] redhat sso get baseurl in custom theme for email
	registration
Message-ID: <CADQwdOpK9TX3qu0wHngKjbnW+EzbyQN81Uyypmv1DKFpWg1k1g@mail.gmail.com>

Hello all,



Your help would be greatly appreciated.


I am using single sign on service from redhat v7.1 and I am developing a
custom template (in a custom theme) for registration email. In the email,
Unfortunately, I didn?t find the proper way to get the client baseUrl or
the url.registrationUrl  .

Could you please help me?



Thank you in advanced.

Sincerely,

Antonia Nicolaou

From James.P.Mcshane at healthpartners.com  Fri Jul  7 16:33:40 2017
From: James.P.Mcshane at healthpartners.com (Mcshane, James P)
Date: Fri, 7 Jul 2017 20:33:40 +0000
Subject: [keycloak-user] Keycloak Spring Boot Bearer Authentication
Message-ID: <B4CED3EC-BD9C-451C-B45E-37666C1894FB@healthpartners.com>

I am working on a set of Spring Boot modules all within the same Realm in Keycloak. I would like the service to have bearer only authentication so that the service can only be accessed by authorized clients. For the spring-security adapter, I see the KeycloakRestTemplate, but the factory there requires the SecurityContextHolder, which isn?t present out of the box in the authentication mechanism for the spring-boot adapter.

Is there a different rest template that could use the different container auth solutions provided by the KeycloakAutoConfiguration class? Clearly accessing the bearer authentication values from these systems is app server dependent, so it would seem to make sense to have a KeycloakClientRequestFactory provider that can handle the different types of container auth that is being done by the spring-boot adapter. Has this been done already, but not yet documented? In either case, I would be happy to contribute docs or code that deals with these different implementations.
Thanks,

James

________________________________

This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited.

If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. Disclaimer R001.0

From dennishonders at gmail.com  Sun Jul  9 15:49:30 2017
From: dennishonders at gmail.com (Dennis H)
Date: Sun, 9 Jul 2017 21:49:30 +0200
Subject: [keycloak-user] Jboss-modules.jar missing
Message-ID: <CALfiJ8bvGTe64quAMYqsHCmjPEymp_muroC3-bjyfmm_4Fci1A@mail.gmail.com>

Hi,

Today I downloaded Keycloak 3.2.0.Final (zip). When running the
standalone.bat, the jboss-modules.jar is missing.
Do you know about this?

I also have another question. What is a good way to handle authorization,
so a user can only edit, for example, his own profile. How to retrieve the
incomming token, get the user_id and verify it in, in this case, the
ProfileComponent? I'm currently using Java Spring Boot as backend (bearer
only).

Thanks,

Dennis

From postmaster at lists.jboss.org  Mon Jul 10 00:08:11 2017
From: postmaster at lists.jboss.org (Automatic Email Delivery Software)
Date: Mon, 10 Jul 2017 09:38:11 +0530
Subject: [keycloak-user] jmpi
Message-ID: <201707100408.v6A48FlT011272@lists01.dmz-a.mwc.hst.phx2.redhat.com>

This message was undeliverable due to the following reason:

Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 1 days:
Host 153.195.58.206 is not responding.

The following recipients did not receive this message:
<keycloak-user at lists.jboss.org>

Please reply to postmaster at lists.jboss.org
if you feel this message to be in error.


From sthorger at redhat.com  Mon Jul 10 01:04:28 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 10 Jul 2017 07:04:28 +0200
Subject: [keycloak-user] Jboss-modules.jar missing
In-Reply-To: <CALfiJ8bvGTe64quAMYqsHCmjPEymp_muroC3-bjyfmm_4Fci1A@mail.gmail.com>
References: <CALfiJ8bvGTe64quAMYqsHCmjPEymp_muroC3-bjyfmm_4Fci1A@mail.gmail.com>
Message-ID: <CAJgngAcCksY8Uy=9ro=pTm0HAg2WD+KhOxkkTASed8S2b-VVwQ@mail.gmail.com>

On 9 July 2017 at 21:49, Dennis H <dennishonders at gmail.com> wrote:

> Hi,
>
> Today I downloaded Keycloak 3.2.0.Final (zip). When running the
> standalone.bat, the jboss-modules.jar is missing.
> Do you know about this?
>

Can you give some more details? jboss-modules.jar is there.


>
> I also have another question. What is a good way to handle authorization,
> so a user can only edit, for example, his own profile. How to retrieve the
> incomming token, get the user_id and verify it in, in this case, the
> ProfileComponent? I'm currently using Java Spring Boot as backend (bearer
> only).
>
> Thanks,
>
> Dennis
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From sblanc at redhat.com  Mon Jul 10 02:17:00 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 10 Jul 2017 08:17:00 +0200
Subject: [keycloak-user] Keycloak Spring Boot Bearer Authentication
In-Reply-To: <B4CED3EC-BD9C-451C-B45E-37666C1894FB@healthpartners.com>
References: <B4CED3EC-BD9C-451C-B45E-37666C1894FB@healthpartners.com>
Message-ID: <CAMZCGg95s5FmZM+2qg9qUWJW1mDRLtZk-tgLWasn-iYPxt+qoQ@mail.gmail.com>

Hi,

We don't have this currently for the Spring Boot Adapter and it would be
great if you could contribute on this, could you also please open a jira
ticket for that on https://issues.jboss.org/browse/KEYCLOAK ?


On Fri, Jul 7, 2017 at 10:33 PM, Mcshane, James P <
James.P.Mcshane at healthpartners.com> wrote:

> I am working on a set of Spring Boot modules all within the same Realm in
> Keycloak. I would like the service to have bearer only authentication so
> that the service can only be accessed by authorized clients. For the
> spring-security adapter, I see the KeycloakRestTemplate, but the factory
> there requires the SecurityContextHolder, which isn?t present out of the
> box in the authentication mechanism for the spring-boot adapter.
>
> Is there a different rest template that could use the different container
> auth solutions provided by the KeycloakAutoConfiguration class? Clearly
> accessing the bearer authentication values from these systems is app server
> dependent, so it would seem to make sense to have a
> KeycloakClientRequestFactory provider that can handle the different types
> of container auth that is being done by the spring-boot adapter. Has this
> been done already, but not yet documented? In either case, I would be happy
> to contribute docs or code that deals with these different implementations.
> Thanks,
>
> James
>
> ________________________________
>
> This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to whom they are
> addressed. If you are not the intended recipient or the individual
> responsible for delivering the e-mail to the intended recipient, please be
> advised that you have received this e-mail in error and that any use,
> dissemination, forwarding, printing, or copying of this e-mail is strictly
> prohibited.
>
> If you have received this communication in error, please return it to the
> sender immediately and delete the original message and any copy of it from
> your computer system. If you have any questions concerning this message,
> please contact the sender. Disclaimer R001.0
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From nicolaouantonia at gmail.com  Mon Jul 10 02:21:37 2017
From: nicolaouantonia at gmail.com (Antonia Nicolaou)
Date: Mon, 10 Jul 2017 09:21:37 +0300
Subject: [keycloak-user] redhat sso get baseurl in custom theme for email
	registration
Message-ID: <CADQwdOqqRzOUOEwevzN6DKX1b39HUu06foAgD4ZgZ_8qV15qrQ@mail.gmail.com>

Hello all,



Your help would be greatly appreciated.


I am using single sign on service from redhat v7.1 and I am developing a
custom template (in a custom theme) for registration email. In the email,
Unfortunately, I didn?t find the proper way to get the client baseUrl or
the url.registrationUrl  .

Could you please help me?



Thank you in advanced.

Sincerely,

Antonia Nicolaou

From marc.tempelmeier at flane.de  Mon Jul 10 03:27:34 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Mon, 10 Jul 2017 07:27:34 +0000
Subject: [keycloak-user] Domain Clustered Mode
Message-ID: <8a8b4107cc1842ae9aa51b240d6cb278@dehamex2013.europe.flane.local>

Hi,

Is there anyone here who has this working with 1 Master and 2-3 Slaves on Version 3.2.0? 

I frequently get 2 errors:

Error 1 (results in unregistering the slave):

Position: 22
[Server:slave1]     Caused by: liquibase.exception.DatabaseException: Error executing SQL select count(*) from public.databasechangeloglock: ERROR: relation \"public.databasechangeloglock\" does not exist
[Server:slave1]   Position: 22
[Server:slave1]     Caused by: org.postgresql.util.PSQLException: ERROR: relation \"public.databasechangeloglock\" does not exist


Error 2 (results in immediate logout, sometimes after 1 sec or later):

10:08:22,066 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-18) RESTEASY002005: Failed executing GET /admin/realms: org.jboss.resteasy.spi.UnauthorizedException: Bearer

If anyone has a working config, it would be really great to share :)

Best regards

Marc Tempelmeier


From hmlnarik at redhat.com  Mon Jul 10 09:09:12 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 10 Jul 2017 15:09:12 +0200
Subject: [keycloak-user] Problems logging out using JEE to keycloak to
 SAML (ADFS) (better formatted)
In-Reply-To: <2140990500.5387792.1499205110788@mail.yahoo.com>
References: <2140990500.5387792.1499205110788.ref@mail.yahoo.com>
	<2140990500.5387792.1499205110788@mail.yahoo.com>
Message-ID: <CAMvXD=GippnWuNH_XZFaeJjyoJuhZJpor8egbgaMwwAKzSLG4w@mail.gmail.com>

How are ADFS and Keycloak configured? If according to [1], the
sessions should be cleared. Beware that ADFS also leaves ssoCookie in
the browser so that it might just relogin the user behind the scenes,
see discussion on [2] for further details.

--Hynek

[1] http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as-brokered.html
[2] https://issues.jboss.org/browse/KEYCLOAK-4398

On Tue, Jul 4, 2017 at 11:51 PM, Jason Spittel <jasonspittel at yahoo.com> wrote:
> Apparently my formatting was lost. So I'm reposting this in a more readable format:
>
> Hello,
>
> I'm having difficulty completing a logout.
> SETUP:
> JEE webapp to keycloak to IdP (ADFS (SAML))
>
> WORKFLOW:
> 1) On logout in the webapp
> externalContext.redirect(externalContext.getRequestContextPath() + "?GLO=true");
>
> 2) User is sent to ADFS letting them know they have successfully logged out.
>
> 3) However, there is still a keycloak user session alive (seen in the admin console)
>
> 4) Hitting a protected resource in the webapp lets user in without having to log back in.
>
> Debugging the keycloak server, I found this bit of code in AuthenticationManager.browserLogout() line 262:
>
> String brokerId = userSession.getNote(Details.IDENTITY_PROVIDER);
>
> if (brokerId != null) {
>    IdentityProvider identityProvider = IdentityBrokerService.getIdentityProvider(session, realm, brokerId);
>    Response response = identityProvider.keycloakInitiatedBrowserLogout(session, userSession, uriInfo, realm);
>    if (response != null) return response;
> }
>
> return finishBrowserLogout(session, realm, userSession, uriInfo, connection, headers);
>
> I think, unless I'm misunderstanding it, that I need to hit the finishBrowserLogout method, to clear the keycloak user session.
> But the way this is written makes it so it never will. Is keycloak expecting ADFS to clear its user session? Am I logging out incorrectly?
> Thanks,
> Jason
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From t.ruiten at rdmedia.com  Mon Jul 10 10:04:22 2017
From: t.ruiten at rdmedia.com (Tiemen Ruiten)
Date: Mon, 10 Jul 2017 16:04:22 +0200
Subject: [keycloak-user] illegal character in path when testing email setup
Message-ID: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>

Hello,

I get the following error when hitting the 'Test connection' button on the
email tab in Realm settings:

2017-07-10 15:55:27,316 INFO  [org.jboss.as] (Controller Boot Thread)
WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* started in
21731ms - Started 449 of 824 services (561 services are lazy, passive or
on-demand)
2017-07-10 15:56:48,997 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-11) RESTEASY002130: Failed to parse request.:
javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to create URI:
https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
"port":null,"host":"mail.rdmedia.com
","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
at
org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(ResteasyUriBuilder.java:749)
at
org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(ResteasyUriBuilder.java:721)
at
org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUriInfo.java:58)
at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInfo.java:53)
at
org.jboss.resteasy.plugins.server.servlet.ServletUtil.extractUriInfo(ServletUtil.java:41)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:200)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.URISyntaxException: Illegal character in path at index
67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
"port":null,"host":"mail.rdmedia.com
","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parseHierarchical(URI.java:3105)
at java.net.URI$Parser.parse(URI.java:3053)
at java.net.URI.<init>(URI.java:588)
at
org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(ResteasyUriBuilder.java:744)
... 40 more

The 67th character is the slash after testSMTPConnection. Is this a bug
and/or is there a workaround/fix?

-- 
Tiemen Ruiten
Systems Engineer
R&D Media

From jasonspittel at yahoo.com  Mon Jul 10 10:44:52 2017
From: jasonspittel at yahoo.com (Jason Spittel)
Date: Mon, 10 Jul 2017 14:44:52 +0000 (UTC)
Subject: [keycloak-user] Problems logging out using JEE to keycloak to
 SAML (ADFS) (better formatted)
In-Reply-To: <CAMvXD=GippnWuNH_XZFaeJjyoJuhZJpor8egbgaMwwAKzSLG4w@mail.gmail.com>
References: <2140990500.5387792.1499205110788.ref@mail.yahoo.com>
	<2140990500.5387792.1499205110788@mail.yahoo.com>
	<CAMvXD=GippnWuNH_XZFaeJjyoJuhZJpor8egbgaMwwAKzSLG4w@mail.gmail.com>
Message-ID: <1621105909.2492952.1499697892635@mail.yahoo.com>

Hi Hynek,
My setup is exactly from that tutorial. And I found the problem with logging out, I'm not sure how to report the issue (not sure if it's really a KC issue at all), raise a Jira ticket?
Setup:JEE app running JSF calling EJBs.JEE app using wildfly keycloak saml adapters to talk to Keycloak (KC)Keycloak setup to use ADFS as its IdP.
Problem:JEE app needs to logout twice to logout. (That is, after first logout, you can still hit the protected resource on the JEE app without logging in again)
Cause:1) first logout:- JSF's redirects (externalContext.redirect(externalContext.getRequestContextPath() + "/?GLO=true" );) removes the jsessionId cookie, which causes an initial auth from JEE to KC when logout is hit.?-rest of logout proceeds properly, Realm Session ID is removed from KC, ADFS logs use out.2) second logout-JSF's redirect again removes the jsessionId cookie, tries to do an initial auth from JEE to KC, but KC doesn't have any sessions to auth user with, and user is kicked out, 'successfully' logging out.
Solution:preserve the jsessionid on redirect, initial auth to KC doesn't occur on logout.
? ?public void logout() throws IOException, ServletException
?? {
??????ExternalContext externalContext = _context.getExternalContext();

??????try
??????{
? ? ? ? ?externalContext.invalidateSession();

???????? _httpRequest.logout();
??????}
??????catch (Exception ex)
??????{
???????? _logger.error(ex);
??????}
??????finally
??????{
???????? // need to set the cookie for the jsessionid, or will re-auth with KC, and will require two logouts to logout completely
???????? preserveJsessionidCookie(externalContext);

???????? externalContext.redirect(externalContext.getRequestContextPath() + "/?GLO=true" );
??????}
?? }

?? private void preserveJsessionidCookie(ExternalContext externalContext)
?? {
??????for (Cookie cookie : ((HttpServletRequest)externalContext.getRequest()).getCookies())
??????{
???????? if (cookie.getName().equalsIgnoreCase("jsessionid"))
???????? {
????????????((HttpServletResponse)externalContext.getResponse()).addCookie(cookie);
????????????break;
???????? }
??????}
?? }

Cheers,
JasonOn Monday, July 10, 2017, 6:09:36 AM PDT, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

How are ADFS and Keycloak configured? If according to [1], the
sessions should be cleared. Beware that ADFS also leaves ssoCookie in
the browser so that it might just relogin the user behind the scenes,
see discussion on [2] for further details.

--Hynek

[1] http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as-brokered.html
[2] https://issues.jboss.org/browse/KEYCLOAK-4398

On Tue, Jul 4, 2017 at 11:51 PM, Jason Spittel <jasonspittel at yahoo.com> wrote:
> Apparently my formatting was lost. So I'm reposting this in a more readable format:
>
> Hello,
>
> I'm having difficulty completing a logout.
> SETUP:
> JEE webapp to keycloak to IdP (ADFS (SAML))
>
> WORKFLOW:
> 1) On logout in the webapp
> externalContext.redirect(externalContext.getRequestContextPath() + "?GLO=true");
>
> 2) User is sent to ADFS letting them know they have successfully logged out.
>
> 3) However, there is still a keycloak user session alive (seen in the admin console)
>
> 4) Hitting a protected resource in the webapp lets user in without having to log back in.
>
> Debugging the keycloak server, I found this bit of code in AuthenticationManager.browserLogout() line 262:
>
> String brokerId = userSession.getNote(Details.IDENTITY_PROVIDER);
>
> if (brokerId != null) {
>? ? IdentityProvider identityProvider = IdentityBrokerService.getIdentityProvider(session, realm, brokerId);
>? ? Response response = identityProvider.keycloakInitiatedBrowserLogout(session, userSession, uriInfo, realm);
>? ? if (response != null) return response;
> }
>
> return finishBrowserLogout(session, realm, userSession, uriInfo, connection, headers);
>
> I think, unless I'm misunderstanding it, that I need to hit the finishBrowserLogout method, to clear the keycloak user session.
> But the way this is written makes it so it never will. Is keycloak expecting ADFS to clear its user session? Am I logging out incorrectly?
> Thanks,
> Jason
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From shimin_q at yahoo.com  Mon Jul 10 11:56:47 2017
From: shimin_q at yahoo.com (shimin q)
Date: Mon, 10 Jul 2017 15:56:47 +0000 (UTC)
Subject: [keycloak-user] keycloak APIs to retrieve logged-in user
References: <1827862300.2313151.1499702207109.ref@mail.yahoo.com>
Message-ID: <1827862300.2313151.1499702207109@mail.yahoo.com>

Hi,?
I am new to keycloak (sorry if the answer to my question seems obvious!). ?We plan to use keycloak to secure a bunch of web apps, some written in Java, some in JavaScript (with React). ??
After the user is logged in by keycloak, each of those web apps needs to retrieve the user that is logged in and the realm/client roles that the user has. ?
   
   - For Java apps, we tried the keycloak Java API (request -> KeycloakSecurityContext -> getIdToken -> getPreferredUsername/getOtherClaims). ? They seem to work fine

   
   - For JavaScript apps, we are hitting roadblocks. ? What APIs would you recommend to use specifically? ?Do you have any example code for JavaScript apps? ? Tried the following code, but could not get Keycloak to init successfully (Note this is in web app code after the user is already authenticated by keycloak, the app is only trying to retrieve who logged in with what roles):   


var kc = Keycloak({????url: 'https://135.112.123.194:8666/auth',????realm: 'rtna',????clientId: 'main'});?//var kc = Keycloak('./keycloak.json'); //this does not work as it can't find the keycloak.json file under WEB-INF//kc.loadUserInfo();var userid = kc.subject;console.log("user id " + userid);
kc.init({ onLoad: 'login-required' }).success(function () {????console.log("===================================");????console.log("kc.idToken.preferred_username: " + kc.idToken.preferred_username);? ??alert(JSON.stringify(kc.tokenParsed));?? ??var authenticatedUser = kc.idTokenParsed.name;?? ? console.log(authenticatedUser); ???}).error(function () {????window.location.reload();??});

Please advise. ?Thank you!!


From Ori.Doolman at amdocs.com  Mon Jul 10 17:18:20 2017
From: Ori.Doolman at amdocs.com (Ori Doolman)
Date: Mon, 10 Jul 2017 21:18:20 +0000
Subject: [keycloak-user] change password page in my application
Message-ID: <F12603E320A90546946D142FB805B94601733F35FE@ILRAADAGBE1.corp.amdocs.com>

Hi,

I want my application's users to be able to change their password.
My app is a web application using React/Node.JS.

I have 2 options to implement this having the end user interacts directly with Keycloak (so password will not go through my application):


1)      Customize the account theme (ftl) and use the /account endpoint. In this form the user will enter his old and new password interactively.

2)      Use the Keycloak admin REST API  from my application server (Node.JS) and make Keycloak send the user a mail with a link to reset the password:
PUT /admin/realms/{realm}/users/{id}/execute-actions-email
Once the user clicks the link, he will need to set the new password.

Which of the above is a preferred option ? Or is there any other option ?



Thanks,

Ori.

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>

From Vijay8.pasupuleti at gmail.com  Tue Jul 11 01:18:27 2017
From: Vijay8.pasupuleti at gmail.com (Vjraj)
Date: Mon, 10 Jul 2017 22:18:27 -0700 (MST)
Subject: [keycloak-user] how to Check if User is logged in or not?
Message-ID: <1499750307617-3943.post@n6.nabble.com>

we are implementing SSO among multiple Angular 2 Applications running on
different domains using keycloak (Note: use are not using any keycloak
adapters) 

the problem we face is the cookies are domain specific and we cant access
the cokie of one app in another

the way this problem can be solved in our point of view is to check if any
user in logged in through this browser and if logged in we will direct to
login page and it will return back with token and if not login it must the
normal page designed for not logged in user
 
1.how can we be able to check if any user is available ?

2.is there any alternative way to achieve this? 

thanks in adavance.




--
View this message in context: http://keycloak-user.88327.x6.nabble.com/how-to-Check-if-User-is-logged-in-or-not-tp3943.html
Sent from the keycloak-user mailing list archive at Nabble.com.

From sthorger at redhat.com  Tue Jul 11 01:28:50 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 11 Jul 2017 07:28:50 +0200
Subject: [keycloak-user] change password page in my application
In-Reply-To: <F12603E320A90546946D142FB805B94601733F35FE@ILRAADAGBE1.corp.amdocs.com>
References: <F12603E320A90546946D142FB805B94601733F35FE@ILRAADAGBE1.corp.amdocs.com>
Message-ID: <CAJgngAd52bs2-r8e-WvdQBRQ_gYTaPbr7tiXgerH_DKPzeJTVA@mail.gmail.com>

Option 1.

On 10 July 2017 at 23:18, Ori Doolman <Ori.Doolman at amdocs.com> wrote:

> Hi,
>
> I want my application's users to be able to change their password.
> My app is a web application using React/Node.JS.
>
> I have 2 options to implement this having the end user interacts directly
> with Keycloak (so password will not go through my application):
>
>
> 1)      Customize the account theme (ftl) and use the /account endpoint.
> In this form the user will enter his old and new password interactively.
>
> 2)      Use the Keycloak admin REST API  from my application server
> (Node.JS) and make Keycloak send the user a mail with a link to reset the
> password:
> PUT /admin/realms/{realm}/users/{id}/execute-actions-email
> Once the user clicks the link, he will need to set the new password.
>
> Which of the above is a preferred option ? Or is there any other option ?
>
>
>
> Thanks,
>
> Ori.
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From sthorger at redhat.com  Tue Jul 11 01:35:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 11 Jul 2017 07:35:57 +0200
Subject: [keycloak-user] illegal character in path when testing email
	setup
In-Reply-To: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>
References: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>
Message-ID: <CAJgngAf+v2vNGjJa-CH=gQxLE6qHVndJx1FkSx5tT6sUdM+Bow@mail.gmail.com>

Tried to reproduce this, but can't and it's working just fine here. Do you
have steps to reproduce?

On 10 July 2017 at 16:04, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:

> Hello,
>
> I get the following error when hitting the 'Test connection' button on the
> email tab in Realm settings:
>
> 2017-07-10 15:55:27,316 INFO  [org.jboss.as] (Controller Boot Thread)
> WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* started in
> 21731ms - Started 449 of 824 services (561 services are lazy, passive or
> on-demand)
> 2017-07-10 15:56:48,997 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n]
> (default task-11) RESTEASY002130: Failed to parse request.:
> javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to create
> URI:
> https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
> "port":null,"host":"mail.rdmedia.com
> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
> at
> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(
> ResteasyUriBuilder.java:749)
> at
> org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(
> ResteasyUriBuilder.java:721)
> at
> org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUriInfo.java:58)
> at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInfo.java:53)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletUtil.
> extractUriInfo(ServletUtil.java:41)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.
> service(ServletContainerDispatcher.java:200)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(
> HttpServletDispatcher.java:56)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(
> HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(
> ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
> doFilter(FilterHandler.java:129)
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(
> KeycloakSessionServletFilter.java:90)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
> doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(
> FilterHandler.java:84)
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.
> handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(
> ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHand
> ler.handleRequest(SecurityContextAssociationHandler.java:78)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandl
> er.handleRequest(SSLInformationAssociationHandler.java:131)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandl
> er.handleRequest(ServletAuthenticationCallHandler.java:57)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler
> .handleRequest(AbstractConfidentialityHandler.java:46)
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstrai
> ntHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandle
> r.handleRequest(AuthenticationMechanismsHandler.java:60)
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand
> ler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(
> NotificationReceiverHandler.java:50)
> at
> io.undertow.security.handlers.AbstractSecurityContextAssocia
> tionHandler.handleRequest(AbstractSecurityContextAssocia
> tionHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.
> handleRequest(JACCContextIdHandler.java:61)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(
> ServletInitialHandler.java:284)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(
> ServletInitialHandler.java:263)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$
> 000(ServletInitialHandler.java:81)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(
> ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(
> HttpServerExchange.java:793)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.URISyntaxException: Illegal character in path at index
> 67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
> "port":null,"host":"mail.rdmedia.com
> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3053)
> at java.net.URI.<init>(URI.java:588)
> at
> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValues(
> ResteasyUriBuilder.java:744)
> ... 40 more
>
> The 67th character is the slash after testSMTPConnection. Is this a bug
> and/or is there a workaround/fix?
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From marc.tempelmeier at flane.de  Tue Jul 11 04:15:28 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Tue, 11 Jul 2017 08:15:28 +0000
Subject: [keycloak-user] Domain Clustered Mode
Message-ID: <444cd1a4798a43c58738b656cad9a8af@dehamex2013.europe.flane.local>

Hi again,

We fixed the bearer error, it was different time settings in the cluster...

But the liquibase errors remains, it seems we have exactly this problem:

https://stackoverflow.com/questions/26235744/liquibase-case-insensitivity-in-postgresql. As far as I see it all table names are upper case in the liquibase change files.

Any idea?

-----Urspr?ngliche Nachricht-----
Von: Marc Tempelmeier 
Gesendet: Monday, July 10, 2017 9:28 AM
An: keycloak-user at lists.jboss.org
Betreff: Domain Clustered Mode

Hi,

Is there anyone here who has this working with 1 Master and 2-3 Slaves on Version 3.2.0? 

I frequently get 2 errors:

Error 1 (results in unregistering the slave):

Position: 22
[Server:slave1]     Caused by: liquibase.exception.DatabaseException: Error executing SQL select count(*) from public.databasechangeloglock: ERROR: relation \"public.databasechangeloglock\" does not exist
[Server:slave1]   Position: 22
[Server:slave1]     Caused by: org.postgresql.util.PSQLException: ERROR: relation \"public.databasechangeloglock\" does not exist


Error 2 (results in immediate logout, sometimes after 1 sec or later):

10:08:22,066 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-18) RESTEASY002005: Failed executing GET /admin/realms: org.jboss.resteasy.spi.UnauthorizedException: Bearer

If anyone has a working config, it would be really great to share :)

Best regards

Marc Tempelmeier


From marc.tempelmeier at flane.de  Tue Jul 11 08:10:47 2017
From: marc.tempelmeier at flane.de (Marc Tempelmeier)
Date: Tue, 11 Jul 2017 12:10:47 +0000
Subject: [keycloak-user] Domain Clustered Mode
In-Reply-To: <444cd1a4798a43c58738b656cad9a8af@dehamex2013.europe.flane.local>
References: <444cd1a4798a43c58738b656cad9a8af@dehamex2013.europe.flane.local>
Message-ID: <a7a661e95fd641ac81e99a0a1cf864b9@dehamex2013.europe.flane.local>

Also we get this errors on docker-compose startup from the postgres nodes:

postgresql-node2_1  | ERROR:  relation "public.databasechangeloglock" does not exist at character 22
postgresql-node2_1  | STATEMENT:  select count(*) from public.databasechangeloglock
postgresql-node1_1  | ERROR:  portal "pgpool_error_portal" does not exist
postgresql-node1_1  | ERROR:  relation "public.databasechangelog" does not exist at character 22
postgresql-node1_1  | STATEMENT:  select count(*) from public.databasechangelog
postgresql-node1_1  | ERROR:  relation "public.databasechangelog" does not exist at character 22
postgresql-node1_1  | STATEMENT:  select count(*) from public.databasechangelog

Seems really to be  liquibase connected issue

-----Urspr?ngliche Nachricht-----
Von: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] Im Auftrag von Marc Tempelmeier
Gesendet: Tuesday, July 11, 2017 10:15 AM
An: keycloak-user at lists.jboss.org
Betreff: Re: [keycloak-user] Domain Clustered Mode

Hi again,

We fixed the bearer error, it was different time settings in the cluster...

But the liquibase errors remains, it seems we have exactly this problem:

https://stackoverflow.com/questions/26235744/liquibase-case-insensitivity-in-postgresql. As far as I see it all table names are upper case in the liquibase change files.

Any idea?

-----Urspr?ngliche Nachricht-----
Von: Marc Tempelmeier 
Gesendet: Monday, July 10, 2017 9:28 AM
An: keycloak-user at lists.jboss.org
Betreff: Domain Clustered Mode

Hi,

Is there anyone here who has this working with 1 Master and 2-3 Slaves on Version 3.2.0? 

I frequently get 2 errors:

Error 1 (results in unregistering the slave):

Position: 22
[Server:slave1]     Caused by: liquibase.exception.DatabaseException: Error executing SQL select count(*) from public.databasechangeloglock: ERROR: relation \"public.databasechangeloglock\" does not exist
[Server:slave1]   Position: 22
[Server:slave1]     Caused by: org.postgresql.util.PSQLException: ERROR: relation \"public.databasechangeloglock\" does not exist


Error 2 (results in immediate logout, sometimes after 1 sec or later):

10:08:22,066 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-18) RESTEASY002005: Failed executing GET /admin/realms: org.jboss.resteasy.spi.UnauthorizedException: Bearer

If anyone has a working config, it would be really great to share :)

Best regards

Marc Tempelmeier

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


From reza.shams at axis.com  Tue Jul 11 08:48:45 2017
From: reza.shams at axis.com (Reza Shams Amiri)
Date: Tue, 11 Jul 2017 12:48:45 +0000
Subject: [keycloak-user] KeyCloak Clustering and High Availability question
Message-ID: <838293A9-2EC7-438F-A58C-88ACE407F7B6@axis.com>

Hi,

I am also evaluating KeyCloak for my organization. I have a question about how failover in KeyCloak works.
From what I understood from the documentation, it says that the application scalability is handled by wildfly clustering but with a shared database.
I couldn?t find a documentation about what we should do in case of database failure?
We want to have two different clustered nodes in two different continents for idp and we mainly have mysql databases. Clustering them is actually painful and done through rabbitMQ synced messages and in some custom ways. So how can we handle database failure in KeyCloak let?s say if the link between Sweden and USA is completely broken?

Thanks a lot
/Reza


From nicolaouantonia at gmail.com  Tue Jul 11 10:08:56 2017
From: nicolaouantonia at gmail.com (Antonia Nicolaou)
Date: Tue, 11 Jul 2017 17:08:56 +0300
Subject: [keycloak-user] redhat sso get baseurl in custom theme for
	email registration
In-Reply-To: <CADQwdOqqRzOUOEwevzN6DKX1b39HUu06foAgD4ZgZ_8qV15qrQ@mail.gmail.com>
References: <CADQwdOqqRzOUOEwevzN6DKX1b39HUu06foAgD4ZgZ_8qV15qrQ@mail.gmail.com>
Message-ID: <CADQwdOqEPKOkWaEP+sLq0V-gTT6uJH5h2_1=i2xc-CwftFhcJA@mail.gmail.com>

Kind reminder

2017-07-10 9:21 GMT+03:00 Antonia Nicolaou <nicolaouantonia at gmail.com>:

> Hello all,
>
>
>
> Your help would be greatly appreciated.
>
>
> I am using single sign on service from redhat v7.1 and I am developing a
> custom template (in a custom theme) for registration email. In the email,
> Unfortunately, I didn?t find the proper way to get the client baseUrl or
> the url.registrationUrl  .
>
> Could you please help me?
>
>
>
> Thank you in advanced.
>
> Sincerely,
>
> Antonia Nicolaou
>

From federico at info.nl  Tue Jul 11 10:38:33 2017
From: federico at info.nl (Federico Navarro Polo - Info.nl)
Date: Tue, 11 Jul 2017 14:38:33 +0000
Subject: [keycloak-user] error=pkce_verification_failed
Message-ID: <285AAEA2-C62A-4235-BC7D-4AB99F93A412@info.nl>

Hello,

After upgrading our Keycloak version to 3.1.0, we?ve started seeing the following error in one of our use cases (using AppAuth).

2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE supporting Client, codeVerifier = KX3heFUICMscL03Xv_STmf5hgRSsvm5VxnN0DIQob5wRAIGFyVqCn6hQ6w9exPyUtFaMcue1Uole-bTdHP6KaA
2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE codeChallengeMethod = S256
2017-07-11 16:21:12,135 WARN  [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE verification failed. authUserId = a71bd8ee-fe4b-4259-81c5-5e8e09940f47, authUsername = someone at somewhere.nl
2017-07-11 16:21:12,136 WARN  [org.keycloak.events] (default task-24) type=CODE_TO_TOKEN_ERROR, realmId=x, clientId=x, userId=a71bd8ee-fe4b-4259-81c5-5e8e09940f47, ipAddress=x.x.x.x, error=pkce_verification_failed, grant_type=authorization_code, code_id=1cf7b8f2-5462-4cf4-a228-ba0cc4501e82, client_auth_method=client-secret


I saw this bug report, which could be related to the issue (still open for 3.2.0 as well): https://issues.jboss.org/browse/KEYCLOAK-4956

Is it possible to disable PKCE from Keycloak configuration?


Met vriendelijke groet,

Federico Navarro

backend developer

federico at info.nl<mailto:federico at info.nl>  |  LinkedIn<https://www.linkedin.com/company/info-nl>  |  +31 (0)2 05 30 91 61<tel:+31205309161>

info.nl<http://www.info.nl/>

Sint Antoniesbreestraat 16  |  1011 HB Amsterdam  |  +31 (0)20 530 9100<tel:+31205309100>



From bburke at redhat.com  Tue Jul 11 10:46:51 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Jul 2017 10:46:51 -0400
Subject: [keycloak-user] KeyCloak Clustering and High Availability
 question
In-Reply-To: <838293A9-2EC7-438F-A58C-88ACE407F7B6@axis.com>
References: <838293A9-2EC7-438F-A58C-88ACE407F7B6@axis.com>
Message-ID: <25710b88-ad20-fa93-2409-3c6c5c7976c2@redhat.com>

Wildfly clustering handles user login session replication as well as the 
caching layer for information stored in the shared database and/or LDAP 
and/or any other external user store.  Shared database is required for 
storing realm configuration data and user data and imported user data.  
So Wildfly clustering handles anything in-memory related and for 
database stuff you have to rely on your database vendor for whatever 
solution they have for this.


On 7/11/17 8:48 AM, Reza Shams Amiri wrote:
> Hi,
>
> I am also evaluating KeyCloak for my organization. I have a question about how failover in KeyCloak works.
>  From what I understood from the documentation, it says that the application scalability is handled by wildfly clustering but with a shared database.
> I couldn?t find a documentation about what we should do in case of database failure?
> We want to have two different clustered nodes in two different continents for idp and we mainly have mysql databases. Clustering them is actually painful and done through rabbitMQ synced messages and in some custom ways. So how can we handle database failure in KeyCloak let?s say if the link between Sweden and USA is completely broken?
>
> Thanks a lot
> /Reza
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From max.catarino at rps.com.br  Tue Jul 11 13:54:33 2017
From: max.catarino at rps.com.br (Maximiliano)
Date: Tue, 11 Jul 2017 10:54:33 -0700 (MST)
Subject: [keycloak-user] how to Check if User is logged in or not?
In-Reply-To: <1499750307617-3943.post@n6.nabble.com>
References: <1499750307617-3943.post@n6.nabble.com>
Message-ID: <1499795673796-3944.post@n6.nabble.com>

Take a look at this post:  CURL login
<http://lists.jboss.org/pipermail/keycloak-user/2016-April/005869.html>  .



--
View this message in context: http://keycloak-user.88327.x6.nabble.com/how-to-Check-if-User-is-logged-in-or-not-tp3943p3944.html
Sent from the keycloak-user mailing list archive at Nabble.com.

From dennishonders at gmail.com  Tue Jul 11 14:00:12 2017
From: dennishonders at gmail.com (Dennis H)
Date: Tue, 11 Jul 2017 20:00:12 +0200
Subject: [keycloak-user] Error 403 Java Spring Boot
Message-ID: <CALfiJ8aWqUhEZuu6yaQX=L4tUmtzX-56_B1_EkqMc4mhqe+W5Q@mail.gmail.com>

I receive a http error 403 when accessing a bearer-only resource with
Postman that is secured with keycloak.
The user has the needed role.
Debug logs: BEARER AUTHENTICATED.
What could be the problem here?

*Application.properties*

keycloak.realm=myrealm
keycloak.bearer-only=true
keycloak.auth-server-url=http://localhost:8080/auth
keycloak.ssl-required=external
keycloak.resource=my-app
keycloak.use-resource-role-mappings=true
keycloak.securityConstraints[0].securityCollections[0].name=secured
keycloak.securityConstraints[0].authRoles[0]=app-user
keycloak.securityConstraints[0].securityCollections[0].patterns[0]=/secured/*

logging.level.org.keycloak=DEBUG

*Postman*
http://localhost:8081/secured/posts/0/10
Authorization: Bearer aDSFla56s...

*Debug*
2017-07-11 19:53:41.306 DEBUG 22556 --- [nio-8081-exec-1]
o.k.adapters.PreAuthActionsHandler       : adminRequest
http://localhost:8081/secured/posts/0/10
2017-07-11 19:53:41.313 DEBUG 22556 --- [nio-8081-exec-1]
o.k.a.a.ClientCredentialsProviderUtils   : Using provider 'secret' for
authentication of client 'my-app'
2017-07-11 19:53:41.314 DEBUG 22556 --- [nio-8081-exec-1]
o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
secret
2017-07-11 19:53:41.315 DEBUG 22556 --- [nio-8081-exec-1]
o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
jwt
2017-07-11 19:53:41.317 DEBUG 22556 --- [nio-8081-exec-1]
o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
secret
2017-07-11 19:53:41.317 DEBUG 22556 --- [nio-8081-exec-1]
o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
jwt
2017-07-11 19:53:41.354 DEBUG 22556 --- [nio-8081-exec-1]
o.keycloak.adapters.KeycloakDeployment   : resolveUrls
2017-07-11 19:53:41.356 DEBUG 22556 --- [nio-8081-exec-1]
o.k.adapters.KeycloakDeploymentBuilder   : Use authServerUrl:
http://localhost:8080/auth, tokenUrl:
http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/token,
relativeUrls: NEVER
2017-07-11 19:53:41.631 DEBUG 22556 --- [nio-8081-exec-1]
o.k.a.rotation.JWKPublicKeyLocator       : Realm public keys successfully
retrieved for client my-app. New kids: [NsYwvDAUJYY3ioS9-0mpo]
2017-07-11 19:53:41.641 DEBUG 22556 --- [nio-8081-exec-1]
o.k.adapters.RequestAuthenticator        : User
'c1ed6bf7-5dd-988-94fab8ecf' invoking '
http://localhost:8081/secured/posts/0/10' on client 'my-app'
2017-07-11 19:53:41.642 DEBUG 22556 --- [nio-8081-exec-1]
o.k.adapters.RequestAuthenticator        : *Bearer AUTHENTICATED*

From max.catarino at rps.com.br  Tue Jul 11 14:08:46 2017
From: max.catarino at rps.com.br (Maximiliano)
Date: Tue, 11 Jul 2017 11:08:46 -0700 (MST)
Subject: [keycloak-user] how to Check if User is logged in or not?
In-Reply-To: <1499795673796-3944.post@n6.nabble.com>
References: <1499750307617-3943.post@n6.nabble.com>
	<1499795673796-3944.post@n6.nabble.com>
Message-ID: <1499796526856-3945.post@n6.nabble.com>

To check if the token is valid, use introspect endpoint.
Introspect
<http://www.keycloak.org/docs/2.4/authorization_services_guide/topics/service/protection/token-introspection.html>  



--
View this message in context: http://keycloak-user.88327.x6.nabble.com/how-to-Check-if-User-is-logged-in-or-not-tp3943p3945.html
Sent from the keycloak-user mailing list archive at Nabble.com.

From mposolda at redhat.com  Tue Jul 11 16:56:20 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 11 Jul 2017 22:56:20 +0200
Subject: [keycloak-user] error=pkce_verification_failed
In-Reply-To: <285AAEA2-C62A-4235-BC7D-4AB99F93A412@info.nl>
References: <285AAEA2-C62A-4235-BC7D-4AB99F93A412@info.nl>
Message-ID: <67434e71-ba6a-18a1-cca2-fd6c93dc1882@redhat.com>

Still I would try to upgrade to 3.2.0.Final if possible. AFAIK there was 
some related fixes in there, so worth to try if it's not a lot of work 
for you. Otherwise workaround is to disable PKCE for your adapter, which 
will also remove all related parameters from the initial request to 
Keycloak.

Marek

On 11/07/17 16:38, Federico Navarro Polo - Info.nl wrote:
> Hello,
>
> After upgrading our Keycloak version to 3.1.0, we?ve started seeing the following error in one of our use cases (using AppAuth).
>
> 2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE supporting Client, codeVerifier = KX3heFUICMscL03Xv_STmf5hgRSsvm5VxnN0DIQob5wRAIGFyVqCn6hQ6w9exPyUtFaMcue1Uole-bTdHP6KaA
> 2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE codeChallengeMethod = S256
> 2017-07-11 16:21:12,135 WARN  [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE verification failed. authUserId = a71bd8ee-fe4b-4259-81c5-5e8e09940f47, authUsername = someone at somewhere.nl
> 2017-07-11 16:21:12,136 WARN  [org.keycloak.events] (default task-24) type=CODE_TO_TOKEN_ERROR, realmId=x, clientId=x, userId=a71bd8ee-fe4b-4259-81c5-5e8e09940f47, ipAddress=x.x.x.x, error=pkce_verification_failed, grant_type=authorization_code, code_id=1cf7b8f2-5462-4cf4-a228-ba0cc4501e82, client_auth_method=client-secret
>
>
> I saw this bug report, which could be related to the issue (still open for 3.2.0 as well): https://issues.jboss.org/browse/KEYCLOAK-4956
>
> Is it possible to disable PKCE from Keycloak configuration?
>
>
> Met vriendelijke groet,
>
> Federico Navarro
>
> backend developer
>
> federico at info.nl<mailto:federico at info.nl>  |  LinkedIn<https://www.linkedin.com/company/info-nl>  |  +31 (0)2 05 30 91 61<tel:+31205309161>
>
> info.nl<http://www.info.nl/>
>
> Sint Antoniesbreestraat 16  |  1011 HB Amsterdam  |  +31 (0)20 530 9100<tel:+31205309100>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Tue Jul 11 16:59:31 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 11 Jul 2017 22:59:31 +0200
Subject: [keycloak-user] Consent Required how it works exatly
In-Reply-To: <CAHSaR+912pr6jtgGPDHqEJ=wogX15P6+0ibkh_TJ0EQZ7D95eQ@mail.gmail.com>
References: <CAHSaR+912pr6jtgGPDHqEJ=wogX15P6+0ibkh_TJ0EQZ7D95eQ@mail.gmail.com>
Message-ID: <46c0a439-dee0-a3bb-1cce-97f781cfbb37@redhat.com>

It means that after successful login to this client, the Keycloak will 
display the screen where user needs to confirm if he wants to share his 
personal informations and roles with the client applications. Something 
like "application XY wants to see your email, firstName, lastName and 
roles user and administrator". You may know this type of screen from 
vendors like Facebook or Google.

Marek

On 04/07/17 17:35, Nikolaj Majorov wrote:
> Hi all,
>
> I see that for sample app-jee-html5 application in the  the client
> configuration the property
> "Consent Required" is configured. How does it implemented ? doest it
> mean that application get cookie first after user logged-in with
> user-name password  or other js Iframe ? and only after login with
> user-name& password the  client can ask for token ?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From brahima at gmail.com  Tue Jul 11 20:10:00 2017
From: brahima at gmail.com (Brahim Ait elhaj)
Date: Wed, 12 Jul 2017 02:10:00 +0200
Subject: [keycloak-user] Authorization services without User Access token
	(Mqtt Broker / IoT)
Message-ID: <CA+eBSFQrRWYFm7xjK5PGE_JVg6UVy+sXTVGUuPSkD8wkMsx=7w@mail.gmail.com>

Hi everyone,

Lately i was playing with Keycloak (KC), evaluating it for an IoT project
and i have a question regarding the authorization services.

One of my use case is : devices that connect to an MQTT Broker using X.509
client authentication.

Note : when i talk about device, you must understand KC user (device =
user).

For several reasons/constraints that i won't explain here, i can't have my
devices connect first to Keycloak to obtain a token (using their X.509
certificates as KC supports it) and then connect to the MQTT Broker passing
this token. They connect directly to the MQTT Broker, each device
presenting its X.509 certificate to the Broker. After connection, the
Broker doesn't know client private key.

My need is to have my MQTT Broker (ideally through KC) authorize/reject
MQTT client to publish/subscribe to specific topic.
MQTT Topic being some kind of uri/path, i already have an idea of how to
configure KC (client, resource, policy, permission ...) to authorize/reject
these access.

However, as i understand it, the starting point for all the ? authorization
services ? (Authorization API, Entitlement API ... ) is a ? user Access
Token ?.
In my case, i don't have a user access token ... so i'm kind of stuck to
use any of the K.C API (unless i missed something).

Hence, My question is how can i make my MQTT Broker (.ie : resource server)
interact with KC to enforce/evaluate policy ? Is it possible without the
user access token ?

Hope i made myself clear and thanks in advance for any help ...

Best regards,
Brahim

From mposolda at redhat.com  Wed Jul 12 02:51:18 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 08:51:18 +0200
Subject: [keycloak-user] Kerberos Authentication throws Exception
In-Reply-To: <CALS12-NG8aJRCQHRbF62ARj0LD+Emy1kjNuriho09yEbtYKyQA@mail.gmail.com>
References: <0d8e7bae-a4b5-2b59-96f4-634e2635bc8e@finsterwalder.name>
	<CALS12-OE6mxooa5nF12hsa9k4Q--kHKOyRMXC0YywaLy1QDxGw@mail.gmail.com>
	<CALS12-NG8aJRCQHRbF62ARj0LD+Emy1kjNuriho09yEbtYKyQA@mail.gmail.com>
Message-ID: <be59ce9e-bb9a-7776-d142-ba86eec49942@redhat.com>

Do you have "/etc/krb5.conf" file on the server where your Keycloak is 
deployed? In this file you need to have configuration of kerberos realm 
corresponding to the kerberos realm you used in the Keycloak LDAP 
storage provider configuration. The host/port of kdc needs to be 
accessible through network. The configuration of kdc in the 
/etc/krb5.conf file can look like this for example:

         KEYCLOAK.ORG={
                 kdc = localhost:6088
         }


Marek

On 06/07/17 19:26, Malte Finsterwalder wrote:
> I tweaked my config a bit and fixed an error there. It still doesn't work
> correctly, but now I get an ICMP Error, after the SPNEGO Failure and a try
> to login with username and password;
>
> 17:23:54,184 INFO  [stdout] (default task-21) [Krb5LoginModule]
> authentication failed
> 17:23:54,184 INFO  [stdout] (default task-21) ICMP Port Unreachable
> 17:23:54,185 WARN  [org.keycloak.services] (default task-21)
> KC-SERVICES0013: Failed authentication: org.keycloak.models.ModelException:
> Kerberos unreachable
> at
> org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.checkKerberosServerAvailable(KerberosUsernamePasswordAuthenticator.java:108)
> at
> org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.validUser(KerberosUsernamePasswordAuthenticator.java:94)
> at
> org.keycloak.storage.ldap.LDAPStorageProvider.validPassword(LDAPStorageProvider.java:512)
> at
> org.keycloak.storage.ldap.LDAPStorageProvider.isValid(LDAPStorageProvider.java:602)
> at
> org.keycloak.credential.UserCredentialStoreManager.validate(UserCredentialStoreManager.java:140)
> at
> org.keycloak.credential.UserCredentialStoreManager.isValid(UserCredentialStoreManager.java:121)
> at
> org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validatePassword(AbstractUsernameFormAuthenticator.java:175)
> at
> org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validateUserAndPassword(AbstractUsernameFormAuthenticator.java:151)
> at
> org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.validateForm(UsernamePasswordForm.java:56)
> at
> org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.action(UsernamePasswordForm.java:49)
> at
> org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:92)
> at
> org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:76)
> at
> org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:759)
> at
> org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:365)
> at
> org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:347)
> at
> org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:401)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at
> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at
> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.security.auth.login.LoginException: ICMP Port Unreachable
> at
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:808)
> at
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.authenticateSubject(KerberosUsernamePasswordAuthenticator.java:128)
> at
> org.keycloak.federation.kerberos.impl.KerberosUsernamePasswordAuthenticator.validUser(KerberosUsernamePasswordAuthenticator.java:90)
> ... 61 more
> Caused by: java.net.PortUnreachableException: ICMP Port Unreachable
> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> at
> java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
> at java.net.DatagramSocket.receive(DatagramSocket.java:812)
> at sun.security.krb5.internal.UDPClient.receive(NetClient.java:206)
> at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:411)
> at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:364)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.krb5.KdcComm.send(KdcComm.java:348)
> at sun.security.krb5.KdcComm.sendIfPossible(KdcComm.java:253)
> at sun.security.krb5.KdcComm.send(KdcComm.java:229)
> at sun.security.krb5.KdcComm.send(KdcComm.java:200)
> at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316)
> at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
> at
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:766)
> ... 75 more
>
>
> On 6 July 2017 at 17:21, Malte Finsterwalder <inofi at gmx.net> wrote:
>
>> Hi there,
>>
>> I tried to configure Keycloak to authenticate against Windows Active
>> Directory using Kerberos credentials.
>> But I keep getting an Exception.
>>
>> Setup is as follows:
>>
>> I created a docker image based on jboss/keycloak-ha-postgres:2.5.5.Final.
>> In addition I installed freeipa-client and added a /etc/krb5.conf file as
>> well as my keytab file.
>>
>> But when I configure Kerberos as required in the browser flow, I get the
>> following Exception and the browser shows me a basic auth login dialog,
>> that does not allow me to log in at all.
>>
>> Any ideas? How can gather more information?
>>
>> 13:26:25,796 INFO  [stdout] (default task-64) Debug is  true storeKey true
>> useTicketCache false useKeyTab true doNotPrompt true ticketCache is null
>> isInitiator false KeyTab is /keytabs/SVC_KEYCLOAK_CI20_HTTP_IDP-UI.keytab
>> refreshKrb5Config is false principal is HTTP/SVC_KEYCLOAK_CI20.HH.HANS
>> EMERKUR.DE at HH.HANSEMERKUR.DE tryFirstPass is false useFirstPass is false
>> storePass is false clearPass is false
>> 13:26:25,796 INFO  [stdout] (default task-64) principal is
>> HTTP/SVC_KEYCLOAK_CI20.HH.HANSEMERKUR.DE at HH.HANSEMERKUR.DE
>> 13:26:25,796 INFO  [stdout] (default task-64) Will use keytab
>> 13:26:25,796 INFO  [stdout] (default task-64) Commit Succeeded
>> 13:26:25,796 INFO  [stdout] (default task-64)
>>
>> 13:19:24,501 WARN  [org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator]
>> (default task-47) SPNEGO login failed: java.security.PrivilegedActionException:
>> GSSException: Defective token detected (Mechanism level: GSSHeader did not
>> find the right tag)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at javax.security.auth.Subject.doAs(Subject.java:422)
>> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.au
>> thenticate(SPNEGOAuthenticator.java:68)
>> at org.keycloak.storage.ldap.LDAPStorageProvider.authenticate(L
>> DAPStorageProvider.java:542)
>> at org.keycloak.credential.UserCredentialStoreManager.authentic
>> ate(UserCredentialStoreManager.java:323)
>> at org.keycloak.authentication.authenticators.browser.SpnegoAut
>> henticator.authenticate(SpnegoAuthenticator.java:90)
>> at org.keycloak.authentication.DefaultAuthenticationFlow.proces
>> sFlow(DefaultAuthenticationFlow.java:184)
>> at org.keycloak.authentication.AuthenticationProcessor.authenti
>> cateOnly(AuthenticationProcessor.java:792)
>> at org.keycloak.authentication.AuthenticationProcessor.authenti
>> cate(AuthenticationProcessor.java:667)
>> at org.keycloak.protocol.AuthorizationEndpointBase.handleBrowse
>> rAuthenticationRequest(AuthorizationEndpointBase.java:123)
>> at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.b
>> uildAuthorizationCodeAuthorizationResponse(AuthorizationEndpoint.java:317)
>> at org.keycloak.protocol.oidc.endpoints.AuthorizationEndpoint.
>> build(AuthorizationEndpoint.java:125)
>> at sun.reflect.GeneratedMethodAccessor615.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje
>> ctorImpl.java:139)
>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget
>> (ResourceMethodInvoker.java:295)
>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc
>> eMethodInvoker.java:249)
>> at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTarge
>> tObject(ResourceLocatorInvoker.java:138)
>> at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Resour
>> ceLocatorInvoker.java:107)
>> at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTarge
>> tObject(ResourceLocatorInvoker.java:133)
>> at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Resour
>> ceLocatorInvoker.java:101)
>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
>> nousDispatcher.java:395)
>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
>> nousDispatcher.java:202)
>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
>> spatcher.service(ServletContainerDispatcher.java:221)
>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>> her.service(HttpServletDispatcher.java:56)
>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>> her.service(HttpServletDispatcher.java:51)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>> at io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
>> rvletHandler.java:85)
>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>> oFilter(FilterHandler.java:129)
>> at org.keycloak.services.filters.KeycloakSessionServletFilter.d
>> oFilter(KeycloakSessionServletFilter.java:90)
>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>> oFilter(FilterHandler.java:131)
>> at io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
>> terHandler.java:84)
>> at io.undertow.servlet.handlers.security.ServletSecurityRoleHan
>> dler.handleRequest(ServletSecurityRoleHandler.java:62)
>> at io.undertow.servlet.handlers.ServletDispatchingHandler.handl
>> eRequest(ServletDispatchingHandler.java:36)
>> at org.wildfly.extension.undertow.security.SecurityContextAssoc
>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.servlet.handlers.security.SSLInformationAssociat
>> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>> .handleRequest(AbstractConfidentialityHandler.java:46)
>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>> ConstraintHandler.handleRequest(ServletConfident
>> ialityConstraintHandler.java:64)
>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>> ndleRequest(NotificationReceiverHandler.java:50)
>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>> Handler.java:43)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>> ndler.handleRequest(JACCContextIdHandler.java:61)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>> stRequest(ServletInitialHandler.java:284)
>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>> equest(ServletInitialHandler.java:263)
>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>> 0(ServletInitialHandler.java:81)
>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>> equest(ServletInitialHandler.java:174)
>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>> ge.java:793)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> Caused by: GSSException: Defective token detected (Mechanism level:
>> GSSHeader did not find the right tag)
>> at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97)
>> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContext
>> Impl.java:306)
>> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContext
>> Impl.java:285)
>> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.es
>> tablishContext(SPNEGOAuthenticator.java:172)
>> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$Ac
>> ceptSecContext.run(SPNEGOAuthenticator.java:135)
>> at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$Ac
>> ceptSecContext.run(SPNEGOAuthenticator.java:125)
>> ... 60 more
>>
>> 13:26:25,798 INFO  [stdout] (default task-64)         [Krb5LoginModule]:
>> Entering logout
>> 13:26:25,798 INFO  [stdout] (default task-64)         [Krb5LoginModule]:
>> logged out Subject
>>
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 12 02:59:37 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 08:59:37 +0200
Subject: [keycloak-user] SAML HttpServletRequest.logout() support
In-Reply-To: <1263738321.6142511.1499280048359@mail.yahoo.com>
References: <1263738321.6142511.1499280048359.ref@mail.yahoo.com>
	<1263738321.6142511.1499280048359@mail.yahoo.com>
Message-ID: <fffcbdc9-66d9-35c2-5391-406bc247247a@redhat.com>

You can check our SAML examples in the keycloak-examples distribution. 
They're doing logout.

Marek

On 05/07/17 20:40, Jason Spittel wrote:
> I'm having trouble with SAML Logout.  I have a JEE app that uses Keycloak as an identity broker to ADFS.
> Following these instructions:Logout | Keycloak Documentation
>
>
> |
> |
> |  |
> Logout | Keycloak Documentation
>
>
>   |
>
>   |
>
>   |
>
>
>
> I should be able to just call HttpServletRequest.logout(). But that doesn't do anything.
> Searching Jira I see this a reported issue.
> [KEYCLOAK-2191] SAML HttpServletRequest.logout() support - JBoss Issue Tracker
>
>
> |
> |
> |  |
> [KEYCLOAK-2191] SAML HttpServletRequest.logout() support - JBoss Issue T...
>
>
>   |
>
>   |
>
>   |
>
>
>
> While that's being worked on, are there workarounds to do a SAML logout through Keycloak?
>
> Thanks,
> Jason
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 12 03:10:01 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 09:10:01 +0200
Subject: [keycloak-user] Application to application: could Keycloak
 implement this?
In-Reply-To: <7d4227a7-9bc4-0a93-dffb-c1daa725b0fa@psynd.net>
References: <7d4227a7-9bc4-0a93-dffb-c1daa725b0fa@psynd.net>
Message-ID: <dfa9baa2-6fe4-a3a9-8296-09cc6226812c@redhat.com>

Hi,

We have example in documentation for EJB propagation from web 
application where Keycloak. See 
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/jboss-adapter.html 
and especially the last paragraph "Security domain" .

We have unofficial example I've written to propagate identity from fat 
client through remote EJB calls: 
https://github.com/mposolda/keycloak-remote-ejb

Marek

On 04/07/17 18:42, Tech wrote:
> Dear experts,
>
> I want to bring you this use case to understand if you might be able to
> support me.
>
> Our architecture is based in java, where we might have two kind of clients:
>
>    * Fat java clients
>    * Browsers
>
> Application servers with:
>
>    * Web containers performing local and remote EJB calls + remote WS calls
>    * EJB container performing local and remote EJB calls + remote WS calls
>    * A remote EJB server performing local and remote EJB calls + remote
>      WS calls
>    * Ws implemeting SOAP or REST
>    * Server SSO able to protect what described above
>
> The goal is to allow the clients (thin and fat) to authenticate on the
> SSO server and to propagate the user identity on these requests:
>
>    * Fat client authenticated -> EJB secure -> WS secure
>    * Browser authenticated -> Web container -> EJB secure -> WS secure
>
> The solution could use a secure token OAuth, OIDC or SAML.
>
> The token propagation should be based on standards JAAS and WS-Security.
>
> We saw that is possible to implement something similar in some SAML
> Login Modules on JBoss Enterprise server, but we are not finding
> anything equivalent in Keycloak.
>
> We cannot neither find, for example, not neither for a STS server, that
> are the required elements to transform this kind of tokens.
>
>
> Did anybody faced a similar experience?
>
> Thanks for your support!
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From reza.shams at axis.com  Wed Jul 12 03:48:04 2017
From: reza.shams at axis.com (Reza Shams Amiri)
Date: Wed, 12 Jul 2017 07:48:04 +0000
Subject: [keycloak-user] KeyCloak Clustering and High Availability
 question
In-Reply-To: <25710b88-ad20-fa93-2409-3c6c5c7976c2@redhat.com>
References: <838293A9-2EC7-438F-A58C-88ACE407F7B6@axis.com>
	<25710b88-ad20-fa93-2409-3c6c5c7976c2@redhat.com>
Message-ID: <85D40823-BAAD-4888-9797-5041BFCD4B9F@axis.com>

Thanks a lot Bill, so my question specifically is: 

if for instance, mysql database is down for an hour but wildfly clusters, and ldaps are up, 
the idp still can operate because of caching? And will resync the configuration when the database is up again?
You said about *database stuff*, what exactly will not work if database is not accessible for a while?

Thanks in advance

On 2017-07-11, 17:40, "keycloak-user-bounces at lists.jboss.org on behalf of Bill Burke" <keycloak-user-bounces at lists.jboss.org on behalf of bburke at redhat.com> wrote:

    Wildfly clustering handles user login session replication as well as the 
    caching layer for information stored in the shared database and/or LDAP 
    and/or any other external user store.  Shared database is required for 
    storing realm configuration data and user data and imported user data.  
    So Wildfly clustering handles anything in-memory related and for 
    database stuff you have to rely on your database vendor for whatever 
    solution they have for this.
    
    
    On 7/11/17 8:48 AM, Reza Shams Amiri wrote:
    > Hi,
    >
    > I am also evaluating KeyCloak for my organization. I have a question about how failover in KeyCloak works.
    >  From what I understood from the documentation, it says that the application scalability is handled by wildfly clustering but with a shared database.
    > I couldn?t find a documentation about what we should do in case of database failure?
    > We want to have two different clustered nodes in two different continents for idp and we mainly have mysql databases. Clustering them is actually painful and done through rabbitMQ synced messages and in some custom ways. So how can we handle database failure in KeyCloak let?s say if the link between Sweden and USA is completely broken?
    >
    > Thanks a lot
    > /Reza
    >
    > _______________________________________________
    > keycloak-user mailing list
    > keycloak-user at lists.jboss.org
    > https://lists.jboss.org/mailman/listinfo/keycloak-user
    
    _______________________________________________
    keycloak-user mailing list
    keycloak-user at lists.jboss.org
    https://lists.jboss.org/mailman/listinfo/keycloak-user



From sblanc at redhat.com  Wed Jul 12 04:09:57 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 12 Jul 2017 10:09:57 +0200
Subject: [keycloak-user] Error 403 Java Spring Boot
In-Reply-To: <CALfiJ8aWqUhEZuu6yaQX=L4tUmtzX-56_B1_EkqMc4mhqe+W5Q@mail.gmail.com>
References: <CALfiJ8aWqUhEZuu6yaQX=L4tUmtzX-56_B1_EkqMc4mhqe+W5Q@mail.gmail.com>
Message-ID: <CAMZCGg_=8Owh1EytG1bhtvRYGvH2vww7s_nYAMFWF6E3nQuAHw@mail.gmail.com>

Could you try to add this as well ?
keycloak.public-client=true

On Tue, Jul 11, 2017 at 8:00 PM, Dennis H <dennishonders at gmail.com> wrote:

> I receive a http error 403 when accessing a bearer-only resource with
> Postman that is secured with keycloak.
> The user has the needed role.
> Debug logs: BEARER AUTHENTICATED.
> What could be the problem here?
>
> *Application.properties*
>
> keycloak.realm=myrealm
> keycloak.bearer-only=true
> keycloak.auth-server-url=http://localhost:8080/auth
> keycloak.ssl-required=external
> keycloak.resource=my-app
> keycloak.use-resource-role-mappings=true
> keycloak.securityConstraints[0].securityCollections[0].name=secured
> keycloak.securityConstraints[0].authRoles[0]=app-user
> keycloak.securityConstraints[0].securityCollections[0].
> patterns[0]=/secured/*
>
> logging.level.org.keycloak=DEBUG
>
> *Postman*
> http://localhost:8081/secured/posts/0/10
> Authorization: Bearer aDSFla56s...
>
> *Debug*
> 2017-07-11 19:53:41.306 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.PreAuthActionsHandler       : adminRequest
> http://localhost:8081/secured/posts/0/10
> 2017-07-11 19:53:41.313 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Using provider 'secret' for
> authentication of client 'my-app'
> 2017-07-11 19:53:41.314 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded
> clientCredentialsProvider
> secret
> 2017-07-11 19:53:41.315 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded
> clientCredentialsProvider
> jwt
> 2017-07-11 19:53:41.317 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded
> clientCredentialsProvider
> secret
> 2017-07-11 19:53:41.317 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded
> clientCredentialsProvider
> jwt
> 2017-07-11 19:53:41.354 DEBUG 22556 --- [nio-8081-exec-1]
> o.keycloak.adapters.KeycloakDeployment   : resolveUrls
> 2017-07-11 19:53:41.356 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.KeycloakDeploymentBuilder   : Use authServerUrl:
> http://localhost:8080/auth, tokenUrl:
> http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/token,
> relativeUrls: NEVER
> 2017-07-11 19:53:41.631 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.rotation.JWKPublicKeyLocator       : Realm public keys successfully
> retrieved for client my-app. New kids: [NsYwvDAUJYY3ioS9-0mpo]
> 2017-07-11 19:53:41.641 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.RequestAuthenticator        : User
> 'c1ed6bf7-5dd-988-94fab8ecf' invoking '
> http://localhost:8081/secured/posts/0/10' on client 'my-app'
> 2017-07-11 19:53:41.642 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.RequestAuthenticator        : *Bearer AUTHENTICATED*
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From K.Buler at adbglobal.com  Wed Jul 12 04:24:20 2017
From: K.Buler at adbglobal.com (Karol Buler)
Date: Wed, 12 Jul 2017 10:24:20 +0200
Subject: [keycloak-user] Error 403 Java Spring Boot
In-Reply-To: <CALfiJ8aWqUhEZuu6yaQX=L4tUmtzX-56_B1_EkqMc4mhqe+W5Q@mail.gmail.com>
References: <CALfiJ8aWqUhEZuu6yaQX=L4tUmtzX-56_B1_EkqMc4mhqe+W5Q@mail.gmail.com>
Message-ID: <3783e075-b126-33af-5254-41d419033c92@adbglobal.com>

I had similar problem. You are using
"keycloak.use-resource-role-mappings=true", check that the user has the
client's role instead realm's role.


On 11.07.2017 20:00, Dennis H wrote:
> I receive a http error 403 when accessing a bearer-only resource with
> Postman that is secured with keycloak.
> The user has the needed role.
> Debug logs: BEARER AUTHENTICATED.
> What could be the problem here?
>
> *Application.properties*
>
> keycloak.realm=myrealm
> keycloak.bearer-only=true
> keycloak.auth-server-url=http://localhost:8080/auth
> keycloak.ssl-required=external
> keycloak.resource=my-app
> keycloak.use-resource-role-mappings=true
> keycloak.securityConstraints[0].securityCollections[0].name=secured
> keycloak.securityConstraints[0].authRoles[0]=app-user
> keycloak.securityConstraints[0].securityCollections[0].patterns[0]=/secured/*
>
> logging.level.org.keycloak=DEBUG
>
> *Postman*
> http://localhost:8081/secured/posts/0/10
> Authorization: Bearer aDSFla56s...
>
> *Debug*
> 2017-07-11 19:53:41.306 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.PreAuthActionsHandler       : adminRequest
> http://localhost:8081/secured/posts/0/10
> 2017-07-11 19:53:41.313 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Using provider 'secret' for
> authentication of client 'my-app'
> 2017-07-11 19:53:41.314 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
> secret
> 2017-07-11 19:53:41.315 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
> jwt
> 2017-07-11 19:53:41.317 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
> secret
> 2017-07-11 19:53:41.317 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.a.ClientCredentialsProviderUtils   : Loaded clientCredentialsProvider
> jwt
> 2017-07-11 19:53:41.354 DEBUG 22556 --- [nio-8081-exec-1]
> o.keycloak.adapters.KeycloakDeployment   : resolveUrls
> 2017-07-11 19:53:41.356 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.KeycloakDeploymentBuilder   : Use authServerUrl:
> http://localhost:8080/auth, tokenUrl:
> http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/token,
> relativeUrls: NEVER
> 2017-07-11 19:53:41.631 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.a.rotation.JWKPublicKeyLocator       : Realm public keys successfully
> retrieved for client my-app. New kids: [NsYwvDAUJYY3ioS9-0mpo]
> 2017-07-11 19:53:41.641 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.RequestAuthenticator        : User
> 'c1ed6bf7-5dd-988-94fab8ecf' invoking'
> http://localhost:8081/secured/posts/0/10' on client 'my-app'
> 2017-07-11 19:53:41.642 DEBUG 22556 --- [nio-8081-exec-1]
> o.k.adapters.RequestAuthenticator        : *Bearer AUTHENTICATED*
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

[https://www.adbglobal.com/wp-content/uploads/adb.png]
connecting lives
connecting worlds


From t.ruiten at rdmedia.com  Wed Jul 12 05:43:09 2017
From: t.ruiten at rdmedia.com (Tiemen Ruiten)
Date: Wed, 12 Jul 2017 11:43:09 +0200
Subject: [keycloak-user] illegal character in path when testing email
	setup
In-Reply-To: <CAJgngAf+v2vNGjJa-CH=gQxLE6qHVndJx1FkSx5tT6sUdM+Bow@mail.gmail.com>
References: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>
	<CAJgngAf+v2vNGjJa-CH=gQxLE6qHVndJx1FkSx5tT6sUdM+Bow@mail.gmail.com>
Message-ID: <CAAegNz2D3QRZSj+8nZBwy7+eWvi-VQqX3Sn2DDUpagw=xJz2FA@mail.gmail.com>

Hm, it's an almost vanilla Keycloak setup (however upgraded from 3.1.0 to
3.2.0), in fact the only changes in standalone.xml are related to the
keystore and database. I'll see if I can setup another instance and
reproduce there.

On 11 July 2017 at 07:35, Stian Thorgersen <sthorger at redhat.com> wrote:

> Tried to reproduce this, but can't and it's working just fine here. Do you
> have steps to reproduce?
>
> On 10 July 2017 at 16:04, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>
>> Hello,
>>
>> I get the following error when hitting the 'Test connection' button on the
>> email tab in Realm settings:
>>
>> 2017-07-10 15:55:27,316 INFO  [org.jboss.as] (Controller Boot Thread)
>> WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* started in
>>
>> 21731ms - Started 449 of 824 services (561 services are lazy, passive or
>> on-demand)
>> 2017-07-10 15:56:48,997 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (default task-11) RESTEASY002130: Failed to parse request.:
>> javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to create
>> URI:
>> https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
>> "port":null,"host":"mail.rdmedia.com
>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>> at
>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>> es(ResteasyUriBuilder.java:749)
>> at
>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(Resteas
>> yUriBuilder.java:721)
>> at
>> org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUr
>> iInfo.java:58)
>> at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInfo.java:53)
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletUtil.extrac
>> tUriInfo(ServletUtil.java:41)
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
>> spatcher.service(ServletContainerDispatcher.java:200)
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>> her.service(HttpServletDispatcher.java:56)
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>> her.service(HttpServletDispatcher.java:51)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>> at
>> io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
>> rvletHandler.java:85)
>> at
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>> oFilter(FilterHandler.java:129)
>> at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.d
>> oFilter(KeycloakSessionServletFilter.java:90)
>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> at
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>> oFilter(FilterHandler.java:131)
>> at
>> io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
>> terHandler.java:84)
>> at
>> io.undertow.servlet.handlers.security.ServletSecurityRoleHan
>> dler.handleRequest(ServletSecurityRoleHandler.java:62)
>> at
>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl
>> eRequest(ServletDispatchingHandler.java:36)
>> at
>> org.wildfly.extension.undertow.security.SecurityContextAssoc
>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at
>> io.undertow.servlet.handlers.security.SSLInformationAssociat
>> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>> at
>> io.undertow.servlet.handlers.security.ServletAuthenticationC
>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at
>> io.undertow.security.handlers.AbstractConfidentialityHandler
>> .handleRequest(AbstractConfidentialityHandler.java:46)
>> at
>> io.undertow.servlet.handlers.security.ServletConfidentiality
>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>> aintHandler.java:64)
>> at
>> io.undertow.security.handlers.AuthenticationMechanismsHandle
>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>> at
>> io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>> at
>> io.undertow.security.handlers.NotificationReceiverHandler.ha
>> ndleRequest(NotificationReceiverHandler.java:50)
>> at
>> io.undertow.security.handlers.AbstractSecurityContextAssocia
>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>> Handler.java:43)
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at
>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>> ndler.handleRequest(JACCContextIdHandler.java:61)
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>> stRequest(ServletInitialHandler.java:284)
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>> equest(ServletInitialHandler.java:263)
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler.access$00
>> 0(ServletInitialHandler.java:81)
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>> equest(ServletInitialHandler.java:174)
>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>> ge.java:793)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by: java.net.URISyntaxException: Illegal character in path at index
>> 67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
>> "port":null,"host":"mail.rdmedia.com
>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>> at java.net.URI$Parser.fail(URI.java:2848)
>> at java.net.URI$Parser.checkChars(URI.java:3021)
>> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
>> at java.net.URI$Parser.parse(URI.java:3053)
>> at java.net.URI.<init>(URI.java:588)
>> at
>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>> es(ResteasyUriBuilder.java:744)
>> ... 40 more
>>
>> The 67th character is the slash after testSMTPConnection. Is this a bug
>> and/or is there a workaround/fix?
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>


-- 
Tiemen Ruiten
Systems Engineer
R&D Media

From t.ruiten at rdmedia.com  Wed Jul 12 07:09:01 2017
From: t.ruiten at rdmedia.com (Tiemen Ruiten)
Date: Wed, 12 Jul 2017 13:09:01 +0200
Subject: [keycloak-user] illegal character in path when testing email
	setup
In-Reply-To: <CAAegNz2D3QRZSj+8nZBwy7+eWvi-VQqX3Sn2DDUpagw=xJz2FA@mail.gmail.com>
References: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>
	<CAJgngAf+v2vNGjJa-CH=gQxLE6qHVndJx1FkSx5tT6sUdM+Bow@mail.gmail.com>
	<CAAegNz2D3QRZSj+8nZBwy7+eWvi-VQqX3Sn2DDUpagw=xJz2FA@mail.gmail.com>
Message-ID: <CAAegNz0PmGi4Yc6T8Jw8nWSiX=X+3pBhH21+e9uaPq1ihHLVgQ@mail.gmail.com>

OK, so I rolled a new Keycloak instance and it gives me the exact same
error. Reproducing is trivial:

- login
- click Realm Settings
- click Email tab
- Fill in Host and From fields
- Hit 'Test connection'

 I can share the Ansible playbook I used to setup the VM privately if you'd
like.

On 12 July 2017 at 11:43, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:

> Hm, it's an almost vanilla Keycloak setup (however upgraded from 3.1.0 to
> 3.2.0), in fact the only changes in standalone.xml are related to the
> keystore and database. I'll see if I can setup another instance and
> reproduce there.
>
> On 11 July 2017 at 07:35, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Tried to reproduce this, but can't and it's working just fine here. Do
>> you have steps to reproduce?
>>
>> On 10 July 2017 at 16:04, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>>
>>> Hello,
>>>
>>> I get the following error when hitting the 'Test connection' button on
>>> the
>>> email tab in Realm settings:
>>>
>>> 2017-07-10 15:55:27,316 INFO  [org.jboss.as] (Controller Boot Thread)
>>> WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* started
>>> in
>>>
>>> 21731ms - Started 449 of 824 services (561 services are lazy, passive or
>>> on-demand)
>>> 2017-07-10 15:56:48,997 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>>> (default task-11) RESTEASY002130: Failed to parse request.:
>>> javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to create
>>> URI:
>>> https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
>>> "port":null,"host":"mail.rdmedia.com
>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>>> at
>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>>> es(ResteasyUriBuilder.java:749)
>>> at
>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(Resteas
>>> yUriBuilder.java:721)
>>> at
>>> org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUr
>>> iInfo.java:58)
>>> at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInf
>>> o.java:53)
>>> at
>>> org.jboss.resteasy.plugins.server.servlet.ServletUtil.extrac
>>> tUriInfo(ServletUtil.java:41)
>>> at
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
>>> spatcher.service(ServletContainerDispatcher.java:200)
>>> at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>>> her.service(HttpServletDispatcher.java:56)
>>> at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>>> her.service(HttpServletDispatcher.java:51)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>> at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
>>> rvletHandler.java:85)
>>> at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>>> oFilter(FilterHandler.java:129)
>>> at
>>> org.keycloak.services.filters.KeycloakSessionServletFilter.d
>>> oFilter(KeycloakSessionServletFilter.java:90)
>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilte
>>> r.java:60)
>>> at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>>> oFilter(FilterHandler.java:131)
>>> at
>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
>>> terHandler.java:84)
>>> at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHan
>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)
>>> at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl
>>> eRequest(ServletDispatchingHandler.java:36)
>>> at
>>> org.wildfly.extension.undertow.security.SecurityContextAssoc
>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>> at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at
>>> io.undertow.servlet.handlers.security.SSLInformationAssociat
>>> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>> at
>>> io.undertow.servlet.handlers.security.ServletAuthenticationC
>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>> at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at
>>> io.undertow.security.handlers.AbstractConfidentialityHandler
>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>> at
>>> io.undertow.servlet.handlers.security.ServletConfidentiality
>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>> aintHandler.java:64)
>>> at
>>> io.undertow.security.handlers.AuthenticationMechanismsHandle
>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>> at
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>> at
>>> io.undertow.security.handlers.NotificationReceiverHandler.ha
>>> ndleRequest(NotificationReceiverHandler.java:50)
>>> at
>>> io.undertow.security.handlers.AbstractSecurityContextAssocia
>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>> Handler.java:43)
>>> at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>> at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>> stRequest(ServletInitialHandler.java:284)
>>> at
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>> equest(ServletInitialHandler.java:263)
>>> at
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>> 0(ServletInitialHandler.java:81)
>>> at
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>> equest(ServletInitialHandler.java:174)
>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>> ge.java:793)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1142)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:748)
>>> Caused by: java.net.URISyntaxException: Illegal character in path at
>>> index
>>> 67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
>>> "port":null,"host":"mail.rdmedia.com
>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>>> at java.net.URI$Parser.fail(URI.java:2848)
>>> at java.net.URI$Parser.checkChars(URI.java:3021)
>>> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
>>> at java.net.URI$Parser.parse(URI.java:3053)
>>> at java.net.URI.<init>(URI.java:588)
>>> at
>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>>> es(ResteasyUriBuilder.java:744)
>>> ... 40 more
>>>
>>> The 67th character is the slash after testSMTPConnection. Is this a bug
>>> and/or is there a workaround/fix?
>>>
>>> --
>>> Tiemen Ruiten
>>> Systems Engineer
>>> R&D Media
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>



-- 
Tiemen Ruiten
Systems Engineer
R&D Media

From mposolda at redhat.com  Wed Jul 12 07:17:40 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 13:17:40 +0200
Subject: [keycloak-user] Identity provider,
 keycloak js adapter and session management
In-Reply-To: <1727835614.580304.1499443610670@mail.yahoo.com>
References: <1727835614.580304.1499443610670.ref@mail.yahoo.com>
	<1727835614.580304.1499443610670@mail.yahoo.com>
Message-ID: <219ed4ff-fd22-0f2a-2231-cdbe8480cf86@redhat.com>

There was some related fix in latest master 
https://issues.jboss.org/browse/KEYCLOAK-5139 . However your issue with 
iframe looks like something different. Feel free to create JIRA if it 
won't help.

Ideally you can also send PR. We have tests for pairwise in 
OIDCPairwiseClientRegistrationTest.java 
<https://github.com/keycloak/keycloak/commit/8cb8678525cd660530ec3b875ff7e0316c1b8742#diff-8595a2b898ec26c6d7856cae9f93d4f5> 
and there are some IFrame related tests in LoginStatusIframeEndpointTest .

Marek

On 07/07/17 18:06, Peter Nalyvayko wrote:
> Some additional info: we can also reproduce the same behavior using the Pairwise subject identifier, i.e. users keep getting logged out after 5 seconds.
>
> --------------------------------------------
> On Thu, 7/6/17, Peter Nalyvayko <petervn1 at yahoo.com> wrote:
>
>   Subject: Identity provider, keycloak js adapter and session management
>   To: keycloak-user at lists.jboss.org
>   Date: Thursday, July 6, 2017, 12:10 PM
>   
>   Hi,
>   
>   We've hit a bit of a snag while setting
>   up our one page js client. Changing the value of the "sub"
>   claim to anything other than the unique identifier of the
>   keycloak user causes the keycloak adapter to detect the
>   changes to the session and clear out the tokens, forcing the
>   users to re-log in after every 5 seconds.
>    
>   We are using the version 2.3.0 of
>   keycloak. Our app is set up to use keycloak.js adapter for
>   all things related to OIDC. The adapter is configured to use
>   the "code authorization" (standard) flow. The instance of
>   keycloak is configured to use an external OIDC identity
>   provider and the users are uniquely identified by their
>   e-mails. Naturally, we wanted that the "sub" claim in the
>   claim set returned by calling the keycloak's OIDC /token
>   endpoint would return the unique identity of the external
>   user rather than the internal identifier of the keycloak
>   user, so we re-configured the keycloak client by adding a
>   property mapper to map the user's email to the "sub" claim,
>   here the example of the access token:
>   {
>      "sub": "user at company.com",
>      "iat": 223235098325,
>      "email": "user at company.com",
>      ...
>   }
>   
>   Once we had implemented these changes
>   on the keycloak side, our users were able to initially sign
>   into the application, but when they tried to access any
>   functionality within the app, they would be prompted to sign
>   in again. The problem seems to related to the OIDC session
>   management and the assumption and the "sub" claim always
>   matches the keycloak user's unique identifier.
>   
>   We narrowed the problem down to four
>   components:
>   
>   - keycloak.js
>   - login-status-iframe.html
>   -
>   services\srv\main\java\org\keycloak\protocol\oidc\endpoints\LoginStatusIframeEndpoint.java
>   -
>   services\src\main\java\org\keycloak\services\managers\AuthenticationManager.java
>    
>   In keycloak.js, line 637, the
>   implementation creates a session id to be used to check the
>   session state. Notice that the code uses the value from the
>   "sub" claim:
>      var sessionId = kc.realm + "/"
>   + kc.tokenParsed.sub;
>     
>   In
>   AuthenticationManager.createLoginCookie, line 306, the value
>   of the "SESSION_COOKIE" is set to:
>   
>     String sessionCookieValue =
>   realm.getName() + "/" + user.getId();
>   
>   Sadly, in our configuration, the value
>   returned of by user.getId() is not the same as the value
>   stored in the "sub" claim, thus causing the session
>   management code in login-status-iframe.html, line 53 to
>   clear out any tokens and force the users to re-login the
>   next time it checks the session state (default is 5 second
>   intervals):
>   
>     var cookie = getCookie();
>     if (sessionState == cookie) {
>   ... } else { callback("changed"); }
>   
>    
>   Looking at the
>   LoginStatusIframeEndpoint.preCheck
>   (LoginSatusIframeEndpoint.java, lines 71-93), we've noticed
>   that the implementation does not even make use of the user
>   identity, only the session id.
>   
>   The workaround, at least temporary, for
>   us was to add the "id" claim containing the user identity
>   internal to keycloak, and modify the keycloak JS adapter
>   code to look for the "id" claim and use its value instead of
>   the value in the "sub" claim when creating the session id,
>   i.e.:
>   
>     
>      var sessionId;
>      if (kc.tokenParsed.id) {
>         sessionId =
>   kc.realm + "/" + kc.tokenParsed.id;
>      } else {
>         sessionId =
>   kc.realm + "/" + kc.tokenParsed.sub;
>      }
>   
>   Is this a bug, or does it work as
>   intended, i.e. the users should never set the "sub" claim to
>   anything other than the keycloak's user identity? If this is
>   a bug, I can submit a JIRA request and a fix as long as the
>   workaround above seems like an acceptable solution
>   
>   Any comments are welcome
>   Regards,
>   Peter
>   
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 12 07:24:14 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 13:24:14 +0200
Subject: [keycloak-user] LDAP attributes & caching
In-Reply-To: <1499337987.2966.2.camel@cargosoft.ru>
References: <1499289029.2978.3.camel@cargosoft.ru>
	<1499337987.2966.2.camel@cargosoft.ru>
Message-ID: <1488d902-6af3-893a-5936-807402fa4b5a@redhat.com>

"Always Read Value From LDAP" means that attribute is read from LDAP 
instead of from DB. However the cache is still there. You will need to 
disable cache or change it to low value if you want the user updated 
immediately after attribute change in LDAP.


Marek

On 06/07/17 12:46, Dmitry Telegin wrote:
> https://issues.jboss.org/browse/KEYCLOAK-5156
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 12 07:29:23 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 13:29:23 +0200
Subject: [keycloak-user] LDAP User Federation: Issue with Hardcoded Roles
In-Reply-To: <CAKp1Nw6owuPz7oHt8KRWDGM_k6s3eMX9q3PnSFDmHEbkLqmoOQ@mail.gmail.com>
References: <CAKp1Nw6owuPz7oHt8KRWDGM_k6s3eMX9q3PnSFDmHEbkLqmoOQ@mail.gmail.com>
Message-ID: <36248726-62a8-4117-6fc6-99365de6f59f@redhat.com>

Looks like a bug to me. Feel free to create JIRA.

Marek

On 06/07/17 20:45, Gabriel Lavoie wrote:
> Hi,
>       I've been trying to setup a LDAP user federation with a hardcoded
> admin role on Keycloak 2.1.0.Final, on the master realm. The role is
> granted to the user as expected, but not the composite roles attached to
> the "admin" role.
>
> I tried reproducing the issue with the latest Keycloak but encountered a
> different problem. When I try to add the hardcoded role mapper and add the
> "admin" role to it, the role displays as "a" in the field (after
> selection), and I get an error on save. I get the following exception in
> the log:
>
> 2017-07-06 14:43:36,727 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
> (default task-18) RESTEASY002005: Failed executing POST
> /admin/realms/master/components: org.jboss.resteasy.spi.ReaderException:
> com.fasterxml.jackson.databind.JsonMappingException: Can not deserialize
> instance of java.util.ArrayList out of VALUE_STRING token
>   at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 1611369f;
> line: 1, column: 12] (through reference chain:
> org.keycloak.representations.idm.ComponentRepresentation["config"]->org.keycloak.common.util.MultivaluedHashMap["role"])
>          at
> org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:184)
>          at
> org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:91)
>          at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:114)
>          at
> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
>          at
> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
>          at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
>          at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
>          at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
>          at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>          at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>          at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>          at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>          at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
>          at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>          at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>          at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>          at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>          at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>          at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>          at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>          at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>          at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>          at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>          at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>          at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>          at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>          at
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>          at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>          at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
>          at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>          at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>          at java.lang.Thread.run(Thread.java:745)
> Caused by: com.fasterxml.jackson.databind.JsonMappingException: Can not
> deserialize instance of java.util.ArrayList out of VALUE_STRING token
>   at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 1611369f;
> line: 1, column: 12] (through reference chain:
> org.keycloak.representations.idm.ComponentRepresentation["config"]->org.keycloak.common.util.MultivaluedHashMap["role"])
>          at
> com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:148)
>          at
> com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:835)
>          at
> com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:831)
>          at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.handleNonArray(StringCollectionDeserializer.java:240)
>          at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:171)
>          at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:161)
>          at
> com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:19)
>          at
> com.fasterxml.jackson.databind.deser.std.MapDeserializer._readAndBindStringMap(MapDeserializer.java:485)
>          at
> com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:342)
>          at
> com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:26)
>          at
> com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:523)
>          at
> com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:95)
>          at
> com.fasterxml.jackson.databind.deser.impl.BeanPropertyMap.findDeserializeAndSet(BeanPropertyMap.java:285)
>          at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:248)
>          at
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:136)
>          at
> com.fasterxml.jackson.databind.ObjectReader._bind(ObjectReader.java:1410)
>          at
> com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:860)
>          at
> org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.readFrom(ResteasyJackson2Provider.java:121)
>          at
> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:61)
>          at
> org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:60)
>          at
> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:53)
>          at
> org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:34)
>          at
> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:55)
>          at
> org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.aroundReadFrom(GZIPDecodingInterceptor.java:59)
>          at
> org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:55)
>          at
> org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:151)
>          ... 48 more
>
>
> Any idea of what could be wrong? Bug?
>
> Thank you,
>
> Gabriel
>


From K.Buler at adbglobal.com  Wed Jul 12 08:23:28 2017
From: K.Buler at adbglobal.com (Karol Buler)
Date: Wed, 12 Jul 2017 14:23:28 +0200
Subject: [keycloak-user] Fwd: CORS's problem with JavaScript's library
In-Reply-To: <ac529659f1b3485487a1e57322a6d34b@PHINEAS.ppg.lan>
References: <430dc3ea-ebdd-4503-494a-eac0607ae0c1@adbglobal.com>
	<CAMZCGg87VSrkuTWM=CKgnzHFrp7oNU+h85KG9EcSDJ_SKgweDw@mail.gmail.com>
	<CAMZCGg_hS9YOMLr8-5mi6PWuEufxiW-xSsJeR48rBraFASdxsw@mail.gmail.com>
	<c65cd0e1-eda9-286e-7fff-65f65f69ec89@adbglobal.com>
	<ac529659f1b3485487a1e57322a6d34b@PHINEAS.ppg.lan>
Message-ID: <f6a98ea2-5933-a766-3667-36f5353c307d@adbglobal.com>

Kevin you have 100% right! But we didn't modify Keycloak server and JS 
lib at all. Clean server and clean library have a problem with 
communication.


On 29.06.2017 13:24, Kevin Berendsen wrote:
> Hi,
>
> This is a perfect response from your browser. X-client is a custom header and not allowed out of the box.
> I think either you should strip that header from your request to Keycloak or modify Keycloak to allow that header or some sort (not recommend).
>
> You could also modify your standalone configuration to add a response header but that's not really recommended either.
>
>> -----Oorspronkelijk bericht-----
>> Van: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-
>> bounces at lists.jboss.org] Namens Karol Buler
>> Verzonden: donderdag 29 juni 2017 10:30
>> Aan: keycloak-user at lists.jboss.org
>> Onderwerp: Re: [keycloak-user] Fwd: CORS's problem with JavaScript's
>> library
>>
>> We are using keycloak-auth-utils because our application isn't strict frontend.
>> It is something like "middle-end" app. We can't use e.g. code flow
>> authentication.
>>
>> Secondly... yes, We applied "*" to "Web Origins".
>>
>>
>> On 28.06.2017 16:47, Sebastien Blanc wrote:
>>> (forgot including user list)
>>>
>>> Are you using keycloak-auth-utils on your frontend application ? Why
>>> not the JavaScript library ?
>>> Also have you configured the "Web Origins" field of your client in the
>>> Keycloak Web Console ?
>>>
>>> On Wed, Jun 28, 2017 at 3:09 PM, Karol Buler <K.Buler at adbglobal.com>
>> wrote:
>>>> Hi Everyone,
>>>>
>>>> We have problem with CORS. We are using this lib:
>>>> https://www.npmjs.com/package/keycloak-auth-utils in our JavaScript
>>>> application.
>>>>
>>>> When we try to get AccessToken we are getting this message:
>>>>
>>>> Fetch API cannot load http://<keycloak_address>/auth
>>>> /realms/master/protocol/openid-connect/token. Request header field
>>>> x-client is not allowed by Access-Control-Allow-Headers in preflight
>>>> response.
>>>>
>>>> We tried to modify CORS headers in standalone.xml file of Keycloak's
>>>> server, but we found that CORS headers are hardcoded and added "in
>> air".
>>>> Best regards,
>>>> Karol Buler
>>>>
>>>> [https://www.adbglobal.com/wp-content/uploads/adb.png]
>>>> connecting lives
>>>> connecting worlds
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From psilva at redhat.com  Wed Jul 12 09:08:22 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 12 Jul 2017 10:08:22 -0300
Subject: [keycloak-user] Authorization services without User Access
 token (Mqtt Broker / IoT)
In-Reply-To: <CA+eBSFQrRWYFm7xjK5PGE_JVg6UVy+sXTVGUuPSkD8wkMsx=7w@mail.gmail.com>
References: <CA+eBSFQrRWYFm7xjK5PGE_JVg6UVy+sXTVGUuPSkD8wkMsx=7w@mail.gmail.com>
Message-ID: <CAJrcDBfqHjvePxb71mL=JE9Wfy3LmTjXYwzr3ehqZo-Xs-qFjA@mail.gmail.com>

Hi,

Some questions inline ...

On Tue, Jul 11, 2017 at 9:10 PM, Brahim Ait elhaj <brahima at gmail.com> wrote:

> Hi everyone,
>
> Lately i was playing with Keycloak (KC), evaluating it for an IoT project
> and i have a question regarding the authorization services.
>
> One of my use case is : devices that connect to an MQTT Broker using X.509
> client authentication.


> Note : when i talk about device, you must understand KC user (device =
> user).
>

Do clients connect to your MQTT on behalf of an human ?

If a device is actually an user, who are your clients ? The same devices ?


>
> For several reasons/constraints that i won't explain here, i can't have my
> devices connect first to Keycloak to obtain a token (using their X.509
> certificates as KC supports it) and then connect to the MQTT Broker passing
> this token. They connect directly to the MQTT Broker, each device
> presenting its X.509 certificate to the Broker. After connection, the
> Broker doesn't know client private key.


Now I'm curious :)


>
> My need is to have my MQTT Broker (ideally through KC) authorize/reject
> MQTT client to publish/subscribe to specific topic.
> MQTT Topic being some kind of uri/path, i already have an idea of how to
> configure KC (client, resource, policy, permission ...) to authorize/reject
> these access.


> However, as i understand it, the starting point for all the ? authorization
> services ? (Authorization API, Entitlement API ... ) is a ? user Access
> Token ?.
> In my case, i don't have a user access token ... so i'm kind of stuck to
> use any of the K.C API (unless i missed something).
>

Considering your devices are actually users in your realm, you should be
able to obtain access tokens from Keycloak. With this access token you can
then use Entitlement API, for instance to obtain a RPT that you can finally
send to your MQTT broker. But I think you have constraints that block this
approach ...

The point here is that our APIs need to identify the identity associated
with a permission request somehow, hence the need for an access token when
using any of our APIs to obtain the RPT.

If I understood your use correctly, the only thing you have that identifies
the user/device is a certificate. But we only support access tokens
previously issued by Keycloak to your clients/users.

However, I think we could support your use case with UMA 2.0 changes we are
planning. In the new version of the specs, the client don't actually need
an access token in order to obtain RPTs from AS. There is a specific OAuth2
Grant Type, which you can use just like any other grant type. The tricky
here is that instead of using an OAuth2 Access Token to gain access to our
APIs, you basically authenticate the client using whatever client
authentication method we support. For instance, id/secret, jwt or even
using a bearer token (as it stands today). In addition to that, you are
allowed to send tokens with claims associated with a requesting party
(e.g.: your devices). That would allow you to send your devices
certificates.

In a nutshell, in a single request to the server you would provide your
client credentials + device certificate. And we would need to support
extracting requesting party information (the user) from certificates.


>
> Hence, My question is how can i make my MQTT Broker (.ie : resource server)
> interact with KC to enforce/evaluate policy ? Is it possible without the
> user access token ?


> Hope i made myself clear and thanks in advance for any help ...
>

Btw, have you considered OAuth2 Device Flow ?


>
> Best regards,
> Brahim
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From psilva at redhat.com  Wed Jul 12 09:20:32 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 12 Jul 2017 10:20:32 -0300
Subject: [keycloak-user] Application to application: could Keycloak
 implement this?
In-Reply-To: <dfa9baa2-6fe4-a3a9-8296-09cc6226812c@redhat.com>
References: <7d4227a7-9bc4-0a93-dffb-c1daa725b0fa@psynd.net>
	<dfa9baa2-6fe4-a3a9-8296-09cc6226812c@redhat.com>
Message-ID: <CAJrcDBeAQ-5zVBmR_8vPi=06LD3HKZ5k=6FGm5aUCdTON2Ko1w@mail.gmail.com>

FYI, in Wildfly 11 and Elytron identity propagation will be supported OOTB.
This is one of the main features brought to you by Elytron.

Your client should be able to authenticate with a remote server using a
OAuth2 Access Token (remoting + SASL OAUTHBEARER), which in turn can be
automatically propagated to other servers in the topology. In fact, you can
even propagate credentials if using other authentication mechanism such as
PLAIN or Kerberos.

On Wed, Jul 12, 2017 at 4:10 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
>
> We have example in documentation for EJB propagation from web
> application where Keycloak. See
> https://keycloak.gitbooks.io/documentation/securing_apps/
> topics/oidc/java/jboss-adapter.html
> and especially the last paragraph "Security domain" .
>
> We have unofficial example I've written to propagate identity from fat
> client through remote EJB calls:
> https://github.com/mposolda/keycloak-remote-ejb
>
> Marek
>
> On 04/07/17 18:42, Tech wrote:
> > Dear experts,
> >
> > I want to bring you this use case to understand if you might be able to
> > support me.
> >
> > Our architecture is based in java, where we might have two kind of
> clients:
> >
> >    * Fat java clients
> >    * Browsers
> >
> > Application servers with:
> >
> >    * Web containers performing local and remote EJB calls + remote WS
> calls
> >    * EJB container performing local and remote EJB calls + remote WS
> calls
> >    * A remote EJB server performing local and remote EJB calls + remote
> >      WS calls
> >    * Ws implemeting SOAP or REST
> >    * Server SSO able to protect what described above
> >
> > The goal is to allow the clients (thin and fat) to authenticate on the
> > SSO server and to propagate the user identity on these requests:
> >
> >    * Fat client authenticated -> EJB secure -> WS secure
> >    * Browser authenticated -> Web container -> EJB secure -> WS secure
> >
> > The solution could use a secure token OAuth, OIDC or SAML.
> >
> > The token propagation should be based on standards JAAS and WS-Security.
> >
> > We saw that is possible to implement something similar in some SAML
> > Login Modules on JBoss Enterprise server, but we are not finding
> > anything equivalent in Keycloak.
> >
> > We cannot neither find, for example, not neither for a STS server, that
> > are the required elements to transform this kind of tokens.
> >
> >
> > Did anybody faced a similar experience?
> >
> > Thanks for your support!
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From jasonspittel at yahoo.com  Wed Jul 12 10:29:58 2017
From: jasonspittel at yahoo.com (Jason Spittel)
Date: Wed, 12 Jul 2017 14:29:58 +0000 (UTC)
Subject: [keycloak-user] SAML HttpServletRequest.logout() support
In-Reply-To: <fffcbdc9-66d9-35c2-5391-406bc247247a@redhat.com>
References: <1263738321.6142511.1499280048359.ref@mail.yahoo.com>
	<1263738321.6142511.1499280048359@mail.yahoo.com>
	<fffcbdc9-66d9-35c2-5391-406bc247247a@redhat.com>
Message-ID: <558367677.4396667.1499869798560@mail.yahoo.com>

Hi Mark,
You can see my other thread to Hynek Mlnarik about logout and cookies. It's sort of a JSF issue, I suppose, more than a KC issue. Actually, I'l just copy the email here.
The TLDR; version is : JSF redirect on logout loses cookies, so has to re-auth with KC before logging out. Which means the first logout doesn't 'take'.


Hi Hynek,
My setup is exactly from that tutorial. And I found the problem with logging out, I'm not sure how to report the issue (not sure if it's really a KC issue at all), raise a Jira ticket?

Setup:
JEE app running JSF calling EJBs.
JEE app using wildfly keycloak saml adapters to talk to Keycloak (KC)Keycloak setup to use ADFS as its IdP.

Problem:
JEE app needs to logout twice to logout. (That is, after first logout, you can still hit the protected resource on the JEE app without logging in again)

Cause:
1) first logout:- JSF's redirects (externalContext.redirect(externalContext.getRequestContextPath() + "/?GLO=true" );) removes the jsessionId cookie, which causes an initial auth from JEE to KC when logout is hit. -rest of logout proceeds properly, Realm Session ID is removed from KC, ADFS logs use out.

2) second logout-JSF's redirect again removes the jsessionId cookie, tries to do an initial auth from JEE to KC, but KC doesn't have any sessions to auth user with, and user is kicked out, 'successfully' logging out.

Solution:
preserve the jsessionid on redirect, initial auth to KC doesn't occur on logout.
?? public void logout() throws IOException, ServletException
?? {
??????ExternalContext externalContext = _context.getExternalContext();

??????try
??????{
???????? externalContext.invalidateSession();

???????? _httpRequest.logout();
??????}
??????catch (Exception ex)
??????{
???????? _logger.error(ex);
??????}
??????finally
??????{
???????? // need to set the cookie for the jsessionid, or will re-auth with KC, and will require two logouts to logout completely
???????? preserveJsessionidCookie(externalContext);

???????? externalContext.redirect(externalContext.getRequestContextPath() + "/?GLO=true" );
??????}
?? }

?? private void preserveJsessionidCookie(ExternalContext externalContext)
?? {
??????for (Cookie cookie : ((HttpServletRequest)externalContext.getRequest()).getCookies())
??????{
???????? if (cookie.getName().equalsIgnoreCase("jsessionid"))
???????? {
????????????((HttpServletResponse)externalContext.getResponse()).addCookie(cookie);
????????????break;
???????? }
??????}
?? }

Cheers,


Thanks, 
Jason
On Tuesday, July 11, 2017, 11:59:41 PM PDT, Marek Posolda <mposolda at redhat.com> wrote:

You can check our SAML examples in the keycloak-examples distribution. 
They're doing logout.

Marek

On 05/07/17 20:40, Jason Spittel wrote:
> I'm having trouble with SAML Logout.? I have a JEE app that uses Keycloak as an identity broker to ADFS.
> Following these instructions:Logout | Keycloak Documentation
>
>
> |
> |
> |? |
> Logout | Keycloak Documentation
>
>
>? |
>
>? |
>
>? |
>
>
>
> I should be able to just call HttpServletRequest.logout(). But that doesn't do anything.
> Searching Jira I see this a reported issue.
> [KEYCLOAK-2191] SAML HttpServletRequest.logout() support - JBoss Issue Tracker
>
>
> |
> |
> |? |
> [KEYCLOAK-2191] SAML HttpServletRequest.logout() support - JBoss Issue T...
>
>
>? |
>
>? |
>
>? |
>
>
>
> While that's being worked on, are there workarounds to do a SAML logout through Keycloak?
>
> Thanks,
> Jason
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From brahima at gmail.com  Wed Jul 12 12:23:48 2017
From: brahima at gmail.com (Brahim Ait elhaj)
Date: Wed, 12 Jul 2017 18:23:48 +0200
Subject: [keycloak-user] Authorization services without User Access
 token (Mqtt Broker / IoT)
In-Reply-To: <CAJrcDBfqHjvePxb71mL=JE9Wfy3LmTjXYwzr3ehqZo-Xs-qFjA@mail.gmail.com>
References: <CA+eBSFQrRWYFm7xjK5PGE_JVg6UVy+sXTVGUuPSkD8wkMsx=7w@mail.gmail.com>
	<CAJrcDBfqHjvePxb71mL=JE9Wfy3LmTjXYwzr3ehqZo-Xs-qFjA@mail.gmail.com>
Message-ID: <CA+eBSFSrQ5M-R9smPnKUoZ1cwTDamqt9EL9A-ejb3b4ORYfNPg@mail.gmail.com>

Hi and thanks a lot for your feedback.

My answers/questions below ...

On Wed, Jul 12, 2017 at 3:08 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> Some questions inline ...
>
> On Tue, Jul 11, 2017 at 9:10 PM, Brahim Ait elhaj <brahima at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> Lately i was playing with Keycloak (KC), evaluating it for an IoT project
>> and i have a question regarding the authorization services.
>>
>> One of my use case is : devices that connect to an MQTT Broker using X.509
>> client authentication.
>
>
>> Note : when i talk about device, you must understand KC user (device =
>> user).
>>
>
> Do clients connect to your MQTT on behalf of an human ?
>

Once device are provisioned in the platform (done once through an app),
they become autonomous and can start connecting/talking to the MQTT Server
at any moment ...


>
> If a device is actually an user, who are your clients ? The same devices ?
>

My client is the MQTT Server in this use case (as the *photoz-restful-api*
in the *photoz* example).
I want to protect access to MQTT topics (paths/resources) of this MQTT
server.

I was initially asking myself whereas devices should be ? users ? or ?
clients ? but we could end with a lot of clients in the latter scenario ...
also after playing with KC and reading through the mailing list
questions/answers, i think that's a better approach to have devices be
users and not clients.

However, did you have something in mind when asking this question ?


>
>
>>
>> For several reasons/constraints that i won't explain here, i can't have my
>> devices connect first to Keycloak to obtain a token (using their X.509
>> certificates as KC supports it) and then connect to the MQTT Broker
>> passing
>> this token. They connect directly to the MQTT Broker, each device
>> presenting its X.509 certificate to the Broker. After connection, the
>> Broker doesn't know client private key.
>
>
> Now I'm curious :)
>

Ok, the main reason is that the one thing that can be guaranteed about
devices is that they have a certificate to authenticate themselves. They're
not necessarily http or even mqtt capable. They can be able to communicate
only via a low power wide area network (Lora / Sigfox ... ie. not connected
to internet directly)

So we know how to deal with a user (be it a human or a device) that can
authenticate and get an access token.
My concern here is how to deal with a user (device) that can not.


>
>
>>
>> My need is to have my MQTT Broker (ideally through KC) authorize/reject
>> MQTT client to publish/subscribe to specific topic.
>> MQTT Topic being some kind of uri/path, i already have an idea of how to
>> configure KC (client, resource, policy, permission ...) to
>> authorize/reject
>> these access.
>
>
>> However, as i understand it, the starting point for all the ?
>> authorization
>> services ? (Authorization API, Entitlement API ... ) is a ? user Access
>> Token ?.
>> In my case, i don't have a user access token ... so i'm kind of stuck to
>> use any of the K.C API (unless i missed something).
>>
>
> Considering your devices are actually users in your realm, you should be
> able to obtain access tokens from Keycloak. With this access token you can
> then use Entitlement API, for instance to obtain a RPT that you can finally
> send to your MQTT broker. But I think you have constraints that block this
> approach ...
>

> The point here is that our APIs need to identify the identity associated
> with a permission request somehow, hence the need for an access token when
> using any of our APIs to obtain the RPT.
>

Exactly, i technically can have some devices (http capable) connect to KC,
get a token et connect to the MQTT Broker ... but some devices cannot so i
need to support this use case.


>
> If I understood your use correctly, the only thing you have that
> identifies the user/device is a certificate. But we only support access
> tokens previously issued by Keycloak to your clients/users.
>

Right !


>
> However, I think we could support your use case with UMA 2.0 changes we
> are planning. In the new version of the specs, the client don't actually
> need an access token in order to obtain RPTs from AS. There is a specific
> OAuth2 Grant Type, which you can use just like any other grant type. The
> tricky here is that instead of using an OAuth2 Access Token to gain access
> to our APIs, you basically authenticate the client using whatever client
> authentication method we support. For instance, id/secret, jwt or even
> using a bearer token (as it stands today). In addition to that, you are
> allowed to send tokens with claims associated with a requesting party
> (e.g.: your devices). That would allow you to send your devices
> certificates.
>
> In a nutshell, in a single request to the server you would provide your
> client credentials + device certificate. And we would need to support
> extracting requesting party information (the user) from certificates.
>

Yes, it seems really interesting and corresponding to what i'd like to
achieve. Since you talk about UMA, i understand this is the ? Authorization
API ? that is involved here.

Also, you said ? *In the new version of the specs, the client don't
actually need an access token in order to obtain RPTs from AS* ?, can you
please point me to the specs that talk about this specific part (if
possible) ? I quickly went through the v2.0 without being able to clearly
identity this specific part ...

Do you have something (beta ...) that i can start playing with ? Is it
already in the roadmap (maybe you have a specific ticket number in mind) ?

Depending on the estimated ? landing ? date, i can contribute in many ways.
So, What's the next step :-)


>
>

>
>>
>> Hence, My question is how can i make my MQTT Broker (.ie : resource
>> server)
>> interact with KC to enforce/evaluate policy ? Is it possible without the
>> user access token ?
>
>
>> Hope i made myself clear and thanks in advance for any help ...
>>
>
> Btw, have you considered OAuth2 Device Flow ?
>

Yes, can make sense for some devices (http capable, internet connected ...)
but not for all devices ...


Thanks again for your feedbacks. Greatly appreciated !
Brahim


>
>
>>
>> Best regards,
>> Brahim
>>
>



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

From psilva at redhat.com  Wed Jul 12 13:19:03 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 12 Jul 2017 14:19:03 -0300
Subject: [keycloak-user] Authorization services without User Access
 token (Mqtt Broker / IoT)
In-Reply-To: <CA+eBSFSrQ5M-R9smPnKUoZ1cwTDamqt9EL9A-ejb3b4ORYfNPg@mail.gmail.com>
References: <CA+eBSFQrRWYFm7xjK5PGE_JVg6UVy+sXTVGUuPSkD8wkMsx=7w@mail.gmail.com>
	<CAJrcDBfqHjvePxb71mL=JE9Wfy3LmTjXYwzr3ehqZo-Xs-qFjA@mail.gmail.com>
	<CA+eBSFSrQ5M-R9smPnKUoZ1cwTDamqt9EL9A-ejb3b4ORYfNPg@mail.gmail.com>
Message-ID: <CAJrcDBcvuRtYaQcT1ruiV-5c0s5ZEnRx6=oGw811PfFdZB_0oA@mail.gmail.com>

On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima at gmail.com> wrote:

>
>> If a device is actually an user, who are your clients ? The same devices ?
>>
>
> My client is the MQTT Server in this use case (as the *photoz-restful-api*
> in the *photoz* example).
> I want to protect access to MQTT topics (paths/resources) of this MQTT
> server.
>
> I was initially asking myself whereas devices should be ? users ? or ?
> clients ? but we could end with a lot of clients in the latter scenario ...
> also after playing with KC and reading through the mailing list
> questions/answers, i think that's a better approach to have devices be
> users and not clients.
>
> However, did you have something in mind when asking this question ?
>

I was wondering if the users you mentioned were actually service accounts
associated with clients representing your devices. But yeah, the decision
on whether devices should be users or not I think depend on the
capabilities you want to support on them.


>
>
>>
>>
>>>
>>> For several reasons/constraints that i won't explain here, i can't have
>>> my
>>> devices connect first to Keycloak to obtain a token (using their X.509
>>> certificates as KC supports it) and then connect to the MQTT Broker
>>> passing
>>> this token. They connect directly to the MQTT Broker, each device
>>> presenting its X.509 certificate to the Broker. After connection, the
>>> Broker doesn't know client private key.
>>
>>
>> Now I'm curious :)
>>
>
> Ok, the main reason is that the one thing that can be guaranteed about
> devices is that they have a certificate to authenticate themselves. They're
> not necessarily http or even mqtt capable. They can be able to communicate
> only via a low power wide area network (Lora / Sigfox ... ie. not connected
> to internet directly)
>
> So we know how to deal with a user (be it a human or a device) that can
> authenticate and get an access token.
> My concern here is how to deal with a user (device) that can not.
>

Ok, so that changes things a bit ...


>
>> However, I think we could support your use case with UMA 2.0 changes we
>> are planning. In the new version of the specs, the client don't actually
>> need an access token in order to obtain RPTs from AS. There is a specific
>> OAuth2 Grant Type, which you can use just like any other grant type. The
>> tricky here is that instead of using an OAuth2 Access Token to gain access
>> to our APIs, you basically authenticate the client using whatever client
>> authentication method we support. For instance, id/secret, jwt or even
>> using a bearer token (as it stands today). In addition to that, you are
>> allowed to send tokens with claims associated with a requesting party
>> (e.g.: your devices). That would allow you to send your devices
>> certificates.
>>
>> In a nutshell, in a single request to the server you would provide your
>> client credentials + device certificate. And we would need to support
>> extracting requesting party information (the user) from certificates.
>>
>
> Yes, it seems really interesting and corresponding to what i'd like to
> achieve. Since you talk about UMA, i understand this is the ? Authorization
> API ? that is involved here.
>

That is one of the changes introduced by UMA 2.0. The Authorization API was
replaced by a UMA Grant Type [1]. We are going to deprecate the
Authorization API and leave it there for a while. But remove it in future
releases.

My statement above also applies to our Entitlement API, which we also want
to support scenarios where the identity is not really represented by an ID
or access token.

[1]
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html#seek-authorization


>
> Also, you said ? *In the new version of the specs, the client don't
> actually need an access token in order to obtain RPTs from AS* ?, can you
> please point me to the specs that talk about this specific part (if
> possible) ? I quickly went through the v2.0 without being able to clearly
> identity this specific part ...
>

See link above.


>
> Do you have something (beta ...) that i can start playing with ? Is it
> already in the roadmap (maybe you have a specific ticket number in mind) ?
>

Nothing yet ... But this is my next task in Keycloak. At the moment I'm
stuck with tasks in other projects that I need to get it done. But the JIRA
is https://issues.jboss.org/browse/KEYCLOAK-3169.


>
> Depending on the estimated ? landing ? date, i can contribute in many
> ways. So, What's the next step :-)
>

Sure thing. Maybe you can start providing some more background to what you
need in that JIRA. Although the title is related with UMA 2.0 it will also
involve changes to Entitlement API.

The initial plan did not include what we are discussing here. But I think
we can consider your requirements during development once we agree on what
we really need to do.

Maybe another approach to your problem is make your MQTT Broker both a PDP
and PEP. I mean, you would use some REST API in Keycloak to evaluate
policies based on a set of one or more resources/topics + enforce access
based on the permissions returned by the server. We do have an endpoint
that you can use to evaluate policies (see
https://github.com/keycloak/keycloak/blob/master/integration/admin-client/src/main/java/org/keycloak/admin/client/resource/PoliciesResource.java#L70).
But it is basically accessing the API used by our Policy Evaluation Toll in
the admin console. Ideally, you should use Entitlement API, Authorization
API/UMA Grant Type.


>
>>
>>
>>>
>>> Best regards,
>>> Brahim
>>>
>>
>
>
>
>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>

From manuel.holtgrewe at bihealth.de  Wed Jul 12 14:39:03 2017
From: manuel.holtgrewe at bihealth.de (Holtgrewe, Manuel)
Date: Wed, 12 Jul 2017 18:39:03 +0000
Subject: [keycloak-user] Increasing logging for debugging "Internal Server
	Error" response
Message-ID: <CC941ED861F3AA469B6D50EE76C57483D377BB89@s-mx14-bih01.charite.de>

Dear all,

I have some grief with my Keycloak 3.2.0.Final setup.

I have setup my instance and connected it to my organization's AD and this part works well.

I am now trying to connect a client application (that supports OAuth 2) to the Keycloak instance. The application redirects me to the Keycloak login and after successful login, I'm redirected back to the app. So far so good.

The app then tries to do the equivalent of the following.

curl -k --data "refresh_token=SOMEVERYLONGTOKEN&grant_type=refresh_token&client_secret=eeBoTh2hoMifooDaiyig&client_id=igv" https://KEYCLOAK.MYORGA.NET/auth/realms/MYREALM/protocol/openid-connect/token

from this, the app gets a "HTTP 500" response and the curl also displays "<html><head><title>Error</title></head><body>Internal Server Error</body></html>".

I'm running keycloak as a standalone app and so far did not succeed in debugging the problem. How can I increase log levels as to see where things are going bad?

Thanks,
Manuel

From nielsbne at gmail.com  Thu Jul 13 01:17:23 2017
From: nielsbne at gmail.com (Niels Bertram)
Date: Thu, 13 Jul 2017 15:17:23 +1000
Subject: [keycloak-user] Keycloak Adapter validating tokens issued by
	different realms
Message-ID: <CAPLPygkx1t=OMgM2Z7iq6O+MJs1PKjLTOHb=NCxh2mts2PMQ1w@mail.gmail.com>

Hi everyone,

has anyone ever had a requirement to validate access tokens issued by 2 or
more issuers in the Keycloak Java or NodeJS adapters? I found KEYCLOAK-5014
which loosely talks about it but there is no feedback.

We are currently using the client adapter from MitreId (in Spring) which
can be configured via StaticClientConfigurationService.java
<https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-client/src/main/java/org/mitre/openid/connect/client/service/impl/StaticClientConfigurationService.java>
to
validate an inbound token against multiple realms.

Would love to find out if anyone has done this in keycloak or if there are
others out there that have this need.

Kind Regards,
Niels

From Sebastian.Schuster at bosch-si.com  Thu Jul 13 03:41:44 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Thu, 13 Jul 2017 07:41:44 +0000
Subject: [keycloak-user] Authorization services without User Access
 token (Mqtt Broker / IoT)
In-Reply-To: <CAJrcDBcvuRtYaQcT1ruiV-5c0s5ZEnRx6=oGw811PfFdZB_0oA@mail.gmail.com>
References: <CA+eBSFQrRWYFm7xjK5PGE_JVg6UVy+sXTVGUuPSkD8wkMsx=7w@mail.gmail.com>
	<CAJrcDBfqHjvePxb71mL=JE9Wfy3LmTjXYwzr3ehqZo-Xs-qFjA@mail.gmail.com>
	<CA+eBSFSrQ5M-R9smPnKUoZ1cwTDamqt9EL9A-ejb3b4ORYfNPg@mail.gmail.com>
	<CAJrcDBcvuRtYaQcT1ruiV-5c0s5ZEnRx6=oGw811PfFdZB_0oA@mail.gmail.com>
Message-ID: <220032d0170a40aa890d4d39af67b6a7@FE-MBX1028.de.bosch.com>

Hi Pedro,

Since I saw you referring to "https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html#seek-authorization": I think this is not latest version of UMA2. They changed the naming of the spec parts and IMHO https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-04.html and https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-04.html form the current spec. Just in case you did not notice the change of names...

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

 Sebastian Schuster

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

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




-----Original Message-----
From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Mittwoch, 12. Juli 2017 19:19
To: Brahim Ait elhaj <brahima at gmail.com>
Cc: keycloak-user <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Authorization services without User Access token (Mqtt Broker / IoT)

On Wed, Jul 12, 2017 at 1:23 PM, Brahim Ait elhaj <brahima at gmail.com> wrote:

>
>> If a device is actually an user, who are your clients ? The same devices ?
>>
>
> My client is the MQTT Server in this use case (as the 
> *photoz-restful-api* in the *photoz* example).
> I want to protect access to MQTT topics (paths/resources) of this MQTT 
> server.
>
> I was initially asking myself whereas devices should be ? users ? or ? 
> clients ? but we could end with a lot of clients in the latter scenario ...
> also after playing with KC and reading through the mailing list 
> questions/answers, i think that's a better approach to have devices be 
> users and not clients.
>
> However, did you have something in mind when asking this question ?
>

I was wondering if the users you mentioned were actually service accounts associated with clients representing your devices. But yeah, the decision on whether devices should be users or not I think depend on the capabilities you want to support on them.


>
>
>>
>>
>>>
>>> For several reasons/constraints that i won't explain here, i can't 
>>> have my devices connect first to Keycloak to obtain a token (using 
>>> their X.509 certificates as KC supports it) and then connect to the 
>>> MQTT Broker passing this token. They connect directly to the MQTT 
>>> Broker, each device presenting its X.509 certificate to the Broker. 
>>> After connection, the Broker doesn't know client private key.
>>
>>
>> Now I'm curious :)
>>
>
> Ok, the main reason is that the one thing that can be guaranteed about
> devices is that they have a certificate to authenticate themselves. They're
> not necessarily http or even mqtt capable. They can be able to communicate
> only via a low power wide area network (Lora / Sigfox ... ie. not connected
> to internet directly)
>
> So we know how to deal with a user (be it a human or a device) that can
> authenticate and get an access token.
> My concern here is how to deal with a user (device) that can not.
>

Ok, so that changes things a bit ...


>
>> However, I think we could support your use case with UMA 2.0 changes we
>> are planning. In the new version of the specs, the client don't actually
>> need an access token in order to obtain RPTs from AS. There is a specific
>> OAuth2 Grant Type, which you can use just like any other grant type. The
>> tricky here is that instead of using an OAuth2 Access Token to gain access
>> to our APIs, you basically authenticate the client using whatever client
>> authentication method we support. For instance, id/secret, jwt or even
>> using a bearer token (as it stands today). In addition to that, you are
>> allowed to send tokens with claims associated with a requesting party
>> (e.g.: your devices). That would allow you to send your devices
>> certificates.
>>
>> In a nutshell, in a single request to the server you would provide your
>> client credentials + device certificate. And we would need to support
>> extracting requesting party information (the user) from certificates.
>>
>
> Yes, it seems really interesting and corresponding to what i'd like to
> achieve. Since you talk about UMA, i understand this is the ? Authorization
> API ? that is involved here.
>

That is one of the changes introduced by UMA 2.0. The Authorization API was
replaced by a UMA Grant Type [1]. We are going to deprecate the
Authorization API and leave it there for a while. But remove it in future
releases.

My statement above also applies to our Entitlement API, which we also want
to support scenarios where the identity is not really represented by an ID
or access token.

[1]
https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-08.html#seek-authorization


>
> Also, you said ? *In the new version of the specs, the client don't
> actually need an access token in order to obtain RPTs from AS* ?, can you
> please point me to the specs that talk about this specific part (if
> possible) ? I quickly went through the v2.0 without being able to clearly
> identity this specific part ...
>

See link above.


>
> Do you have something (beta ...) that i can start playing with ? Is it
> already in the roadmap (maybe you have a specific ticket number in mind) ?
>

Nothing yet ... But this is my next task in Keycloak. At the moment I'm
stuck with tasks in other projects that I need to get it done. But the JIRA
is https://issues.jboss.org/browse/KEYCLOAK-3169.


>
> Depending on the estimated ? landing ? date, i can contribute in many
> ways. So, What's the next step :-)
>

Sure thing. Maybe you can start providing some more background to what you
need in that JIRA. Although the title is related with UMA 2.0 it will also
involve changes to Entitlement API.

The initial plan did not include what we are discussing here. But I think
we can consider your requirements during development once we agree on what
we really need to do.

Maybe another approach to your problem is make your MQTT Broker both a PDP
and PEP. I mean, you would use some REST API in Keycloak to evaluate
policies based on a set of one or more resources/topics + enforce access
based on the permissions returned by the server. We do have an endpoint
that you can use to evaluate policies (see
https://github.com/keycloak/keycloak/blob/master/integration/admin-client/src/main/java/org/keycloak/admin/client/resource/PoliciesResource.java#L70).
But it is basically accessing the API used by our Policy Evaluation Toll in
the admin console. Ideally, you should use Entitlement API, Authorization
API/UMA Grant Type.


>
>>
>>
>>>
>>> Best regards,
>>> Brahim
>>>
>>
>
>
>
>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user


From nicolaouantonia at gmail.com  Thu Jul 13 03:47:13 2017
From: nicolaouantonia at gmail.com (Antonia Nicolaou)
Date: Thu, 13 Jul 2017 10:47:13 +0300
Subject: [keycloak-user] ${url.resourcesPath} not working in
	email-verification.ftl template
Message-ID: <CADQwdOrN0hsPbUQwC_CU=DLVB+6QbAprMNXXGiBAMUe+bNNvEA@mail.gmail.com>

Hello,




I am using single sign on service from redhat v7.1 and I am developing a
custom template (in a custom theme) for verification email.

In the email, I am using ${url.resourcesPath}

for <img src="${url.resourcesPath}/img/image.jpg">

and is not working.

The template is not used when I use it.

Could you help me?



Thank you in advanced.

Sincerely,

Antonia Nicolaou

From federico at info.nl  Thu Jul 13 03:53:52 2017
From: federico at info.nl (Federico Navarro Polo - Info.nl)
Date: Thu, 13 Jul 2017 07:53:52 +0000
Subject: [keycloak-user] error=pkce_verification_failed
In-Reply-To: <67434e71-ba6a-18a1-cca2-fd6c93dc1882@redhat.com>
References: <285AAEA2-C62A-4235-BC7D-4AB99F93A412@info.nl>
	<67434e71-ba6a-18a1-cca2-fd6c93dc1882@redhat.com>
Message-ID: <61C6D20E-C2F7-4A8E-A281-6263DEABB2A8@info.nl>

Unfortunately, I got the same with 3.1.0.Final and 3.2.0.Final.

When you say disabling PKCE for the adapter, you mean the client connecting to Keycloak, right? In our case, that would be configuration in AppAuth.

Regards,
Federico

On 11/07/17 22:56, "Marek Posolda" <mposolda at redhat.com> wrote:

    Still I would try to upgrade to 3.2.0.Final if possible. AFAIK there was 
    some related fixes in there, so worth to try if it's not a lot of work 
    for you. Otherwise workaround is to disable PKCE for your adapter, which 
    will also remove all related parameters from the initial request to 
    Keycloak.
    
    Marek
    
    On 11/07/17 16:38, Federico Navarro Polo - Info.nl wrote:
    > Hello,
    >
    > After upgrading our Keycloak version to 3.1.0, we?ve started seeing the following error in one of our use cases (using AppAuth).
    >
    > 2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE supporting Client, codeVerifier = KX3heFUICMscL03Xv_STmf5hgRSsvm5VxnN0DIQob5wRAIGFyVqCn6hQ6w9exPyUtFaMcue1Uole-bTdHP6KaA
    > 2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE codeChallengeMethod = S256
    > 2017-07-11 16:21:12,135 WARN  [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE verification failed. authUserId = a71bd8ee-fe4b-4259-81c5-5e8e09940f47, authUsername = someone at somewhere.nl
    > 2017-07-11 16:21:12,136 WARN  [org.keycloak.events] (default task-24) type=CODE_TO_TOKEN_ERROR, realmId=x, clientId=x, userId=a71bd8ee-fe4b-4259-81c5-5e8e09940f47, ipAddress=x.x.x.x, error=pkce_verification_failed, grant_type=authorization_code, code_id=1cf7b8f2-5462-4cf4-a228-ba0cc4501e82, client_auth_method=client-secret
    >
    >
    > I saw this bug report, which could be related to the issue (still open for 3.2.0 as well): https://issues.jboss.org/browse/KEYCLOAK-4956
    >
    > Is it possible to disable PKCE from Keycloak configuration?
    >
    >
    > Met vriendelijke groet,
    >
    > Federico Navarro
    >
    > backend developer
    >
    > federico at info.nl<mailto:federico at info.nl>  |  LinkedIn<https://www.linkedin.com/company/info-nl>  |  +31 (0)2 05 30 91 61<tel:+31205309161>
    >
    > info.nl<http://www.info.nl/>
    >
    > Sint Antoniesbreestraat 16  |  1011 HB Amsterdam  |  +31 (0)20 530 9100<tel:+31205309100>
    >
    >
    > _______________________________________________
    > keycloak-user mailing list
    > keycloak-user at lists.jboss.org
    > https://lists.jboss.org/mailman/listinfo/keycloak-user
    
    
    



From federico at info.nl  Thu Jul 13 03:54:46 2017
From: federico at info.nl (Federico Navarro Polo - Info.nl)
Date: Thu, 13 Jul 2017 07:54:46 +0000
Subject: [keycloak-user] Internal System Error on screens when a code is
 expired
In-Reply-To: <CAJgngAf2TN6wDk9yyuTyvCYzd=GoNDU3Bd0YPiGq61jTbdXMZw@mail.gmail.com>
References: <63F53E4C-3933-4C90-A137-DB30CD000EA5@info.nl>
	<CAJgngAf2TN6wDk9yyuTyvCYzd=GoNDU3Bd0YPiGq61jTbdXMZw@mail.gmail.com>
Message-ID: <D86AEDF3-6B4B-4E77-AF18-C9B3614DB93B@info.nl>

Thanks. I will take a look to the new version.

Regards,
Federico

From: Stian Thorgersen <sthorger at redhat.com>
Reply-To: "stian at redhat.com" <stian at redhat.com>
Date: Wednesday 5 July 2017 at 20:35
To: "Federico Navarro Polo - Info.nl" <federico at info.nl>
Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Internal System Error on screens when a code is expired

Try 3.2 there's been improvements around this

On 5 July 2017 at 13:33, Federico Navarro Polo - Info.nl <federico at info.nl<mailto:federico at info.nl>> wrote:
Hello,

There are some screens / links generated by Keycloak that make use of an authorization code, like registration link, forgotten password link, verification link, etc. When those codes expire or a code is already used, the feedback to the user will be just an Internal Server Error screen.

This is not very user friendly, since the user doesn?t know what he has done wrong (eg: a simple refresh on the register page will trigger the issue). I wonder if there is a simple way to modify this behavior, and for instance show a different error message informing of the actual problem (eg: the code is invalid. Please go to {link} to restart the process), or this is really a new functionality to be requested to the Keycloak team via JIRA.



Regards,
Federico
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user


From federico at info.nl  Thu Jul 13 03:57:03 2017
From: federico at info.nl (Federico Navarro Polo - Info.nl)
Date: Thu, 13 Jul 2017 07:57:03 +0000
Subject: [keycloak-user] Recommended way to import user accounts with
 external identity provider information?
In-Reply-To: <e870c980-1513-2009-6f1d-8509890042e6@redhat.com>
References: <72DC34C5-A442-441F-9BCC-57A9405A70C5@info.nl>
	<e870c980-1513-2009-6f1d-8509890042e6@redhat.com>
Message-ID: <6C23B81F-FEAA-41FB-8D5E-033D41FF654C@info.nl>

Yes, it does indeed work, and the content of the exports was correct as well. The problem I was having was because I was using different Facebook apps to do the test. When keeping the Facebook app the same, there is no problem, which makes sense.

Regards,
Federico

On 23/06/17 08:15, "Marek Posolda" <mposolda at redhat.com> wrote:

    I think it should work - unless we have a bug :) The question is if 
    "userId" and "userName" are really filled correctly in your JSON?
    
    I suggest that you try to setup some Keycloak environment from scratch 
    and do facebook login there. Then you can doublecheck the content from 
    DB and how the federated link in Keycloak DB looks like. You can also 
    export Keycloak DB and re-import to clean DB and then doublecheck if 
    Facebook login still works after export/import.
    
    If this works, you can compare the exported JSON with your own JSON file 
    and doublecheck if "userId" and "userName" matches.
    
    Marek
    
    On 22/06/17 15:20, Federico Navarro Polo - Info.nl wrote:
    > Hello,
    >
    > I?m facing currently a migration scenario where I have a group of users which need to be imported from a different system into Keycloak. For regular users everything works fine, but I wonder what would be the best approach for users which authenticate via external identity providers (eg: facebook) in order to make the transition as transparent as possible for the users (ideally, no interaction at all).
    >
    >  From the source system, I have access to the facebook user id and email address, so first I tried to include that as federated identity in the users import:
    >
    > {
    >      "realm": "test",
    >      "users": [
    >          {
    >              "createdTimestamp" : 1476191007295,
    >              "username" : "somebody at somewhere.com",
    >              "enabled" : true,
    >              "totp" : false,
    >              "emailVerified" : true,
    >              "firstName" : "Test",
    >              "lastName" : "Test",
    >              "email" : "somebody at somewhere.com",
    >              "credentials" : [ ],
    >              "disableableCredentialTypes" : [ ],
    >              "requiredActions" : [ ],
    >              "federatedIdentities" : [ {
    >                "identityProvider" : "facebook",
    >                "userId" : "0123456789",
    >                "userName" : "somebody at somewhere.com",
    >              } ],
    >              "realmRoles" : [ "offline_access", "uma_authorization" ],
    >              "clientRoles" : {
    >                "account" : [ "manage-account", "view-profile" ]
    >              }
    >            }
    >        ]
    > }
    >
    > , which imports fine, and I can see the link in the admin console, but when attempting to login using Facebook, Keycloak ignores that data and redirects to the ?Account linking? screen (and in that case, if I follow the process, then I get a DB exception due to duplicate key). So it seems the best way is to not import the Facebook details, and when the user tries to login with Facebook, then the standard account linking process will be triggered, which is not ideal in a migration.
    >
    > I suppose there is some extra logic which is not taking place when doing the import as opposed to creating a new account from scratch or creating the identity provider link manually in the admin console, but can?t figure out what is it. Is there any possible way to avoid the account linking step?
    >
    > Met vriendelijke groet,
    >
    > Federico Navarro
    >
    > backend developer
    >
    > federico at info.nl<mailto:federico at info.nl>  |  LinkedIn<https://www.linkedin.com/company/info-nl>  |  +31 (0)2 05 30 91 61<tel:+31205309161>
    >
    > info.nl<http://www.info.nl/>
    >
    > Sint Antoniesbreestraat 16  |  1011 HB Amsterdam  |  +31 (0)20 530 9100<tel:+31205309100>
    >
    >
    > _______________________________________________
    > keycloak-user mailing list
    > keycloak-user at lists.jboss.org
    > https://lists.jboss.org/mailman/listinfo/keycloak-user
    
    
    



From K.Buler at adbglobal.com  Thu Jul 13 04:40:42 2017
From: K.Buler at adbglobal.com (Karol Buler)
Date: Thu, 13 Jul 2017 10:40:42 +0200
Subject: [keycloak-user] Increasing logging for debugging "Internal
 Server Error" response
In-Reply-To: <CC941ED861F3AA469B6D50EE76C57483D377BB89@s-mx14-bih01.charite.de>
References: <CC941ED861F3AA469B6D50EE76C57483D377BB89@s-mx14-bih01.charite.de>
Message-ID: <1930a3f7-121e-dfc8-d108-5d72d685bced@adbglobal.com>

Keycloak is running on Wildfly, so go to /standalone/configuration
folder and edit "standalone.xml" file. Section
"urn:jboss:domain:logging:3.0" and change CONSOLE logging from INFO to
e.g. DEBUG.


On 12.07.2017 20:39, Holtgrewe, Manuel wrote:
> Dear all,
>
> I have some grief with my Keycloak 3.2.0.Final setup.
>
> I have setup my instance and connected it to my organization's AD and this part works well.
>
> I am now trying to connect a client application (that supports OAuth 2) to the Keycloak instance. The application redirects me to the Keycloak login and after successful login, I'm redirected back to the app. So far so good.
>
> The app then tries to do the equivalent of the following.
>
> curl -k --data "refresh_token=SOMEVERYLONGTOKEN&grant_type=refresh_token&client_secret=eeBoTh2hoMifooDaiyig&client_id=igv" https://KEYCLOAK.MYORGA.NET/auth/realms/MYREALM/protocol/openid-connect/token
>
> from this, the app gets a "HTTP 500" response and the curl also displays "<html><head><title>Error</title></head><body>Internal Server Error</body></html>".
>
> I'm running keycloak as a standalone app and so far did not succeed in debugging the problem. How can I increase log levels as to see where things are going bad?
>
> Thanks,
> Manuel
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

[https://www.adbglobal.com/wp-content/uploads/adb.png]
connecting lives
connecting worlds


From anunay.sinha at arvindinternet.com  Thu Jul 13 05:52:53 2017
From: anunay.sinha at arvindinternet.com (Anunay Sinha)
Date: Thu, 13 Jul 2017 09:52:53 +0000
Subject: [keycloak-user] Password reset link expires after clicking it once
Message-ID: <CANCBORTbghniWfa6iWjGEtSHxkFQmFkugQ=hC327bRgjk5veDg@mail.gmail.com>

Hi
We are sending the reset password link.
Once you click on the link and for some reason do not complete the action
of reseting the password, and then try again with same link it gives the
following error

We're *sorry* ...
An error occurred, please login again through your application.


There is already an issue raised and its states to be fixed in 1.9.0

I am using 2.4.0 and am still facing this issue

Is this a configuration that I need to take care of?

From hmlnarik at redhat.com  Thu Jul 13 05:58:43 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 13 Jul 2017 11:58:43 +0200
Subject: [keycloak-user] Password reset link expires after clicking it
	once
In-Reply-To: <CANCBORTbghniWfa6iWjGEtSHxkFQmFkugQ=hC327bRgjk5veDg@mail.gmail.com>
References: <CANCBORTbghniWfa6iWjGEtSHxkFQmFkugQ=hC327bRgjk5veDg@mail.gmail.com>
Message-ID: <CAMvXD=FAsgK905ziUv4pPAOVny_Z9v6mwG9Gnf+mZ8nHm8rauw@mail.gmail.com>

This has been changed in 3.2. Please upgrade and try with the latest version.

--Hynek

On Thu, Jul 13, 2017 at 11:52 AM, Anunay Sinha
<anunay.sinha at arvindinternet.com> wrote:
> Hi
> We are sending the reset password link.
> Once you click on the link and for some reason do not complete the action
> of reseting the password, and then try again with same link it gives the
> following error
>
> We're *sorry* ...
> An error occurred, please login again through your application.
>
>
> There is already an issue raised and its states to be fixed in 1.9.0
>
> I am using 2.4.0 and am still facing this issue
>
> Is this a configuration that I need to take care of?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From petervn1 at yahoo.com  Thu Jul 13 08:29:56 2017
From: petervn1 at yahoo.com (Peter Nalyvayko)
Date: Thu, 13 Jul 2017 12:29:56 +0000 (UTC)
Subject: [keycloak-user] Identity provider,
 keycloak js adapter and session management
References: <559623611.4196979.1499948996529.ref@mail.yahoo.com>
Message-ID: <559623611.4196979.1499948996529@mail.yahoo.com>

Thanks, Marek.


--------------------------------------------
On Wed, 7/12/17, Marek Posolda <mposolda at redhat.com> wrote:

 Subject: Re: [keycloak-user] Identity provider, keycloak js adapter and session management
 To: "Peter Nalyvayko" <petervn1 at yahoo.com>, keycloak-user at lists.jboss.org
 Date: Wednesday, July 12, 2017, 7:17 AM
 
 
     There was some
 related fix in latest
       master https://issues.jboss.org/browse/KEYCLOAK-5139
 . However
       your issue with iframe looks like something different.
 Feel free
       to create JIRA if it won't help. 
 
       
 
       Ideally you can also send PR. We have tests for
 pairwise in OIDCPairwiseClientRegistrationTest.java
       and there are some IFrame related tests in LoginStatusIframeEndpointTest
         .
 
         
 
         Marek
       
 
       
 
       On 07/07/17 18:06, Peter Nalyvayko wrote:
 
     
     
       Some additional info: we can also reproduce the
 same behavior using the Pairwise subject identifier, i.e.
 users keep getting logged out after 5 seconds. 
 
 --------------------------------------------
 On Thu, 7/6/17, Peter Nalyvayko <petervn1 at yahoo.com>
 wrote:
 
  Subject: Identity provider, keycloak js adapter and session
 management
  To: keycloak-user at lists.jboss.org
  Date: Thursday, July 6, 2017, 12:10 PM
  
  Hi,
  
  We've hit a bit of a snag while setting
  up our one page js client. Changing the value of the
 "sub"
  claim to anything other than the unique identifier of the
  keycloak user causes the keycloak adapter to detect the
  changes to the session and clear out the tokens, forcing
 the
  users to re-log in after every 5 seconds. 
   
  We are using the version 2.3.0 of
  keycloak. Our app is set up to use keycloak.js adapter for
  all things related to OIDC. The adapter is configured to
 use
  the "code authorization" (standard) flow. The
 instance of
  keycloak is configured to use an external OIDC identity
  provider and the users are uniquely identified by their
  e-mails. Naturally, we wanted that the "sub"
 claim in the
  claim set returned by calling the keycloak's OIDC
 /token
  endpoint would return the unique identity of the external
  user rather than the internal identifier of the keycloak
  user, so we re-configured the keycloak client by adding a
  property mapper to map the user's email to the
 "sub" claim,
  here the example of the access token: 
  {
  ?  "sub": "user at company.com",
  ?  "iat": 223235098325,
  ?  "email": "user at company.com",
  ?  ...
  } 
  
  Once we had implemented these changes
  on the keycloak side, our users were able to initially sign
  into the application, but when they tried to access any
  functionality within the app, they would be prompted to
 sign
  in again. The problem seems to related to the OIDC session
  management and the assumption and the "sub" claim
 always
  matches the keycloak user's unique identifier. 
  
  We narrowed the problem down to four
  components:
  
  - keycloak.js
  - login-status-iframe.html
  -
  services\srv\main\java\org\keycloak\protocol\oidc\endpoints\LoginStatusIframeEndpoint.java
  -
  services\src\main\java\org\keycloak\services\managers\AuthenticationManager.java
   
  In keycloak.js, line 637, the
  implementation creates a session id to be used to check the
  session state. Notice that the code uses the value from the
  "sub" claim: 
  ?  var sessionId = kc.realm + "/"
  + kc.tokenParsed.sub;
  ? 
  In
  AuthenticationManager.createLoginCookie, line 306, the
 value
  of the "SESSION_COOKIE" is set to:
  
  ? String sessionCookieValue =
  realm.getName() + "/" + user.getId();
  
  Sadly, in our configuration, the value
  returned of by user.getId() is not the same as the value
  stored in the "sub" claim, thus causing the
 session
  management code in login-status-iframe.html, line 53 to
  clear out any tokens and force the users to re-login the
  next time it checks the session state (default is 5 second
  intervals):
  
  ? var cookie = getCookie();
  ? if (sessionState == cookie) {
  ... } else { callback("changed"); }? 
  
   
  Looking at the
  LoginStatusIframeEndpoint.preCheck
  (LoginSatusIframeEndpoint.java, lines 71-93), we've
 noticed
  that the implementation does not even make use of the user
  identity, only the session id.
  
  The workaround, at least temporary, for
  us was to add the "id" claim containing the user
 identity
  internal to keycloak, and modify the keycloak JS adapter
  code to look for the "id" claim and use its value
 instead of
  the value in the "sub" claim when creating the
 session id,
  i.e.:
  
  ? 
  ?  var sessionId;
  ?  if (kc.tokenParsed.id) {
  ? ? ? sessionId =
  kc.realm + "/" + kc.tokenParsed.id;
  ?  } else {
  ? ? ? sessionId =
  kc.realm + "/" + kc.tokenParsed.sub;
  ?  }
  
  Is this a bug, or does it work as
  intended, i.e. the users should never set the
 "sub" claim to
  anything other than the keycloak's user identity? If
 this is
  a bug, I can submit a JIRA request and a fix as long as the
  workaround above seems like an acceptable solution
  
  Any comments are welcome
  Regards,
  Peter
  
 
 _______________________________________________
 keycloak-user mailing list
 keycloak-user at lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/keycloak-user
     
     
 
     
   


From kirmerzlikin at gmail.com  Thu Jul 13 10:03:37 2017
From: kirmerzlikin at gmail.com (Kir Merzlikin)
Date: Thu, 13 Jul 2017 07:03:37 -0700 (MST)
Subject: [keycloak-user] Idle connections are not closed
Message-ID: <1499954617778-3948.post@n6.nabble.com>

Hi all,

I deploy Keycloak server app to Cloud Foundry and use ClearDB service as
relational database for Keycloak.

ClearDB has a restriction, that it closes all connections, that are idle for
90 seconds.
To not run into the situation, when Keycloak tries to use closed connection,
I've added following datasource configuration (based on  Pivotal
recommendations
<https://discuss.pivotal.io/hc/en-us/articles/230433268-Suggested-Configuration-for-Connection-Pools-using-ClearDb> 
):



But even after applying this configuration I see in the ClearDB management
console that idle connections are closed only after 90 seconds and not after
60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
parameter.

So, have anybody of you faced similar situation? Or maybe you have some
ideas why these idle connections are not being closed.

Thanks.





--
View this message in context: http://keycloak-user.88327.x6.nabble.com/Idle-connections-are-not-closed-tp3948.html
Sent from the keycloak-user mailing list archive at Nabble.com.

From thomas at recloux.fr  Thu Jul 13 10:44:32 2017
From: thomas at recloux.fr (Thomas Recloux)
Date: Thu, 13 Jul 2017 16:44:32 +0200
Subject: [keycloak-user] Customize admin console to support custom attributes
Message-ID: <1499957072.1860837.1039806232.4FD36FF0@webmail.messagingengine.com>

Hi All,

Is there a way to extend the admin console in order to support more
attributes than email, first name and last name ?

We'd like to offer a guided UI, compared to the "attributes" tab.

Thank you, Thomas


From kirmerzlikin at gmail.com  Thu Jul 13 11:02:10 2017
From: kirmerzlikin at gmail.com (=?UTF-8?B?0JrQuNGAINCc0LXRgNC30LvQuNC60LjQvQ==?=)
Date: Thu, 13 Jul 2017 18:02:10 +0300
Subject: [keycloak-user] Idle connections are not closed
Message-ID: <CAFMb=TNsVgSajWh1o_EkEmuNZ1358mtKuvbGvsh0_eZHWT-YmA@mail.gmail.com>

Hi all,

I deploy Keycloak server app to Cloud Foundry and use ClearDB service as
relational database for Keycloak.

ClearDB has a restriction, that it closes all connections, that are idle
for 90 seconds.
To not run into the situation, when Keycloak tries to use closed
connection, I've added following datasource configuration (based on Pivotal
recommendations
<https://discuss.pivotal.io/hc/en-us/articles/230433268-Suggested-Configuration-for-Connection-Pools-using-ClearDb>
):

- - - - - - - - -
<datasource jndi-name="java:jboss/datasources/KeycloakDS"
pool-name="KeycloakDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:mysql://
blah.cleardb.net/blah?user=blah&password=blah</connection-url>
        <driver>mysql</driver>
    <pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>10</max-pool-size>
    </pool>
    <timeout>
        <idle-timeout-minutes>1</idle-timeout-minutes>
    </timeout>
    <validation>
        <validate-on-match>true</validate-on-match>
        <valid-connection-checker
class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
        <exception-sorter
class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
    </validation>
</datasource>
- - - - - - - - -

But even after applying this configuration I see in the ClearDB management
console that idle connections are closed only after 90 seconds and not
after 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
parameter.

So, have anybody of you faced similar situation? Or maybe you have some
ideas why these idle connections are not being closed.

Thanks.
Kir

From Nicolas.Geadah at vec.virginia.gov  Thu Jul 13 11:42:15 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Thu, 13 Jul 2017 15:42:15 +0000
Subject: [keycloak-user] User Name Complexity
Message-ID: <AA9A1979BCCB3F4998617B9D33FA39002306C36E@COVMSGCES-MBX13>

There seems to be no "out-of-the-box" support for username complexity requirements; as such, users can register with usernames as short as 1 character, which is problematic and potentially unsafe in a production environment.

What is the best way to enforce a set of username complexity requirements, such as minimum/maximum length - presence of numeric/special characters - etc.

Thank you

From bburke at redhat.com  Thu Jul 13 14:11:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Jul 2017 14:11:49 -0400
Subject: [keycloak-user] User Name Complexity
In-Reply-To: <AA9A1979BCCB3F4998617B9D33FA39002306C36E@COVMSGCES-MBX13>
References: <AA9A1979BCCB3F4998617B9D33FA39002306C36E@COVMSGCES-MBX13>
Message-ID: <688ee9c0-f5af-cb03-43ae-732a7ac05656@redhat.com>

We don't have a way of doing this out of the box.  If you're talking 
about browser-based registration through our registration screens, 
you'll have to extend this flow to validate usernames to the 
restrictions you want to enforce.


On 7/13/17 11:42 AM, Geadah, Nicolas (VEC) wrote:
> There seems to be no "out-of-the-box" support for username complexity requirements; as such, users can register with usernames as short as 1 character, which is problematic and potentially unsafe in a production environment.
>
> What is the best way to enforce a set of username complexity requirements, such as minimum/maximum length - presence of numeric/special characters - etc.
>
> Thank you
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From bburke at redhat.com  Thu Jul 13 14:13:19 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Jul 2017 14:13:19 -0400
Subject: [keycloak-user] Customize admin console to support custom
 attributes
In-Reply-To: <1499957072.1860837.1039806232.4FD36FF0@webmail.messagingengine.com>
References: <1499957072.1860837.1039806232.4FD36FF0@webmail.messagingengine.com>
Message-ID: <70ff0924-6893-4721-e77a-f0ef55dc9f80@redhat.com>

Its possible, but we don't have a nice way of extending the admin 
console other than just modifying things yourself with a custom theme.


On 7/13/17 10:44 AM, Thomas Recloux wrote:
> Hi All,
>
> Is there a way to extend the admin console in order to support more
> attributes than email, first name and last name ?
>
> We'd like to offer a guided UI, compared to the "attributes" tab.
>
> Thank you, Thomas
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From bburke at redhat.com  Thu Jul 13 14:14:46 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Jul 2017 14:14:46 -0400
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <1499954617778-3948.post@n6.nabble.com>
References: <1499954617778-3948.post@n6.nabble.com>
Message-ID: <7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>

You'll have to dive into Wildfly/JBoss EAP datasource configuration 
documentation.  I know there are a multitude of connection pool switches 
you can specify.


On 7/13/17 10:03 AM, Kir Merzlikin wrote:
> Hi all,
>
> I deploy Keycloak server app to Cloud Foundry and use ClearDB service as
> relational database for Keycloak.
>
> ClearDB has a restriction, that it closes all connections, that are idle for
> 90 seconds.
> To not run into the situation, when Keycloak tries to use closed connection,
> I've added following datasource configuration (based on  Pivotal
> recommendations
> <https://discuss.pivotal.io/hc/en-us/articles/230433268-Suggested-Configuration-for-Connection-Pools-using-ClearDb>
> ):
>
>
>
> But even after applying this configuration I see in the ClearDB management
> console that idle connections are closed only after 90 seconds and not after
> 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
> parameter.
>
> So, have anybody of you faced similar situation? Or maybe you have some
> ideas why these idle connections are not being closed.
>
> Thanks.
>
>
>
>
>
> --
> View this message in context: http://keycloak-user.88327.x6.nabble.com/Idle-connections-are-not-closed-tp3948.html
> Sent from the keycloak-user mailing list archive at Nabble.com.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From john.d.ament at gmail.com  Thu Jul 13 14:37:15 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 13 Jul 2017 18:37:15 +0000
Subject: [keycloak-user] Keycloak Cookies
Message-ID: <CAOqetn8cWs=Vau_8g8z5bnRhYDL5HckGLWLFDQdR4a_sR4K8Yw@mail.gmail.com>

Hi,

I have a use case where I need to login to my app via keycloak, but using
my app's login screen.  We've been using the OIDC endpoint in keycloak via
a POST to authenticate the user and get an accesstoken/refreshtoken back.
However, we're seeing that its then very hard to actually get into a
keycloak screen (which we use to do account management).  So I was
wondering, is there something in the JS adapter that should fix this?  We
don't see any of the keycloak cookies being set.

John

From mposolda at redhat.com  Thu Jul 13 15:49:43 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Jul 2017 21:49:43 +0200
Subject: [keycloak-user] error=pkce_verification_failed
In-Reply-To: <61C6D20E-C2F7-4A8E-A281-6263DEABB2A8@info.nl>
References: <285AAEA2-C62A-4235-BC7D-4AB99F93A412@info.nl>
	<67434e71-ba6a-18a1-cca2-fd6c93dc1882@redhat.com>
	<61C6D20E-C2F7-4A8E-A281-6263DEABB2A8@info.nl>
Message-ID: <7695a412-aab1-1a39-a18d-14ea7c3b9c38@redhat.com>

On 13/07/17 09:53, Federico Navarro Polo - Info.nl wrote:
> Unfortunately, I got the same with 3.1.0.Final and 3.2.0.Final.
>
> When you say disabling PKCE for the adapter, you mean the client connecting to Keycloak, right? In our case, that would be configuration in AppAuth.
Yes. Especially to ensure that parameters like "code_challenge" not 
present in initial request to Keycloak.

Marek
>
> Regards,
> Federico
>
> On 11/07/17 22:56, "Marek Posolda" <mposolda at redhat.com> wrote:
>
>      Still I would try to upgrade to 3.2.0.Final if possible. AFAIK there was
>      some related fixes in there, so worth to try if it's not a lot of work
>      for you. Otherwise workaround is to disable PKCE for your adapter, which
>      will also remove all related parameters from the initial request to
>      Keycloak.
>      
>      Marek
>      
>      On 11/07/17 16:38, Federico Navarro Polo - Info.nl wrote:
>      > Hello,
>      >
>      > After upgrading our Keycloak version to 3.1.0, we?ve started seeing the following error in one of our use cases (using AppAuth).
>      >
>      > 2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE supporting Client, codeVerifier = KX3heFUICMscL03Xv_STmf5hgRSsvm5VxnN0DIQob5wRAIGFyVqCn6hQ6w9exPyUtFaMcue1Uole-bTdHP6KaA
>      > 2017-07-11 16:21:12,134 DEBUG [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE codeChallengeMethod = S256
>      > 2017-07-11 16:21:12,135 WARN  [org.keycloak.protocol.oidc.endpoints.TokenEndpoint] (default task-24) PKCE verification failed. authUserId = a71bd8ee-fe4b-4259-81c5-5e8e09940f47, authUsername = someone at somewhere.nl
>      > 2017-07-11 16:21:12,136 WARN  [org.keycloak.events] (default task-24) type=CODE_TO_TOKEN_ERROR, realmId=x, clientId=x, userId=a71bd8ee-fe4b-4259-81c5-5e8e09940f47, ipAddress=x.x.x.x, error=pkce_verification_failed, grant_type=authorization_code, code_id=1cf7b8f2-5462-4cf4-a228-ba0cc4501e82, client_auth_method=client-secret
>      >
>      >
>      > I saw this bug report, which could be related to the issue (still open for 3.2.0 as well): https://issues.jboss.org/browse/KEYCLOAK-4956
>      >
>      > Is it possible to disable PKCE from Keycloak configuration?
>      >
>      >
>      > Met vriendelijke groet,
>      >
>      > Federico Navarro
>      >
>      > backend developer
>      >
>      > federico at info.nl<mailto:federico at info.nl>  |  LinkedIn<https://www.linkedin.com/company/info-nl>  |  +31 (0)2 05 30 91 61<tel:+31205309161>
>      >
>      > info.nl<http://www.info.nl/>
>      >
>      > Sint Antoniesbreestraat 16  |  1011 HB Amsterdam  |  +31 (0)20 530 9100<tel:+31205309100>
>      >
>      >
>      > _______________________________________________
>      > keycloak-user mailing list
>      > keycloak-user at lists.jboss.org
>      > https://lists.jboss.org/mailman/listinfo/keycloak-user
>      
>      
>      
>


From kirmerzlikin at gmail.com  Thu Jul 13 17:25:07 2017
From: kirmerzlikin at gmail.com (=?UTF-8?B?0JrQuNGAINCc0LXRgNC30LvQuNC60LjQvQ==?=)
Date: Fri, 14 Jul 2017 00:25:07 +0300
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
Message-ID: <CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>

Hi Bill,

Yes, I have read a lot of documentation articles and manuals regarding
datasource configuration today.
Basing on this material, I've created following config, which should work
as I want:

- - - - - - - - -
<datasource jndi-name="java:jboss/datasources/KeycloakDS"
pool-name="KeycloakDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
blah&password=blah</connection-url>
        <driver>mysql</driver>
    <pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>10</max-pool-size>
    </pool>
    <timeout>
        <idle-timeout-minutes>1</idle-timeout-minutes>
    </timeout>
    <validation>
        <validate-on-match>true</validate-on-match>
        <valid-connection-checker class-name="org.jboss.jca.
adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
        <exception-sorter  class-name="org.jboss.jca.
adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
    </validation>
</datasource>
- - - - - - - - -

But the fact is that idle connections are still able to live to 90 seconds
limit, instead of 1 minute.

My suggestions was that connection was not closed by some Keycloak code and
then returned to the connection pool, where it wasn't considered idle and
was not "closed" (terminated).

Could you please share your thoughts on this?

Thanks.


On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com> wrote:

> You'll have to dive into Wildfly/JBoss EAP datasource configuration
> documentation.  I know there are a multitude of connection pool switches
> you can specify.
>
>
> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
> > Hi all,
> >
> > I deploy Keycloak server app to Cloud Foundry and use ClearDB service as
> > relational database for Keycloak.
> >
> > ClearDB has a restriction, that it closes all connections, that are idle
> for
> > 90 seconds.
> > To not run into the situation, when Keycloak tries to use closed
> connection,
> > I've added following datasource configuration (based on  Pivotal
> > recommendations
> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
> > ):
> >
> >
> >
> > But even after applying this configuration I see in the ClearDB
> management
> > console that idle connections are closed only after 90 seconds and not
> after
> > 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
> > parameter.
> >
> > So, have anybody of you faced similar situation? Or maybe you have some
> > ideas why these idle connections are not being closed.
> >
> > Thanks.
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://keycloak-user.88327.x6.
> nabble.com/Idle-connections-are-not-closed-tp3948.html
> > Sent from the keycloak-user mailing list archive at Nabble.com.
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>



-- 
? ?????????,
????????? ??????

From mevans at aconex.com  Thu Jul 13 19:11:08 2017
From: mevans at aconex.com (Matt Evans)
Date: Thu, 13 Jul 2017 23:11:08 +0000
Subject: [keycloak-user] Upgrading from 2.5.4 to 3.2.0
Message-ID: <ME1PR01MB0769EDC404DFA75E8CD2F015A9AC0@ME1PR01MB0769.ausprd01.prod.outlook.com>

Hi

We're looking to upgrade keycloak from 2.5.4 to 3.2.0, but I noticed in the liquibase changesets that one of the changes in 3.2.0 jpa changelog the column OFFLINE_CLIENT_SESSION has been deleted in the OFFLINE_CLIENT_SESSION table.

My question is how will 2.5.4 handle that column missing if we update the schema first? I've tested this scenario in our environment and it seems to work, but we don't request offline tokens. Will that be enough to ensure that we won't get failures because of the missing column?

Thanks

Matt

From john.d.ament at gmail.com  Thu Jul 13 22:27:19 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Fri, 14 Jul 2017 02:27:19 +0000
Subject: [keycloak-user] Automatically logging in after performing an Update
	Password
Message-ID: <CAOqetn_FtkKncPg2VqtyE0xUG6deSxfQV6BtmttNyxGneMot4A@mail.gmail.com>

Hi,

Based on the Required Actions guide (
https://keycloak.gitbooks.io/documentation/server_admin/topics/users/required-actions.html)
we've implemented a custom required action that acts a lot like Update
Password (it performs a few other sync items for us).  One of our needs is
to automatically log the user in to their destination application upon
setting this password.  This was working for us in 3.1 by creating a custom
template that was rendered upon the completion of the Update Password
action that forwarded the user to our application and set the necessary
cookies.

This no longer works in 3.2.  We believe it has to do with the ability to
reuse required action links.  Before, the link was one time use so it was
only working once, however our need is to make those links work unlimited
times until consumed.  By setting a new challenge to the user after
updating their password, the token is no longer being marked as consumed
and the link remains working.

So I was wondering, what other ways could we achieve this behavior?  It
sounds like a challenge isn't the right approach.

John

From hmlnarik at redhat.com  Fri Jul 14 00:20:09 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 14 Jul 2017 06:20:09 +0200
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
	<CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
Message-ID: <CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>

Can you inspect commands running in expectedly idle connections in
MySQL via SHOW FULL PROCESSLIST? Have you changed any other
datasource- and transaction-related configuration?

Thanks

On Thu, Jul 13, 2017 at 11:25 PM, ??? ????????? <kirmerzlikin at gmail.com> wrote:
> Hi Bill,
>
> Yes, I have read a lot of documentation articles and manuals regarding
> datasource configuration today.
> Basing on this material, I've created following config, which should work
> as I want:
>
> - - - - - - - - -
> <datasource jndi-name="java:jboss/datasources/KeycloakDS"
> pool-name="KeycloakDS" enabled="true" use-java-context="true">
>         <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
> blah&password=blah</connection-url>
>         <driver>mysql</driver>
>     <pool>
>         <min-pool-size>1</min-pool-size>
>         <max-pool-size>10</max-pool-size>
>     </pool>
>     <timeout>
>         <idle-timeout-minutes>1</idle-timeout-minutes>
>     </timeout>
>     <validation>
>         <validate-on-match>true</validate-on-match>
>         <valid-connection-checker class-name="org.jboss.jca.
> adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
>         <exception-sorter  class-name="org.jboss.jca.
> adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
>     </validation>
> </datasource>
> - - - - - - - - -
>
> But the fact is that idle connections are still able to live to 90 seconds
> limit, instead of 1 minute.
>
> My suggestions was that connection was not closed by some Keycloak code and
> then returned to the connection pool, where it wasn't considered idle and
> was not "closed" (terminated).
>
> Could you please share your thoughts on this?
>
> Thanks.
>
>
> On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com> wrote:
>
>> You'll have to dive into Wildfly/JBoss EAP datasource configuration
>> documentation.  I know there are a multitude of connection pool switches
>> you can specify.
>>
>>
>> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
>> > Hi all,
>> >
>> > I deploy Keycloak server app to Cloud Foundry and use ClearDB service as
>> > relational database for Keycloak.
>> >
>> > ClearDB has a restriction, that it closes all connections, that are idle
>> for
>> > 90 seconds.
>> > To not run into the situation, when Keycloak tries to use closed
>> connection,
>> > I've added following datasource configuration (based on  Pivotal
>> > recommendations
>> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
>> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
>> > ):
>> >
>> >
>> >
>> > But even after applying this configuration I see in the ClearDB
>> management
>> > console that idle connections are closed only after 90 seconds and not
>> after
>> > 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
>> > parameter.
>> >
>> > So, have anybody of you faced similar situation? Or maybe you have some
>> > ideas why these idle connections are not being closed.
>> >
>> > Thanks.
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context: http://keycloak-user.88327.x6.
>> nabble.com/Idle-connections-are-not-closed-tp3948.html
>> > Sent from the keycloak-user mailing list archive at Nabble.com.
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
> --
> ? ?????????,
> ????????? ??????
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek


From kirmerzlikin at gmail.com  Fri Jul 14 01:07:05 2017
From: kirmerzlikin at gmail.com (=?UTF-8?B?0JrQuNGAINCc0LXRgNC30LvQuNC60LjQvQ==?=)
Date: Fri, 14 Jul 2017 08:07:05 +0300
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
	<CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
	<CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>
Message-ID: <CAFMb=TPeu=2QWj=zRgmDxfwXt3eHy8cc+-bWOA17XLsRLGB0SA@mail.gmail.com>

Hi Hynek,

Just did it  ? for all "idle" connections the command is Sleep and the time
is increasing constantly (till 90 sec).

Regarding other changes - I don't think so. At first I only specified JDBC
URL and that was it. Then I started seeing errors in the log about the
connection being closed by server and impossibility of query execution.
Then I found Pivotal recommendations and  JBOSS documentation and added
pool, timeout and validation configs.
So now I don't see previous errors, but I see new ones - from connection
validator, that  connection is not valid and ping fails.
It's good, that idle connections are not used anymore but what I what I
want is to close idle connections on the client before they are closed by
the server.

I saw similar situation described on stackoverflow
<https://stackoverflow.com/questions/28645435/database-connections-not-closed-after-idle-timeout-in-wildfly-datasource>,
but suggested solution didn't work for me, since I didn't know how to pass
custom hibernate property (-D option didn't help).

Thanks,

On Fri, Jul 14, 2017 at 7:20 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Can you inspect commands running in expectedly idle connections in
> MySQL via SHOW FULL PROCESSLIST? Have you changed any other
> datasource- and transaction-related configuration?
>
> Thanks
>
> On Thu, Jul 13, 2017 at 11:25 PM, ??? ????????? <kirmerzlikin at gmail.com>
> wrote:
> > Hi Bill,
> >
> > Yes, I have read a lot of documentation articles and manuals regarding
> > datasource configuration today.
> > Basing on this material, I've created following config, which should work
> > as I want:
> >
> > - - - - - - - - -
> > <datasource jndi-name="java:jboss/datasources/KeycloakDS"
> > pool-name="KeycloakDS" enabled="true" use-java-context="true">
> >         <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
> > blah&password=blah</connection-url>
> >         <driver>mysql</driver>
> >     <pool>
> >         <min-pool-size>1</min-pool-size>
> >         <max-pool-size>10</max-pool-size>
> >     </pool>
> >     <timeout>
> >         <idle-timeout-minutes>1</idle-timeout-minutes>
> >     </timeout>
> >     <validation>
> >         <validate-on-match>true</validate-on-match>
> >         <valid-connection-checker class-name="org.jboss.jca.
> > adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
> >         <exception-sorter  class-name="org.jboss.jca.
> > adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> >     </validation>
> > </datasource>
> > - - - - - - - - -
> >
> > But the fact is that idle connections are still able to live to 90
> seconds
> > limit, instead of 1 minute.
> >
> > My suggestions was that connection was not closed by some Keycloak code
> and
> > then returned to the connection pool, where it wasn't considered idle and
> > was not "closed" (terminated).
> >
> > Could you please share your thoughts on this?
> >
> > Thanks.
> >
> >
> > On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com> wrote:
> >
> >> You'll have to dive into Wildfly/JBoss EAP datasource configuration
> >> documentation.  I know there are a multitude of connection pool switches
> >> you can specify.
> >>
> >>
> >> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
> >> > Hi all,
> >> >
> >> > I deploy Keycloak server app to Cloud Foundry and use ClearDB service
> as
> >> > relational database for Keycloak.
> >> >
> >> > ClearDB has a restriction, that it closes all connections, that are
> idle
> >> for
> >> > 90 seconds.
> >> > To not run into the situation, when Keycloak tries to use closed
> >> connection,
> >> > I've added following datasource configuration (based on  Pivotal
> >> > recommendations
> >> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
> >> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
> >> > ):
> >> >
> >> >
> >> >
> >> > But even after applying this configuration I see in the ClearDB
> >> management
> >> > console that idle connections are closed only after 90 seconds and not
> >> after
> >> > 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
> >> > parameter.
> >> >
> >> > So, have anybody of you faced similar situation? Or maybe you have
> some
> >> > ideas why these idle connections are not being closed.
> >> >
> >> > Thanks.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context: http://keycloak-user.88327.x6.
> >> nabble.com/Idle-connections-are-not-closed-tp3948.html
> >> > Sent from the keycloak-user mailing list archive at Nabble.com.
> >> > _______________________________________________
> >> > keycloak-user mailing list
> >> > keycloak-user at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >
> >
> >
> > --
> > ? ?????????,
> > ????????? ??????
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> --Hynek
>



-- 
? ?????????,
????????? ??????

From sthorger at redhat.com  Fri Jul 14 01:30:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 14 Jul 2017 07:30:29 +0200
Subject: [keycloak-user] Upgrading from 2.5.4 to 3.2.0
In-Reply-To: <ME1PR01MB0769EDC404DFA75E8CD2F015A9AC0@ME1PR01MB0769.ausprd01.prod.outlook.com>
References: <ME1PR01MB0769EDC404DFA75E8CD2F015A9AC0@ME1PR01MB0769.ausprd01.prod.outlook.com>
Message-ID: <CAJgngAceMhWKGPZLAYPdxqP_AZb17wq9a4XwO+ugxZ61rGrXCg@mail.gmail.com>

Are you asking if you can upgrade the DB to 3.2 and still run 2.5.4? The
answer to that question is no. It simply won't work.

On 14 July 2017 at 01:11, Matt Evans <mevans at aconex.com> wrote:

> Hi
>
> We're looking to upgrade keycloak from 2.5.4 to 3.2.0, but I noticed in
> the liquibase changesets that one of the changes in 3.2.0 jpa changelog the
> column OFFLINE_CLIENT_SESSION has been deleted in the
> OFFLINE_CLIENT_SESSION table.
>
> My question is how will 2.5.4 handle that column missing if we update the
> schema first? I've tested this scenario in our environment and it seems to
> work, but we don't request offline tokens. Will that be enough to ensure
> that we won't get failures because of the missing column?
>
> Thanks
>
> Matt
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From thomas at recloux.fr  Fri Jul 14 04:29:17 2017
From: thomas at recloux.fr (Thomas Recloux)
Date: Fri, 14 Jul 2017 10:29:17 +0200
Subject: [keycloak-user] Customize admin console to support custom
	attributes
In-Reply-To: <70ff0924-6893-4721-e77a-f0ef55dc9f80@redhat.com>
References: <1499957072.1860837.1039806232.4FD36FF0@webmail.messagingengine.com>
	<70ff0924-6893-4721-e77a-f0ef55dc9f80@redhat.com>
Message-ID: <1500020957.3985352.1040646400.574D91A4@webmail.messagingengine.com>

On Thu, Jul 13, 2017, at 20:13, Bill Burke wrote:

> Its possible, but we don't have a nice way of extending the admin 
> console other than just modifying things yourself with a custom theme.

In a similar way than registration / account apps ?

Do you have any sample ?

Thanks, Thomas


From t.ruiten at rdmedia.com  Fri Jul 14 04:42:13 2017
From: t.ruiten at rdmedia.com (Tiemen Ruiten)
Date: Fri, 14 Jul 2017 10:42:13 +0200
Subject: [keycloak-user] illegal character in path when testing email
	setup
In-Reply-To: <CAAegNz0PmGi4Yc6T8Jw8nWSiX=X+3pBhH21+e9uaPq1ihHLVgQ@mail.gmail.com>
References: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>
	<CAJgngAf+v2vNGjJa-CH=gQxLE6qHVndJx1FkSx5tT6sUdM+Bow@mail.gmail.com>
	<CAAegNz2D3QRZSj+8nZBwy7+eWvi-VQqX3Sn2DDUpagw=xJz2FA@mail.gmail.com>
	<CAAegNz0PmGi4Yc6T8Jw8nWSiX=X+3pBhH21+e9uaPq1ihHLVgQ@mail.gmail.com>
Message-ID: <CAAegNz1riGEqKhKj2d9Qo0Nj=GsrQNL3AkTS1h+=iMxAWC6gQw@mail.gmail.com>

Stian, does this help? Should I file a bug report?

If anyone could give me some pointers for a workaround, that would also be
much appreciated.

On 12 July 2017 at 13:09, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:

> OK, so I rolled a new Keycloak instance and it gives me the exact same
> error. Reproducing is trivial:
>
> - login
> - click Realm Settings
> - click Email tab
> - Fill in Host and From fields
> - Hit 'Test connection'
>
>  I can share the Ansible playbook I used to setup the VM privately if
> you'd like.
>
> On 12 July 2017 at 11:43, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>
>> Hm, it's an almost vanilla Keycloak setup (however upgraded from 3.1.0 to
>> 3.2.0), in fact the only changes in standalone.xml are related to the
>> keystore and database. I'll see if I can setup another instance and
>> reproduce there.
>>
>> On 11 July 2017 at 07:35, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>>> Tried to reproduce this, but can't and it's working just fine here. Do
>>> you have steps to reproduce?
>>>
>>> On 10 July 2017 at 16:04, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I get the following error when hitting the 'Test connection' button on
>>>> the
>>>> email tab in Realm settings:
>>>>
>>>> 2017-07-10 15:55:27,316 INFO  [org.jboss.as] (Controller Boot Thread)
>>>> WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* started
>>>> in
>>>>
>>>> 21731ms - Started 449 of 824 services (561 services are lazy, passive or
>>>> on-demand)
>>>> 2017-07-10 15:56:48,997 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>>>> (default task-11) RESTEASY002130: Failed to parse request.:
>>>> javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to create
>>>> URI:
>>>> https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
>>>> "port":null,"host":"mail.rdmedia.com
>>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>>>> at
>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>>>> es(ResteasyUriBuilder.java:749)
>>>> at
>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(Resteas
>>>> yUriBuilder.java:721)
>>>> at
>>>> org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUr
>>>> iInfo.java:58)
>>>> at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInf
>>>> o.java:53)
>>>> at
>>>> org.jboss.resteasy.plugins.server.servlet.ServletUtil.extrac
>>>> tUriInfo(ServletUtil.java:41)
>>>> at
>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
>>>> spatcher.service(ServletContainerDispatcher.java:200)
>>>> at
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>>>> her.service(HttpServletDispatcher.java:56)
>>>> at
>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>>>> her.service(HttpServletDispatcher.java:51)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>> at
>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
>>>> rvletHandler.java:85)
>>>> at
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>>>> oFilter(FilterHandler.java:129)
>>>> at
>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.d
>>>> oFilter(KeycloakSessionServletFilter.java:90)
>>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilte
>>>> r.java:60)
>>>> at
>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>>>> oFilter(FilterHandler.java:131)
>>>> at
>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
>>>> terHandler.java:84)
>>>> at
>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHan
>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>> at
>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl
>>>> eRequest(ServletDispatchingHandler.java:36)
>>>> at
>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc
>>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>> at
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at
>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat
>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>> at
>>>> io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>> at
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at
>>>> io.undertow.security.handlers.AbstractConfidentialityHandler
>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>> at
>>>> io.undertow.servlet.handlers.security.ServletConfidentiality
>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>> aintHandler.java:64)
>>>> at
>>>> io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>> at
>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>> at
>>>> io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>> at
>>>> io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>> Handler.java:43)
>>>> at
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at
>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>> at
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at
>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at
>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>> stRequest(ServletInitialHandler.java:284)
>>>> at
>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>> equest(ServletInitialHandler.java:263)
>>>> at
>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>> 0(ServletInitialHandler.java:81)
>>>> at
>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>> equest(ServletInitialHandler.java:174)
>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>> java:202)
>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>> ge.java:793)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>> Caused by: java.net.URISyntaxException: Illegal character in path at
>>>> index
>>>> 67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConn
>>>> ection/{
>>>> "port":null,"host":"mail.rdmedia.com
>>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>>>> at java.net.URI$Parser.fail(URI.java:2848)
>>>> at java.net.URI$Parser.checkChars(URI.java:3021)
>>>> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
>>>> at java.net.URI$Parser.parse(URI.java:3053)
>>>> at java.net.URI.<init>(URI.java:588)
>>>> at
>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>>>> es(ResteasyUriBuilder.java:744)
>>>> ... 40 more
>>>>
>>>> The 67th character is the slash after testSMTPConnection. Is this a bug
>>>> and/or is there a workaround/fix?
>>>>
>>>> --
>>>> Tiemen Ruiten
>>>> Systems Engineer
>>>> R&D Media
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>>
>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>



-- 
Tiemen Ruiten
Systems Engineer
R&D Media

From sthorger at redhat.com  Fri Jul 14 05:59:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 14 Jul 2017 11:59:39 +0200
Subject: [keycloak-user] illegal character in path when testing email
	setup
In-Reply-To: <CAAegNz1riGEqKhKj2d9Qo0Nj=GsrQNL3AkTS1h+=iMxAWC6gQw@mail.gmail.com>
References: <CAAegNz1THFADhejDJ3+r61nw+CrsZQGSBrx876_m7DFc05ZaBQ@mail.gmail.com>
	<CAJgngAf+v2vNGjJa-CH=gQxLE6qHVndJx1FkSx5tT6sUdM+Bow@mail.gmail.com>
	<CAAegNz2D3QRZSj+8nZBwy7+eWvi-VQqX3Sn2DDUpagw=xJz2FA@mail.gmail.com>
	<CAAegNz0PmGi4Yc6T8Jw8nWSiX=X+3pBhH21+e9uaPq1ihHLVgQ@mail.gmail.com>
	<CAAegNz1riGEqKhKj2d9Qo0Nj=GsrQNL3AkTS1h+=iMxAWC6gQw@mail.gmail.com>
Message-ID: <CAJgngAdnOfWegUyA_ztwXneeSqGC5g9FONQvJW8E_XVOyJ-Q6A@mail.gmail.com>

I've tried the same steps and we have tests that do the same steps. So
there's something more to it. You can create a JIRA sure, but we need to be
able to reproduce it.

Ideal is that you can reproduce it with a fresh install of Keycloak
directly on your box with a fresh DB as well.

On 14 July 2017 at 10:42, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:

> Stian, does this help? Should I file a bug report?
>
> If anyone could give me some pointers for a workaround, that would also be
> much appreciated.
>
>
> On 12 July 2017 at 13:09, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>
>> OK, so I rolled a new Keycloak instance and it gives me the exact same
>> error. Reproducing is trivial:
>>
>> - login
>> - click Realm Settings
>> - click Email tab
>> - Fill in Host and From fields
>> - Hit 'Test connection'
>>
>>  I can share the Ansible playbook I used to setup the VM privately if
>> you'd like.
>>
>> On 12 July 2017 at 11:43, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>>
>>> Hm, it's an almost vanilla Keycloak setup (however upgraded from 3.1.0
>>> to 3.2.0), in fact the only changes in standalone.xml are related to the
>>> keystore and database. I'll see if I can setup another instance and
>>> reproduce there.
>>>
>>> On 11 July 2017 at 07:35, Stian Thorgersen <sthorger at redhat.com> wrote:
>>>
>>>> Tried to reproduce this, but can't and it's working just fine here. Do
>>>> you have steps to reproduce?
>>>>
>>>> On 10 July 2017 at 16:04, Tiemen Ruiten <t.ruiten at rdmedia.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I get the following error when hitting the 'Test connection' button on
>>>>> the
>>>>> email tab in Realm settings:
>>>>>
>>>>> 2017-07-10 15:55:27,316 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>> WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)*
>>>>> started in
>>>>>
>>>>> 21731ms - Started 449 of 824 services (561 services are lazy, passive
>>>>> or
>>>>> on-demand)
>>>>> 2017-07-10 15:56:48,997 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>>>>> (default task-11) RESTEASY002130: Failed to parse request.:
>>>>> javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to
>>>>> create URI:
>>>>> https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{
>>>>> "port":null,"host":"mail.rdmedia.com
>>>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>>>>> at
>>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>>>>> es(ResteasyUriBuilder.java:749)
>>>>> at
>>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(Resteas
>>>>> yUriBuilder.java:721)
>>>>> at
>>>>> org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUr
>>>>> iInfo.java:58)
>>>>> at org.jboss.resteasy.spi.ResteasyUriInfo.<init>(ResteasyUriInf
>>>>> o.java:53)
>>>>> at
>>>>> org.jboss.resteasy.plugins.server.servlet.ServletUtil.extrac
>>>>> tUriInfo(ServletUtil.java:41)
>>>>> at
>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
>>>>> spatcher.service(ServletContainerDispatcher.java:200)
>>>>> at
>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>>>>> her.service(HttpServletDispatcher.java:56)
>>>>> at
>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
>>>>> her.service(HttpServletDispatcher.java:51)
>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>>> at
>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
>>>>> rvletHandler.java:85)
>>>>> at
>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>>>>> oFilter(FilterHandler.java:129)
>>>>> at
>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.d
>>>>> oFilter(KeycloakSessionServletFilter.java:90)
>>>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilte
>>>>> r.java:60)
>>>>> at
>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
>>>>> oFilter(FilterHandler.java:131)
>>>>> at
>>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
>>>>> terHandler.java:84)
>>>>> at
>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHan
>>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>>> at
>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl
>>>>> eRequest(ServletDispatchingHandler.java:36)
>>>>> at
>>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc
>>>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>>> at
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at
>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat
>>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>>> at
>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>>> at
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at
>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler
>>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>>> at
>>>>> io.undertow.servlet.handlers.security.ServletConfidentiality
>>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>>> aintHandler.java:64)
>>>>> at
>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>> at
>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>> at
>>>>> io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>>> at
>>>>> io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>>> Handler.java:43)
>>>>> at
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at
>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>>> at
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at
>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>>> stRequest(ServletInitialHandler.java:284)
>>>>> at
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>>> equest(ServletInitialHandler.java:263)
>>>>> at
>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>>> 0(ServletInitialHandler.java:81)
>>>>> at
>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>>> equest(ServletInitialHandler.java:174)
>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>>> java:202)
>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>>> ge.java:793)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>>> Executor.java:1142)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>>> lExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>> Caused by: java.net.URISyntaxException: Illegal character in path at
>>>>> index
>>>>> 67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConn
>>>>> ection/{
>>>>> "port":null,"host":"mail.rdmedia.com
>>>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"}
>>>>> at java.net.URI$Parser.fail(URI.java:2848)
>>>>> at java.net.URI$Parser.checkChars(URI.java:3021)
>>>>> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
>>>>> at java.net.URI$Parser.parse(URI.java:3053)
>>>>> at java.net.URI.<init>(URI.java:588)
>>>>> at
>>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu
>>>>> es(ResteasyUriBuilder.java:744)
>>>>> ... 40 more
>>>>>
>>>>> The 67th character is the slash after testSMTPConnection. Is this a bug
>>>>> and/or is there a workaround/fix?
>>>>>
>>>>> --
>>>>> Tiemen Ruiten
>>>>> Systems Engineer
>>>>> R&D Media
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Tiemen Ruiten
>>> Systems Engineer
>>> R&D Media
>>>
>>
>>
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>>
>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>

From hmlnarik at redhat.com  Fri Jul 14 06:56:07 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 14 Jul 2017 12:56:07 +0200
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <CAFMb=TPeu=2QWj=zRgmDxfwXt3eHy8cc+-bWOA17XLsRLGB0SA@mail.gmail.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
	<CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
	<CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>
	<CAFMb=TPeu=2QWj=zRgmDxfwXt3eHy8cc+-bWOA17XLsRLGB0SA@mail.gmail.com>
Message-ID: <CAMvXD=EnZpzfWdmdRd8nVKUf3SOGpJj65+1uBn-ynLs=TMB9vA@mail.gmail.com>

On Fri, Jul 14, 2017 at 7:07 AM, ??? ????????? <kirmerzlikin at gmail.com> wrote:
> Hi Hynek,
>
> Just did it  ? for all "idle" connections the command is Sleep and the time
> is increasing constantly (till 90 sec).
>
> Regarding other changes - I don't think so. At first I only specified JDBC
> URL and that was it. Then I started seeing errors in the log about the
> connection being closed by server and impossibility of query execution. Then
> I found Pivotal recommendations and  JBOSS documentation and added pool,
> timeout and validation configs.
> So now I don't see previous errors, but I see new ones - from connection
> validator, that  connection is not valid and ping fails.
> It's good, that idle connections are not used anymore but what I what I want
> is to close idle connections on the client before they are closed by the
> server.
>
> I saw similar situation described on stackoverflow, but suggested solution
> didn't work for me, since I didn't know how to pass custom hibernate
> property (-D option didn't help).

Can you try adding the following line into persistence.xml [1] file
that is present in keycloak-model-jpa.jar module?

-----------
    <property name="hibernate.connection.release_mode">after_transaction</property>
-----------

[1] https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L87

> On Fri, Jul 14, 2017 at 7:20 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> Can you inspect commands running in expectedly idle connections in
>> MySQL via SHOW FULL PROCESSLIST? Have you changed any other
>> datasource- and transaction-related configuration?
>>
>> Thanks
>>
>> On Thu, Jul 13, 2017 at 11:25 PM, ??? ????????? <kirmerzlikin at gmail.com>
>> wrote:
>> > Hi Bill,
>> >
>> > Yes, I have read a lot of documentation articles and manuals regarding
>> > datasource configuration today.
>> > Basing on this material, I've created following config, which should
>> > work
>> > as I want:
>> >
>> > - - - - - - - - -
>> > <datasource jndi-name="java:jboss/datasources/KeycloakDS"
>> > pool-name="KeycloakDS" enabled="true" use-java-context="true">
>> >         <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
>> > blah&password=blah</connection-url>
>> >         <driver>mysql</driver>
>> >     <pool>
>> >         <min-pool-size>1</min-pool-size>
>> >         <max-pool-size>10</max-pool-size>
>> >     </pool>
>> >     <timeout>
>> >         <idle-timeout-minutes>1</idle-timeout-minutes>
>> >     </timeout>
>> >     <validation>
>> >         <validate-on-match>true</validate-on-match>
>> >         <valid-connection-checker class-name="org.jboss.jca.
>> > adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
>> >         <exception-sorter  class-name="org.jboss.jca.
>> > adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
>> >     </validation>
>> > </datasource>
>> > - - - - - - - - -
>> >
>> > But the fact is that idle connections are still able to live to 90
>> > seconds
>> > limit, instead of 1 minute.
>> >
>> > My suggestions was that connection was not closed by some Keycloak code
>> > and
>> > then returned to the connection pool, where it wasn't considered idle
>> > and
>> > was not "closed" (terminated).
>> >
>> > Could you please share your thoughts on this?
>> >
>> > Thanks.
>> >
>> >
>> > On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com> wrote:
>> >
>> >> You'll have to dive into Wildfly/JBoss EAP datasource configuration
>> >> documentation.  I know there are a multitude of connection pool
>> >> switches
>> >> you can specify.
>> >>
>> >>
>> >> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
>> >> > Hi all,
>> >> >
>> >> > I deploy Keycloak server app to Cloud Foundry and use ClearDB service
>> >> > as
>> >> > relational database for Keycloak.
>> >> >
>> >> > ClearDB has a restriction, that it closes all connections, that are
>> >> > idle
>> >> for
>> >> > 90 seconds.
>> >> > To not run into the situation, when Keycloak tries to use closed
>> >> connection,
>> >> > I've added following datasource configuration (based on  Pivotal
>> >> > recommendations
>> >> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
>> >> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
>> >> > ):
>> >> >
>> >> >
>> >> >
>> >> > But even after applying this configuration I see in the ClearDB
>> >> management
>> >> > console that idle connections are closed only after 90 seconds and
>> >> > not
>> >> after
>> >> > 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
>> >> > parameter.
>> >> >
>> >> > So, have anybody of you faced similar situation? Or maybe you have
>> >> > some
>> >> > ideas why these idle connections are not being closed.
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > View this message in context: http://keycloak-user.88327.x6.
>> >> nabble.com/Idle-connections-are-not-closed-tp3948.html
>> >> > Sent from the keycloak-user mailing list archive at Nabble.com.
>> >> > _______________________________________________
>> >> > keycloak-user mailing list
>> >> > keycloak-user at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >>
>> >> _______________________________________________
>> >> keycloak-user mailing list
>> >> keycloak-user at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >>
>> >
>> >
>> >
>> > --
>> > ? ?????????,
>> > ????????? ??????
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> --
>>
>> --Hynek
>
>
>
>
> --
> ? ?????????,
> ????????? ??????



-- 

--Hynek


From kirmerzlikin at gmail.com  Fri Jul 14 07:18:40 2017
From: kirmerzlikin at gmail.com (=?UTF-8?B?0JrQuNGAINCc0LXRgNC30LvQuNC60LjQvQ==?=)
Date: Fri, 14 Jul 2017 14:18:40 +0300
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <CAMvXD=EnZpzfWdmdRd8nVKUf3SOGpJj65+1uBn-ynLs=TMB9vA@mail.gmail.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
	<CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
	<CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>
	<CAFMb=TPeu=2QWj=zRgmDxfwXt3eHy8cc+-bWOA17XLsRLGB0SA@mail.gmail.com>
	<CAMvXD=EnZpzfWdmdRd8nVKUf3SOGpJj65+1uBn-ynLs=TMB9vA@mail.gmail.com>
Message-ID: <CAFMb=TOGD0TM4bpGf5JrJyanYGPfjL69gHYf8kSF6NvcNQ8f1A@mail.gmail.com>

Hi Hynek,

Thanks for an idea where to find a persistence.xml
But after these changes it still works as before - idle connections live
till 90 seconds :(

p.s. sorry for not mentioning it earlier - I use Keycloak 3.1.0.Final


On Fri, Jul 14, 2017 at 1:56 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> On Fri, Jul 14, 2017 at 7:07 AM, ??? ????????? <kirmerzlikin at gmail.com>
> wrote:
> > Hi Hynek,
> >
> > Just did it  ? for all "idle" connections the command is Sleep and the
> time
> > is increasing constantly (till 90 sec).
> >
> > Regarding other changes - I don't think so. At first I only specified
> JDBC
> > URL and that was it. Then I started seeing errors in the log about the
> > connection being closed by server and impossibility of query execution.
> Then
> > I found Pivotal recommendations and  JBOSS documentation and added pool,
> > timeout and validation configs.
> > So now I don't see previous errors, but I see new ones - from connection
> > validator, that  connection is not valid and ping fails.
> > It's good, that idle connections are not used anymore but what I what I
> want
> > is to close idle connections on the client before they are closed by the
> > server.
> >
> > I saw similar situation described on stackoverflow, but suggested
> solution
> > didn't work for me, since I didn't know how to pass custom hibernate
> > property (-D option didn't help).
>
> Can you try adding the following line into persistence.xml [1] file
> that is present in keycloak-model-jpa.jar module?
>
> -----------
>     <property name="hibernate.connection.release_mode">after_
> transaction</property>
> -----------
>
> [1] https://github.com/keycloak/keycloak/blob/master/model/
> jpa/src/main/resources/META-INF/persistence.xml#L87
>
> > On Fri, Jul 14, 2017 at 7:20 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
> >>
> >> Can you inspect commands running in expectedly idle connections in
> >> MySQL via SHOW FULL PROCESSLIST? Have you changed any other
> >> datasource- and transaction-related configuration?
> >>
> >> Thanks
> >>
> >> On Thu, Jul 13, 2017 at 11:25 PM, ??? ????????? <kirmerzlikin at gmail.com
> >
> >> wrote:
> >> > Hi Bill,
> >> >
> >> > Yes, I have read a lot of documentation articles and manuals regarding
> >> > datasource configuration today.
> >> > Basing on this material, I've created following config, which should
> >> > work
> >> > as I want:
> >> >
> >> > - - - - - - - - -
> >> > <datasource jndi-name="java:jboss/datasources/KeycloakDS"
> >> > pool-name="KeycloakDS" enabled="true" use-java-context="true">
> >> >         <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
> >> > blah&password=blah</connection-url>
> >> >         <driver>mysql</driver>
> >> >     <pool>
> >> >         <min-pool-size>1</min-pool-size>
> >> >         <max-pool-size>10</max-pool-size>
> >> >     </pool>
> >> >     <timeout>
> >> >         <idle-timeout-minutes>1</idle-timeout-minutes>
> >> >     </timeout>
> >> >     <validation>
> >> >         <validate-on-match>true</validate-on-match>
> >> >         <valid-connection-checker class-name="org.jboss.jca.
> >> > adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
> >> >         <exception-sorter  class-name="org.jboss.jca.
> >> > adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> >> >     </validation>
> >> > </datasource>
> >> > - - - - - - - - -
> >> >
> >> > But the fact is that idle connections are still able to live to 90
> >> > seconds
> >> > limit, instead of 1 minute.
> >> >
> >> > My suggestions was that connection was not closed by some Keycloak
> code
> >> > and
> >> > then returned to the connection pool, where it wasn't considered idle
> >> > and
> >> > was not "closed" (terminated).
> >> >
> >> > Could you please share your thoughts on this?
> >> >
> >> > Thanks.
> >> >
> >> >
> >> > On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >> >
> >> >> You'll have to dive into Wildfly/JBoss EAP datasource configuration
> >> >> documentation.  I know there are a multitude of connection pool
> >> >> switches
> >> >> you can specify.
> >> >>
> >> >>
> >> >> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > I deploy Keycloak server app to Cloud Foundry and use ClearDB
> service
> >> >> > as
> >> >> > relational database for Keycloak.
> >> >> >
> >> >> > ClearDB has a restriction, that it closes all connections, that are
> >> >> > idle
> >> >> for
> >> >> > 90 seconds.
> >> >> > To not run into the situation, when Keycloak tries to use closed
> >> >> connection,
> >> >> > I've added following datasource configuration (based on  Pivotal
> >> >> > recommendations
> >> >> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
> >> >> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
> >> >> > ):
> >> >> >
> >> >> >
> >> >> >
> >> >> > But even after applying this configuration I see in the ClearDB
> >> >> management
> >> >> > console that idle connections are closed only after 90 seconds and
> >> >> > not
> >> >> after
> >> >> > 60 seconds (1 minute) as it's specified with "idle-timeout-minutes"
> >> >> > parameter.
> >> >> >
> >> >> > So, have anybody of you faced similar situation? Or maybe you have
> >> >> > some
> >> >> > ideas why these idle connections are not being closed.
> >> >> >
> >> >> > Thanks.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > View this message in context: http://keycloak-user.88327.x6.
> >> >> nabble.com/Idle-connections-are-not-closed-tp3948.html
> >> >> > Sent from the keycloak-user mailing list archive at Nabble.com.
> >> >> > _______________________________________________
> >> >> > keycloak-user mailing list
> >> >> > keycloak-user at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >> >>
> >> >> _______________________________________________
> >> >> keycloak-user mailing list
> >> >> keycloak-user at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > ? ?????????,
> >> > ????????? ??????
> >> > _______________________________________________
> >> > keycloak-user mailing list
> >> > keycloak-user at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
> >
> >
> > --
> > ? ?????????,
> > ????????? ??????
>
>
>
> --
>
> --Hynek
>



-- 
? ?????????,
????????? ??????

From hmlnarik at redhat.com  Fri Jul 14 07:21:28 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 14 Jul 2017 13:21:28 +0200
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <CAFMb=TOGD0TM4bpGf5JrJyanYGPfjL69gHYf8kSF6NvcNQ8f1A@mail.gmail.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
	<CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
	<CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>
	<CAFMb=TPeu=2QWj=zRgmDxfwXt3eHy8cc+-bWOA17XLsRLGB0SA@mail.gmail.com>
	<CAMvXD=EnZpzfWdmdRd8nVKUf3SOGpJj65+1uBn-ynLs=TMB9vA@mail.gmail.com>
	<CAFMb=TOGD0TM4bpGf5JrJyanYGPfjL69gHYf8kSF6NvcNQ8f1A@mail.gmail.com>
Message-ID: <CAMvXD=EMBf17G92Dee6rKiD2wwX7suvr2yrmQG310=PRygUbjA@mail.gmail.com>

In that case I suggest you to ask Wildfly community as this does not
look like Keycloak issue. If you find a way to resolve it, I'd be
interested if you could share your findings.

Thanks

--Hynek

On Fri, Jul 14, 2017 at 1:18 PM, ??? ????????? <kirmerzlikin at gmail.com> wrote:
> Hi Hynek,
>
> Thanks for an idea where to find a persistence.xml
> But after these changes it still works as before - idle connections live
> till 90 seconds :(
>
> p.s. sorry for not mentioning it earlier - I use Keycloak 3.1.0.Final
>
>
> On Fri, Jul 14, 2017 at 1:56 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> On Fri, Jul 14, 2017 at 7:07 AM, ??? ????????? <kirmerzlikin at gmail.com>
>> wrote:
>> > Hi Hynek,
>> >
>> > Just did it  ? for all "idle" connections the command is Sleep and the
>> > time
>> > is increasing constantly (till 90 sec).
>> >
>> > Regarding other changes - I don't think so. At first I only specified
>> > JDBC
>> > URL and that was it. Then I started seeing errors in the log about the
>> > connection being closed by server and impossibility of query execution.
>> > Then
>> > I found Pivotal recommendations and  JBOSS documentation and added pool,
>> > timeout and validation configs.
>> > So now I don't see previous errors, but I see new ones - from connection
>> > validator, that  connection is not valid and ping fails.
>> > It's good, that idle connections are not used anymore but what I what I
>> > want
>> > is to close idle connections on the client before they are closed by the
>> > server.
>> >
>> > I saw similar situation described on stackoverflow, but suggested
>> > solution
>> > didn't work for me, since I didn't know how to pass custom hibernate
>> > property (-D option didn't help).
>>
>> Can you try adding the following line into persistence.xml [1] file
>> that is present in keycloak-model-jpa.jar module?
>>
>> -----------
>>     <property
>> name="hibernate.connection.release_mode">after_transaction</property>
>> -----------
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L87
>>
>> > On Fri, Jul 14, 2017 at 7:20 AM, Hynek Mlnarik <hmlnarik at redhat.com>
>> > wrote:
>> >>
>> >> Can you inspect commands running in expectedly idle connections in
>> >> MySQL via SHOW FULL PROCESSLIST? Have you changed any other
>> >> datasource- and transaction-related configuration?
>> >>
>> >> Thanks
>> >>
>> >> On Thu, Jul 13, 2017 at 11:25 PM, ??? ?????????
>> >> <kirmerzlikin at gmail.com>
>> >> wrote:
>> >> > Hi Bill,
>> >> >
>> >> > Yes, I have read a lot of documentation articles and manuals
>> >> > regarding
>> >> > datasource configuration today.
>> >> > Basing on this material, I've created following config, which should
>> >> > work
>> >> > as I want:
>> >> >
>> >> > - - - - - - - - -
>> >> > <datasource jndi-name="java:jboss/datasources/KeycloakDS"
>> >> > pool-name="KeycloakDS" enabled="true" use-java-context="true">
>> >> >         <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
>> >> > blah&password=blah</connection-url>
>> >> >         <driver>mysql</driver>
>> >> >     <pool>
>> >> >         <min-pool-size>1</min-pool-size>
>> >> >         <max-pool-size>10</max-pool-size>
>> >> >     </pool>
>> >> >     <timeout>
>> >> >         <idle-timeout-minutes>1</idle-timeout-minutes>
>> >> >     </timeout>
>> >> >     <validation>
>> >> >         <validate-on-match>true</validate-on-match>
>> >> >         <valid-connection-checker class-name="org.jboss.jca.
>> >> > adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
>> >> >         <exception-sorter  class-name="org.jboss.jca.
>> >> > adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
>> >> >     </validation>
>> >> > </datasource>
>> >> > - - - - - - - - -
>> >> >
>> >> > But the fact is that idle connections are still able to live to 90
>> >> > seconds
>> >> > limit, instead of 1 minute.
>> >> >
>> >> > My suggestions was that connection was not closed by some Keycloak
>> >> > code
>> >> > and
>> >> > then returned to the connection pool, where it wasn't considered idle
>> >> > and
>> >> > was not "closed" (terminated).
>> >> >
>> >> > Could you please share your thoughts on this?
>> >> >
>> >> > Thanks.
>> >> >
>> >> >
>> >> > On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com>
>> >> > wrote:
>> >> >
>> >> >> You'll have to dive into Wildfly/JBoss EAP datasource configuration
>> >> >> documentation.  I know there are a multitude of connection pool
>> >> >> switches
>> >> >> you can specify.
>> >> >>
>> >> >>
>> >> >> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I deploy Keycloak server app to Cloud Foundry and use ClearDB
>> >> >> > service
>> >> >> > as
>> >> >> > relational database for Keycloak.
>> >> >> >
>> >> >> > ClearDB has a restriction, that it closes all connections, that
>> >> >> > are
>> >> >> > idle
>> >> >> for
>> >> >> > 90 seconds.
>> >> >> > To not run into the situation, when Keycloak tries to use closed
>> >> >> connection,
>> >> >> > I've added following datasource configuration (based on  Pivotal
>> >> >> > recommendations
>> >> >> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
>> >> >> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
>> >> >> > ):
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > But even after applying this configuration I see in the ClearDB
>> >> >> management
>> >> >> > console that idle connections are closed only after 90 seconds and
>> >> >> > not
>> >> >> after
>> >> >> > 60 seconds (1 minute) as it's specified with
>> >> >> > "idle-timeout-minutes"
>> >> >> > parameter.
>> >> >> >
>> >> >> > So, have anybody of you faced similar situation? Or maybe you have
>> >> >> > some
>> >> >> > ideas why these idle connections are not being closed.
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > View this message in context: http://keycloak-user.88327.x6.
>> >> >> nabble.com/Idle-connections-are-not-closed-tp3948.html
>> >> >> > Sent from the keycloak-user mailing list archive at Nabble.com.
>> >> >> > _______________________________________________
>> >> >> > keycloak-user mailing list
>> >> >> > keycloak-user at lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >> >>
>> >> >> _______________________________________________
>> >> >> keycloak-user mailing list
>> >> >> keycloak-user at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > ? ?????????,
>> >> > ????????? ??????
>> >> > _______________________________________________
>> >> > keycloak-user mailing list
>> >> > keycloak-user at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> --Hynek
>> >
>> >
>> >
>> >
>> > --
>> > ? ?????????,
>> > ????????? ??????
>>
>>
>>
>> --
>>
>> --Hynek
>
>
>
>
> --
> ? ?????????,
> ????????? ??????



-- 

--Hynek


From kirmerzlikin at gmail.com  Fri Jul 14 07:30:14 2017
From: kirmerzlikin at gmail.com (=?UTF-8?B?0JrQuNGAINCc0LXRgNC30LvQuNC60LjQvQ==?=)
Date: Fri, 14 Jul 2017 14:30:14 +0300
Subject: [keycloak-user] Idle connections are not closed
In-Reply-To: <CAMvXD=EMBf17G92Dee6rKiD2wwX7suvr2yrmQG310=PRygUbjA@mail.gmail.com>
References: <1499954617778-3948.post@n6.nabble.com>
	<7d72f4ab-e4ea-0f8e-39d0-1ade983563f8@redhat.com>
	<CAFMb=TMrX0tXEpQYVwjjenF_xVujim=hj2APmt9d2D=4xm3N1Q@mail.gmail.com>
	<CAMvXD=Gb8iztHfr0G7WJQ=hiN=QKqvoYjNo-eiv7KV5==y6PvQ@mail.gmail.com>
	<CAFMb=TPeu=2QWj=zRgmDxfwXt3eHy8cc+-bWOA17XLsRLGB0SA@mail.gmail.com>
	<CAMvXD=EnZpzfWdmdRd8nVKUf3SOGpJj65+1uBn-ynLs=TMB9vA@mail.gmail.com>
	<CAFMb=TOGD0TM4bpGf5JrJyanYGPfjL69gHYf8kSF6NvcNQ8f1A@mail.gmail.com>
	<CAMvXD=EMBf17G92Dee6rKiD2wwX7suvr2yrmQG310=PRygUbjA@mail.gmail.com>
Message-ID: <CAFMb=TNmgFN3xGsWumNCfchCOMvixzF_ddZEhWcC-QdOvk6WYw@mail.gmail.com>

Thanks for your help!

I'll try to reproduce this issue on pure Wildfly 10.0.0.Final server and
then write to community.

If I get positive results, I'll let you know.

On Fri, Jul 14, 2017 at 2:21 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> In that case I suggest you to ask Wildfly community as this does not
> look like Keycloak issue. If you find a way to resolve it, I'd be
> interested if you could share your findings.
>
> Thanks
>
> --Hynek
>
> On Fri, Jul 14, 2017 at 1:18 PM, ??? ????????? <kirmerzlikin at gmail.com>
> wrote:
> > Hi Hynek,
> >
> > Thanks for an idea where to find a persistence.xml
> > But after these changes it still works as before - idle connections live
> > till 90 seconds :(
> >
> > p.s. sorry for not mentioning it earlier - I use Keycloak 3.1.0.Final
> >
> >
> > On Fri, Jul 14, 2017 at 1:56 PM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
> >>
> >> On Fri, Jul 14, 2017 at 7:07 AM, ??? ????????? <kirmerzlikin at gmail.com>
> >> wrote:
> >> > Hi Hynek,
> >> >
> >> > Just did it  ? for all "idle" connections the command is Sleep and the
> >> > time
> >> > is increasing constantly (till 90 sec).
> >> >
> >> > Regarding other changes - I don't think so. At first I only specified
> >> > JDBC
> >> > URL and that was it. Then I started seeing errors in the log about the
> >> > connection being closed by server and impossibility of query
> execution.
> >> > Then
> >> > I found Pivotal recommendations and  JBOSS documentation and added
> pool,
> >> > timeout and validation configs.
> >> > So now I don't see previous errors, but I see new ones - from
> connection
> >> > validator, that  connection is not valid and ping fails.
> >> > It's good, that idle connections are not used anymore but what I what
> I
> >> > want
> >> > is to close idle connections on the client before they are closed by
> the
> >> > server.
> >> >
> >> > I saw similar situation described on stackoverflow, but suggested
> >> > solution
> >> > didn't work for me, since I didn't know how to pass custom hibernate
> >> > property (-D option didn't help).
> >>
> >> Can you try adding the following line into persistence.xml [1] file
> >> that is present in keycloak-model-jpa.jar module?
> >>
> >> -----------
> >>     <property
> >> name="hibernate.connection.release_mode">after_transaction</property>
> >> -----------
> >>
> >> [1]
> >> https://github.com/keycloak/keycloak/blob/master/model/
> jpa/src/main/resources/META-INF/persistence.xml#L87
> >>
> >> > On Fri, Jul 14, 2017 at 7:20 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> >> > wrote:
> >> >>
> >> >> Can you inspect commands running in expectedly idle connections in
> >> >> MySQL via SHOW FULL PROCESSLIST? Have you changed any other
> >> >> datasource- and transaction-related configuration?
> >> >>
> >> >> Thanks
> >> >>
> >> >> On Thu, Jul 13, 2017 at 11:25 PM, ??? ?????????
> >> >> <kirmerzlikin at gmail.com>
> >> >> wrote:
> >> >> > Hi Bill,
> >> >> >
> >> >> > Yes, I have read a lot of documentation articles and manuals
> >> >> > regarding
> >> >> > datasource configuration today.
> >> >> > Basing on this material, I've created following config, which
> should
> >> >> > work
> >> >> > as I want:
> >> >> >
> >> >> > - - - - - - - - -
> >> >> > <datasource jndi-name="java:jboss/datasources/KeycloakDS"
> >> >> > pool-name="KeycloakDS" enabled="true" use-java-context="true">
> >> >> >         <connection-url>jdbc:mysql://blah.cleardb.net/blah?user=
> >> >> > blah&password=blah</connection-url>
> >> >> >         <driver>mysql</driver>
> >> >> >     <pool>
> >> >> >         <min-pool-size>1</min-pool-size>
> >> >> >         <max-pool-size>10</max-pool-size>
> >> >> >     </pool>
> >> >> >     <timeout>
> >> >> >         <idle-timeout-minutes>1</idle-timeout-minutes>
> >> >> >     </timeout>
> >> >> >     <validation>
> >> >> >         <validate-on-match>true</validate-on-match>
> >> >> >         <valid-connection-checker class-name="org.jboss.jca.
> >> >> > adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
> >> >> >         <exception-sorter  class-name="org.jboss.jca.
> >> >> > adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> >> >> >     </validation>
> >> >> > </datasource>
> >> >> > - - - - - - - - -
> >> >> >
> >> >> > But the fact is that idle connections are still able to live to 90
> >> >> > seconds
> >> >> > limit, instead of 1 minute.
> >> >> >
> >> >> > My suggestions was that connection was not closed by some Keycloak
> >> >> > code
> >> >> > and
> >> >> > then returned to the connection pool, where it wasn't considered
> idle
> >> >> > and
> >> >> > was not "closed" (terminated).
> >> >> >
> >> >> > Could you please share your thoughts on this?
> >> >> >
> >> >> > Thanks.
> >> >> >
> >> >> >
> >> >> > On Thu, Jul 13, 2017 at 9:14 PM, Bill Burke <bburke at redhat.com>
> >> >> > wrote:
> >> >> >
> >> >> >> You'll have to dive into Wildfly/JBoss EAP datasource
> configuration
> >> >> >> documentation.  I know there are a multitude of connection pool
> >> >> >> switches
> >> >> >> you can specify.
> >> >> >>
> >> >> >>
> >> >> >> On 7/13/17 10:03 AM, Kir Merzlikin wrote:
> >> >> >> > Hi all,
> >> >> >> >
> >> >> >> > I deploy Keycloak server app to Cloud Foundry and use ClearDB
> >> >> >> > service
> >> >> >> > as
> >> >> >> > relational database for Keycloak.
> >> >> >> >
> >> >> >> > ClearDB has a restriction, that it closes all connections, that
> >> >> >> > are
> >> >> >> > idle
> >> >> >> for
> >> >> >> > 90 seconds.
> >> >> >> > To not run into the situation, when Keycloak tries to use closed
> >> >> >> connection,
> >> >> >> > I've added following datasource configuration (based on  Pivotal
> >> >> >> > recommendations
> >> >> >> > <https://discuss.pivotal.io/hc/en-us/articles/230433268-
> >> >> >> Suggested-Configuration-for-Connection-Pools-using-ClearDb>
> >> >> >> > ):
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > But even after applying this configuration I see in the ClearDB
> >> >> >> management
> >> >> >> > console that idle connections are closed only after 90 seconds
> and
> >> >> >> > not
> >> >> >> after
> >> >> >> > 60 seconds (1 minute) as it's specified with
> >> >> >> > "idle-timeout-minutes"
> >> >> >> > parameter.
> >> >> >> >
> >> >> >> > So, have anybody of you faced similar situation? Or maybe you
> have
> >> >> >> > some
> >> >> >> > ideas why these idle connections are not being closed.
> >> >> >> >
> >> >> >> > Thanks.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > View this message in context: http://keycloak-user.88327.x6.
> >> >> >> nabble.com/Idle-connections-are-not-closed-tp3948.html
> >> >> >> > Sent from the keycloak-user mailing list archive at Nabble.com.
> >> >> >> > _______________________________________________
> >> >> >> > keycloak-user mailing list
> >> >> >> > keycloak-user at lists.jboss.org
> >> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> keycloak-user mailing list
> >> >> >> keycloak-user at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > ? ?????????,
> >> >> > ????????? ??????
> >> >> > _______________________________________________
> >> >> > keycloak-user mailing list
> >> >> > keycloak-user at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> --Hynek
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > ? ?????????,
> >> > ????????? ??????
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
> >
> >
> > --
> > ? ?????????,
> > ????????? ??????
>
>
>
> --
>
> --Hynek
>



-- 
? ?????????,
????????? ??????

From jannik.huels at googlemail.com  Fri Jul 14 09:01:05 2017
From: jannik.huels at googlemail.com (=?utf-8?Q?Jannik_H=C3=BCls?=)
Date: Fri, 14 Jul 2017 15:01:05 +0200
Subject: [keycloak-user] Authentication Flow
Message-ID: <18b0561f-15ca-4962-b4e6-182d5ad9d390@Spark>

Hi,

I have implemented a async authenticator like in?https://github.com/stianst/authenticator-example. (Btw: Thanks for that)

I am now wondering if it is possible to implement a RealmResourceProvider that can mark the BankIDFlow as unsuccessful in a backchannel call. Such that the user does not have to enter the username but only has to redo the post when he again wants to open a protected resource.

Thanks!
Jannik

From Kevin.Cuijpers at mips.be  Fri Jul 14 11:00:46 2017
From: Kevin.Cuijpers at mips.be (Kevin Cuijpers)
Date: Fri, 14 Jul 2017 15:00:46 +0000
Subject: [keycloak-user] Unable to make quickstart app-profile-saml-jee-jsp
	work
Message-ID: <9d2f429902474d2aae407e5e19b6be93@srv-webmail.mips.be>

Hello,

I am trying to see if we can use KeyCloak to secure and make our current API's available through SAML.
We are running our application on Tomcat 8.5.8
I downloaded keycloak-3.2.0.Final and saml-tomcat8-adapter.
I was following the instructions described in quickstarts app-profile-saml-jee-jsp and applying it to our application.
However, I am not able to select Client Protocol: saml. I can only choose openid-connect.
In Identity Providers I tried to configure my own saml Identity Provider and use that in my setup but when I try to access the secured resource I get following error:
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No login page was defined for FORM authentication in context

I found a post of an older similar issue and it said it should be fixed in a new version:
http://lists.jboss.org/pipermail/keycloak-user/2016-November/008383.html

It points to https://issues.jboss.org/browse/KEYCLOAK-3669?filter=-2 but I can't find the issue.

The following things I have been trying to figure out but without success. Could you please help me clarify following questions or point me in the right direction to make it work?

-          When I create a new realm I can only select Endpoints: OpenID Endpoint Configuration. I was expecting to also be able to select SAML 2.0 here or saml as described in the example.

-          When I add Client, I only have Client Protocol openid-connect. If I want to add a new Identity Provider I need to add Single Sign-On Service URL: The url that must be used to send authentication requests (SAML AuthnRequest). I don't want to implement the Identity Provider. I was looking for a way to retrieve valid SAML tickets and specify what keys of the user are sent in that ticket. I would like this to be sent to a url inside my web app.

>From the description of app-profile-saml-jee-jsp I thought this is what I should be able to do but can't seem to figure it out.

Best regards,

Kevin

From dennishonders at gmail.com  Fri Jul 14 12:27:51 2017
From: dennishonders at gmail.com (Dennis H)
Date: Fri, 14 Jul 2017 18:27:51 +0200
Subject: [keycloak-user] Java Spring Boot: possible inject user info?
Message-ID: <CALfiJ8bV3BJ7V=SvnoSvXc6ws+iuOGxXT1ibeZXUYjkK-LrxQA@mail.gmail.com>

Does the keycloak java spring boot library provide a service, that contains
the user info, which can be injected in a class?

If not, how to retrieve the user info from the request?

I can't find this in the docs.

From Dana.Danet at Evisions.com  Fri Jul 14 17:09:34 2017
From: Dana.Danet at Evisions.com (Dana Danet)
Date: Fri, 14 Jul 2017 21:09:34 +0000
Subject: [keycloak-user] Java Spring Boot: possible inject user info?
In-Reply-To: <CALfiJ8bV3BJ7V=SvnoSvXc6ws+iuOGxXT1ibeZXUYjkK-LrxQA@mail.gmail.com>
References: <CALfiJ8bV3BJ7V=SvnoSvXc6ws+iuOGxXT1ibeZXUYjkK-LrxQA@mail.gmail.com>
Message-ID: <3EF594AC-A96D-4298-BB27-729E2C749302@evisions.com>

Dennis,

Add a Security Config class.  Then auto wire your accessToken where needed.


@Configuration
public class SecurityConfig {

    @Bean
    @Scope(scopeName = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
    public AccessToken getAccessToken() {

        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        return ((KeycloakPrincipal) request.getUserPrincipal()).getKeycloakSecurityContext().getToken();
    }

}

-dana


On Jul 14, 2017, at 9:27 AM, Dennis H <dennishonders at gmail.com<mailto:dennishonders at gmail.com>> wrote:

Does the keycloak java spring boot library provide a service, that contains
the user info, which can be injected in a class?

If not, how to retrieve the user info from the request?

I can't find this in the docs.
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user


From sagarahire at arvindinternet.com  Sat Jul 15 04:04:19 2017
From: sagarahire at arvindinternet.com (Sagar Ahire)
Date: Sat, 15 Jul 2017 13:34:19 +0530
Subject: [keycloak-user] Unable To Add Server to Existing Keycloak Cluster
Message-ID: <CAFcYf8-HaTrhwBCBYGuTVY=1Mx91c4+DBrE1STYN1bK1mutRfA@mail.gmail.com>

Hello,

I'm trying to add/start one more server to our existing keycloak cluster of
two nodes. I took the AMI snapshot of current running server and tried to
launch new keycloak service keeping the same configuration but getting the
following errors.

I'm using
*Keycloak version: 2.4.0*
*Wildfly version: 2.0.10*

*******Errors*******
*07:39:08,605 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool
-- 58) MSC000001: Failed to start service
jboss.infinispan.keycloak.sessions: org.jboss.msc.service.StartException in
service jboss.infinispan.keycloak.sessions:
org.infinispan.commons.CacheException: Unable to invoke method public void
org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
throws java.lang.Exception on object of type StateTransferManagerImpl*
* at
org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)*
* at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)*
* at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)*
* at java.lang.Thread.run(Thread.java:745)*
* at org.jboss.threads.JBossThread.run(JBossThread.java:320)*
*Caused by: org.infinispan.commons.CacheException: Unable to invoke method
public void
org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
throws java.lang.Exception on object of type StateTransferManagerImpl*

---------------------------------------------------------------------------------------------------------------

*07:39:08,615 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address:
([*
*    ("subsystem" => "infinispan"),*
*    ("cache-container" => "keycloak"),*
*    ("distributed-cache" => "sessions")*
*]) - failure description: {"WFLYCTL0080: Failed services" =>
{"jboss.infinispan.keycloak.sessions" =>
"org.jboss.msc.service.StartException in service
jboss.infinispan.keycloak.sessions: org.infinispan.commons.CacheException:
Unable to invoke method public void
org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
throws java.lang.Exception on object of type StateTransferManagerImpl*
*    Caused by: org.infinispan.commons.CacheException: Unable to invoke
method public void
org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
throws java.lang.Exception on object of type StateTransferManagerImpl*

*    Caused by: org.infinispan.commons.CacheException: Initial state
transfer timed out for cache sessions on
ip-172-31-23-136.ap-southeast-1.compute.internal"}} *
*regards,*
**************end*************


*Any help is greatly appreciated.*



 -Sagar

From Nicolas.Geadah at vec.virginia.gov  Sun Jul 16 22:02:45 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Mon, 17 Jul 2017 02:02:45 +0000
Subject: [keycloak-user] Language selection to client
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230AC109@COVMSGCES-MBX13>

I configured my theme to support Spanish and English - works like a charm.  Now how can I send the selected language to one of my client applications, so that the user does not have to make the language choice again when reaching the destination application?  Is there something set on the KeycloakPrincipal that would indicate what language was selected?

From rody.van.der.vliet at accenture.com  Mon Jul 17 05:52:39 2017
From: rody.van.der.vliet at accenture.com (van der Vliet, Rody)
Date: Mon, 17 Jul 2017 09:52:39 +0000
Subject: [keycloak-user] Keycloak error 3.2.0 migration
Message-ID: <CY4P114MB0117787034F1F2FB50ACB1E18FA00@CY4P114MB0117.NAMP114.PROD.OUTLOOK.COM>

Hi All,

Within our project we are migrating our Keycloak version from 2.5.4 to 3.2.0 Final.
However we are getting below error when trying to run Keycloak 3.2.0 Final on our Test Environment.
(We also tried to migrate from 2.5.4 to 3.0.0. That was successful. But when tried to migrate 3.0.0 to 3.2.0, again same error.)

It seems the migration scripts wants to include some DB records but is violating a unique constraint.
Is there anyone who has encountered the same problem or has an idea how we can resolve this issue?
Any help would be greatly appreciated.

Regards,

Rody van der Vliet
rody.van.der.vliet at accenture.com

ERROR:

2017-07-17 11:33:05,475 DEBUG [org.hibernate.engine.spi.ActionQueue] (ServerService Thread Pool -- 57) Changes must be flushed to space: KEYCLOAK_ROLE
2017-07-17 11:33:05,475 DEBUG [org.hibernate.SQL] (ServerService Thread Pool -- 57)
    insert
    into
        KEYCLOAK_ROLE
        (CLIENT, CLIENT_REALM_CONSTRAINT, CLIENT_ROLE, DESCRIPTION, NAME, REALM, REALM_ID, SCOPE_PARAM_REQUIRED, ID)
    values
        (?, ?, ?, ?, ?, ?, ?, ?, ?)
2017-07-17 11:33:05,506 DEBUG [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) could not execute statement [n/a]: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (XYZ_KEYCLOAK.UK_J3RWUVD56ONTGSUHOGM184WW2-2) violated

            at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:445)
            at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
            at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:879)
            at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:450)
            at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)
            at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
            at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
            at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1044)
            at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1329)
            at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)
            at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3665)
            at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1352)
            at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
            at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
            at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
            at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
            at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
            at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
            at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
            at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
            at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
            at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:50)
            at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1251)
            at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1319)
            at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87)
            at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606)
            at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483)
            at org.keycloak.models.jpa.JpaRealmProvider.getClientRole(JpaRealmProvider.java:252)
            at org.keycloak.models.cache.infinispan.RealmCacheSession.getClientRole(RealmCacheSession.java:743)
            at org.keycloak.models.cache.infinispan.ClientAdapter.getRole(ClientAdapter.java:572)
            at org.keycloak.migration.migrators.MigrateTo3_2_0.addRoles(MigrateTo3_2_0.java:66)
            at org.keycloak.migration.migrators.MigrateTo3_2_0.migrate(MigrateTo3_2_0.java:50)
            at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:84)
            at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:243)
            at org.keycloak.services.resources.KeycloakApplication.migrateAndBootstrap(KeycloakApplication.java:184)
            at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:143)
            at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
            at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
            at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
            at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
            at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
            at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
            at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
            at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
            at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
            at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
            at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
            at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
            at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
            at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
            at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
            at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
            at java.util.concurrent.FutureTask.run(FutureTask.java:266)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
            at java.lang.Thread.run(Thread.java:745)
            at org.jboss.threads.JBossThread.run(JBossThread.java:320)

2017-07-17 11:33:05,506 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) SQL Error: 1, SQLState: 23000
2017-07-17 11:33:05,506 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) ORA-00001: unique constraint (XYZ_KEYCLOAK.UK_J3RWUVD56ONTGSUHOGM184WW2-2) violated

==================================================
The information transmitted via this e-mail is intended only for the person or
entity to which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon this information by persons or entities
other than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from any computer

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com

From manuel.holtgrewe at bihealth.de  Mon Jul 17 08:42:39 2017
From: manuel.holtgrewe at bihealth.de (Holtgrewe, Manuel)
Date: Mon, 17 Jul 2017 12:42:39 +0000
Subject: [keycloak-user] "Failed to introspect token" problem
Message-ID: <CC941ED861F3AA469B6D50EE76C57483D378BDE6@s-mx14-bih01.charite.de>

Hi, I am getting a problem with token introspection.

My setup is Keycloak 3.2.0.Final in combination with Apache+mod_auth_openidc. I configured mod_auth_openidc as an OAuth 2 resource server (for what it's worth, reproduced at the bottom).

I would be very grateful if someone could have a look and point me to where to continue working on resolving the problem. The problem

Thanks,
Manuel

I have a client "igv-files" setup and I can manually log me in for this OAuth client:

$ curl -X POST -d client_id=igv-files -d client_secret=030d8719-5479-4400-a8e9-185abac13cb1 -d 'username=ME at EXAMPLE.COM' -d 'password=MYPASS' -dgrant_type=password https://HOST/auth/realms/REALM/protocol/openid-connect/token

Result

{"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiIzYWJiNGQ4OC1jYjI0LTRlZDktODIwZS1kMTE5ODg0NzhjZTYiLCJleHAiOjE1MDAyOTQ5MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IkJlYXJlciIsImF6cCI6Imlndi1maWxlcyIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImFjZTYwM2ZiLWQ3MTUtNDQxMS1hNTZjLTJjZTY5YWM2NGJiMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9jdWJpLWlndi1maWxlcy5iaWhlYWx0aC5vcmciXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6Ik1hbnVlbCBIb2x0Z3Jld2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJob2x0Z3Jld2UsIG1hbnVlbCIsImdpdmVuX25hbWUiOiJNYW51ZWwiLCJmYW1pbHlfbmFtZSI6IkhvbHRncmV3ZSIsImVtYWlsIjoibWFudWVsLmhvbHRncmV3ZUBiaWhlYWx0aC5kZSJ9.a6XdNMW8uEefYKq7AhPg7_LAIIkKrZ3dOKi0pulOSd3W94mV3M0uqT10JbMrxWkGmZZHPaMDLx8U0U6fwCVTsmRsOH5IyKVxfAoSAMYoaTKHZCHrWENG2EdMqy39M_7iqkf2dZasav5EAuJPgjCi6vYpfRCWHYM_5U90uJu2Hi395u7Ro0xX9jfBytf1wt-ydDyG58L6HB8hqiLzQQTBep4soYz9-NzSTMOyljnYX8wtGhYUurYtTS2OGpf3Zd5vp54v6NRZmRH7vi3PSn2kEUEmGjBt-v-r3JNB8-IhMVnW6jyLKFlzJjml3NmZ2MzZsFwYXXlRbNODtVDuDuGRFg","expires_in":300,"refresh_expires_in":1800,"refresh_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiI5ZWQ4NDJlNS1mMWEyLTQ0MmUtYTM2Ni0xZThkZmRkZTI4Y2UiLCJleHAiOjE1MDAyOTY0MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJpZ3YtZmlsZXMiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJhY2U2MDNmYi1kNzE1LTQ0MTEtYTU2Yy0yY2U2OWFjNjRiYjAiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsidW1hX2F1dGhvcml6YXRpb24iXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19fQ.M0FZU-RkfjWgGbShfXC8CFfqTCG5HG4weEGPHAMovAVLqgJj8cQjodkzhQAPUQTjjyEZeeShTnMtMcbbciJ-EBwCsDonc0eDELzGO3xKuZU8yURhKB6N2yheuhuX2eU0ChMGkURhD4Iju5umbYe8sdpAzte1S9iW9dxRl8Q4fw-gLfZ5oeD5dExQClBdJUWYire8T2wwvD68OKviiZbRfh1gCM6EkhTR121L8SOvA5k22E-gSrjBa6zk5OeiTqaaNgBt_eBOWEtKZvbQZVIEVX9-5TOViIXVDGLG30Wa7a0-Zk6bsAMLt2jV4FQqt_HPIegMAD3btPAN3qZ0-0QkJg","token_type":"bearer","not-before-policy":1500291033,"session_state":"ace603fb-d715-4411-a56c-2ce69ac64bb0"}

Then, I'm trying to access a resource in Apache (reproduced below, not so important, I think) from with I get a 401 Unauthorized reply.

The mod_auth_openidc tries to introspect the token and this is where things appear to fail.

Here is the log entry in my apache log, showing that it POSTs to the SSO host and gets back a failure.

[Mon Jul 17 14:38:56.287833 2017] [auth_openidc:debug] [pid 26627:tid 140542922938112] src/oauth.c(138): [client 172.16.128.8:43630] oidc_oauth_get_bearer_token: bearer token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiIzYWJiNGQ4OC1jYjI0LTRlZDktODIwZS1kMTE5ODg0NzhjZTYiLCJleHAiOjE1MDAyOTQ5MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IkJlYXJlciIsImF6cCI6Imlndi1maWxlcyIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImFjZTYwM2ZiLWQ3MTUtNDQxMS1hNTZjLTJjZTY5YWM2NGJiMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9jdWJpLWlndi1maWxlcy5iaWhlYWx0aC5vcmciXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6Ik1hbnVlbCBIb2x0Z3Jld2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJob2x0Z3Jld2UsIG1hbnVlbCIsImdpdmVuX25hbWUiOiJNYW51ZWwiLCJmYW1pbHlfbmFtZSI6IkhvbHRncmV3ZSIsImVtYWlsIjoibWFudWVsLmhvbHRncmV3ZUBiaWhlYWx0aC5kZSJ9.a6XdNMW8uEefYKq7AhPg7_LAIIkKrZ3dOKi0pulOSd3W94mV3M0uqT10JbMrxWkGmZZHPaMDLx8U0U6fwCVTsmRsOH5IyKVxfAoSAMYoaTKHZCHrWENG2EdMqy39M_7iqkf2dZasav5EAuJPgjCi6vYpfRCWHYM_5U90uJu2Hi395u7Ro0xX9jfBytf1wt-ydDyG58L6HB8hqiLzQQTBep4soYz9-NzSTMOyljnYX8wtGhYUurYtTS2OGpf3Zd5vp54v6NRZmRH7vi3PSn2kEUEmGjBt-v-r3JNB8-IhMVnW6jyLKFlzJjml3NmZ2MzZsFwYXXlRbNODtVDuDuGRFg
[Mon Jul 17 14:38:56.287980 2017] [auth_openidc:debug] [pid 26627:tid 140542922938112] src/cache/shm.c(156): [client 172.16.128.8:43630] oidc_cache_shm_get: enter, section="access_token", key="eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiIzYWJiNGQ4OC1jYjI0LTRlZDktODIwZS1kMTE5ODg0NzhjZTYiLCJleHAiOjE1MDAyOTQ5MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IkJlYXJlciIsImF6cCI6Imlndi1maWxlcyIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImFjZTYwM2ZiLWQ3MTUtNDQxMS1hNTZjLTJjZTY5YWM2NGJiMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9jdWJpLWlndi1maWxlcy5iaWhlYWx0aC5vcmciXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6Ik1hbnVlbCBIb2x0Z3Jld2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJob2x0Z3Jld2UsIG1hbnVlbCIsImdpdmVuX25hbWUiOiJNYW51ZWwiLCJmYW1pbHlfbmFtZSI6IkhvbHRncmV3ZSIsImVtYWlsIjoibWFudWVsLmhvbHRncmV3ZUBiaWhlYWx0aC5kZSJ9.a6XdNMW8uEefYKq7AhPg7_LAIIkKrZ3dOKi0pulOSd3W94mV3M0uqT10JbMrxWkGmZZHPaMDLx8U0U6fwCVTsmRsOH5IyKVxfAoSAMYoaTKHZCHrWENG2EdMqy39M_7iqkf2dZasav5EAuJPgjCi6vYpfRCWHYM_5U90uJu2Hi395u7Ro0xX9jfBytf1wt-ydDyG58L6HB8hqiLzQQTBep4soYz9-NzSTMOyljnYX8wtGhYUurYtTS2OGpf3Zd5vp54v6NRZmRH7vi3PSn2kEUEmGjBt-v-r3JNB8-IhMVnW6jyLKFlzJjml3NmZ2MzZsFwYXXlRbNODtVDuDuGRFg"
[Mon Jul 17 14:38:56.290061 2017] [auth_openidc:debug] [pid 26627:tid 140542922938112] src/util.c(600): [client 172.16.128.8:43630] oidc_util_http_post_form: post data="token_type_hint=requesting_party_token&token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiIzYWJiNGQ4OC1jYjI0LTRlZDktODIwZS1kMTE5ODg0NzhjZTYiLCJleHAiOjE1MDAyOTQ5MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IkJlYXJlciIsImF6cCI6Imlndi1maWxlcyIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImFjZTYwM2ZiLWQ3MTUtNDQxMS1hNTZjLTJjZTY5YWM2NGJiMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9jdWJpLWlndi1maWxlcy5iaWhlYWx0aC5vcmciXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6Ik1hbnVlbCBIb2x0Z3Jld2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJob2x0Z3Jld2UsIG1hbnVlbCIsImdpdmVuX25hbWUiOiJNYW51ZWwiLCJmYW1pbHlfbmFtZSI6IkhvbHRncmV3ZSIsImVtYWlsIjoibWFudWVsLmhvbHRncmV3ZUBiaWhlYWx0aC5kZSJ9.a6XdNMW8uEefYKq7AhPg7_LAIIkKrZ3dOKi0pulOSd3W94mV3M0uqT10JbMrxWkGmZZHPaMDLx8U0U6fwCVTsmRsOH5IyKVxfAoSAMYoaTKHZCHrWENG2EdMqy39M_7iqkf2dZasav5EAuJPgjCi6vYpfRCWHYM_5U90uJu2Hi395u7Ro0xX9jfBytf1wt-ydDyG58L6HB8hqiLzQQTBep4soYz9-NzSTMOyljnYX8wtGhYUurYtTS2OGpf3Zd5vp54v6NRZmRH7vi3PSn2kEUEmGjBt-v-r3JNB8-IhMVnW6jyLKFlzJjml3NmZ2MzZsFwYXXlRbNODtVDuDuGRFg"
[Mon Jul 17 14:38:56.290182 2017] [auth_openidc:debug] [pid 26627:tid 140542922938112] src/util.c(427): [client 172.16.128.8:43630] oidc_util_http_call: url=https://SSOHOST.org/auth/realms/REALM/protocol/openid-connect/token/introspect, data=token_type_hint=requesting_party_token&token=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiIzYWJiNGQ4OC1jYjI0LTRlZDktODIwZS1kMTE5ODg0NzhjZTYiLCJleHAiOjE1MDAyOTQ5MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IkJlYXJlciIsImF6cCI6Imlndi1maWxlcyIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImFjZTYwM2ZiLWQ3MTUtNDQxMS1hNTZjLTJjZTY5YWM2NGJiMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9jdWJpLWlndi1maWxlcy5iaWhlYWx0aC5vcmciXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6Ik1hbnVlbCBIb2x0Z3Jld2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJob2x0Z3Jld2UsIG1hbnVlbCIsImdpdmVuX25hbWUiOiJNYW51ZWwiLCJmYW1pbHlfbmFtZSI6IkhvbHRncmV3ZSIsImVtYWlsIjoibWFudWVsLmhvbHRncmV3ZUBiaWhlYWx0aC5kZSJ9.a6XdNMW8uEefYKq7AhPg7_LAIIkKrZ3dOKi0pulOSd3W94mV3M0uqT10JbMrxWkGmZZHPaMDLx8U0U6fwCVTsmRsOH5IyKVxfAoSAMYoaTKHZCHrWENG2EdMqy39M_7iqkf2dZasav5EAuJPgjCi6vYpfRCWHYM_5U90uJu2Hi395u7Ro0xX9jfBytf1wt-ydDyG58L6HB8hqiLzQQTBep4soYz9-NzSTMOyljnYX8wtGhYUurYtTS2OGpf3Zd5vp54v6NRZmRH7vi3PSn2kEUEmGjBt-v-r3JNB8-IhMVnW6jyLKFlzJjml3NmZ2MzZsFwYXXlRbNODtVDuDuGRFg, content_type=application/x-www-form-urlencoded, basic_auth=igv-files:030d8719-5479-4400-a8e9-185abac13cb1, bearer_token=(null), ssl_validate_server=1
[Mon Jul 17 14:38:56.373267 2017] [auth_openidc:debug] [pid 26627:tid 140542922938112] src/util.c(551): [client 172.16.128.8:43630] oidc_util_http_call: response={"error":"invalid_request","error_description":"Failed to introspect token."}
[Mon Jul 17 14:38:56.374242 2017] [auth_openidc:error] [pid 26627:tid 140542922938112] [client 172.16.128.8:43630] oidc_util_json_string_print: oidc_util_check_json_error: response contained an "error" entry with value: ""invalid_request""
[Mon Jul 17 14:38:56.374409 2017] [auth_openidc:error] [pid 26627:tid 140542922938112] [client 172.16.128.8:43630] oidc_util_json_string_print: oidc_util_check_json_error: response contained an "error_description" entry with value: ""Failed to introspect token.""

And here is the log entry of the wildfly/keycloak showing the failure:

2017-07-17 14:40:43,769 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-25) new JtaTransactionWrapper
2017-07-17 14:40:43,780 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-25) was existing? false
2017-07-17 14:40:43,781 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-25) RESTEASY002315: PathInfo: /realms/REALM/protocol/openid-connect/token/introspect
2017-07-17 14:40:43,788 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-25) AUTHENTICATE CLIENT
2017-07-17 14:40:43,795 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (default task-25) client authenticator: client-secret
2017-07-17 14:40:43,797 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (default task-25) client authenticator SUCCESS: client-secret
2017-07-17 14:40:43,797 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (default task-25) Client igv-files authenticated by client-secret
2017-07-17 14:40:43,797 DEBUG [org.keycloak.authorization.protection.introspect.RPTIntrospectionProvider] (default task-25) Introspecting requesting party token
2017-07-17 14:40:43,800 WARN  [org.keycloak.events] (default task-25) type=INTROSPECT_TOKEN_ERROR, realmId=bihealth, clientId=igv-files, userId=null, ipAddress=172.16.96.165, error=invalid_request, detail='Failed to introspect token.', client_auth_method=client-secret
2017-07-17 14:40:43,802 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-25) JtaTransactionWrapper  commit
2017-07-17 14:40:43,811 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (default task-25) JtaTransactionWrapper end


## mod_auth_openidc configuration

OIDCOAuthClientID igv-files
OIDCOAuthClientSecret 030d8719-5479-4400-a8e9-185abac13cb1
OIDCOAuthIntrospectionEndpoint https://SSOHOST.org/auth/realms/REALM/protocol/openid-connect/token/introspect
OIDCOAuthIntrospectionEndpointAuth client_secret_basic
OIDCOAuthIntrospectionEndpointMethod POST
OIDCOAuthIntrospectionEndpointParams token_type_hint=requesting_party_token
OIDCOAuthIntrospectionTokenParamName token

<Location />
  Authtype oauth20
  Require valid-user
  LogLevel debug
</Location>

# Resource Query for Apache

# curl -I --header "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJsNEhkVVhkdGxSamhta08yVTFld0JyX2hQYlZ6OWVINkQxNXBsVklSUGo4In0.eyJqdGkiOiIzYWJiNGQ4OC1jYjI0LTRlZDktODIwZS1kMTE5ODg0NzhjZTYiLCJleHAiOjE1MDAyOTQ5MjUsIm5iZiI6MCwiaWF0IjoxNTAwMjk0NjI1LCJpc3MiOiJodHRwczovL2N1Ymktc3NvLmJpaGVhbHRoLm9yZy9hdXRoL3JlYWxtcy9iaWhlYWx0aCIsImF1ZCI6Imlndi1maWxlcyIsInN1YiI6IjhkZjczMzllLTFiYWYtNDJhMS05ZjA3LWQzYzZjNjQ3NjQ4MCIsInR5cCI6IkJlYXJlciIsImF6cCI6Imlndi1maWxlcyIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImFjZTYwM2ZiLWQ3MTUtNDQxMS1hNTZjLTJjZTY5YWM2NGJiMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9jdWJpLWlndi1maWxlcy5iaWhlYWx0aC5vcmciXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6Ik1hbnVlbCBIb2x0Z3Jld2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJob2x0Z3Jld2UsIG1hbnVlbCIsImdpdmVuX25hbWUiOiJNYW51ZWwiLCJmYW1pbHlfbmFtZSI6IkhvbHRncmV3ZSIsImVtYWlsIjoibWFudWVsLmhvbHRncmV3ZUBiaWhlYWx0aC5kZSJ9.a6XdNMW8uEefYKq7AhPg7_LAIIkKrZ3dOKi0pulOSd3W94mV3M0uqT10JbMrxWkGmZZHPaMDLx8U0U6fwCVTsmRsOH5IyKVxfAoSAMYoaTKHZCHrWENG2EdMqy39M_7iqkf2dZasav5EAuJPgjCi6vYpfRCWHYM_5U90uJu2Hi395u7Ro0xX9jfBytf1wt-ydDyG58L6HB8hqiLzQQTBep4soYz9-NzSTMOyljnYX8wtGhYUurYtTS2OGpf3Zd5vp54v6NRZmRH7vi3PSn2kEUEmGjBt-v-r3JNB8-IhMVnW6jyLKFlzJjml3NmZ2MzZsFwYXXlRbNODtVDuDuGRFg"  https://FILESHOST/PATH



From bburke at redhat.com  Mon Jul 17 14:24:18 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 17 Jul 2017 14:24:18 -0400
Subject: [keycloak-user] Keycloak error 3.2.0 migration
In-Reply-To: <CY4P114MB0117787034F1F2FB50ACB1E18FA00@CY4P114MB0117.NAMP114.PROD.OUTLOOK.COM>
References: <CY4P114MB0117787034F1F2FB50ACB1E18FA00@CY4P114MB0117.NAMP114.PROD.OUTLOOK.COM>
Message-ID: <9a3e49e5-57ae-ef82-59ad-0bad890603b5@redhat.com>

I'll try to reproduce. Not sure why adding a role would be an error as 
that's what the code is doing.  Did you add roles to "realm-management" 
client?  Specifically "query-clients", "query-users", "query-realms" or 
"query-groups"?


On 7/17/17 5:52 AM, van der Vliet, Rody wrote:
> Hi All,
>
> Within our project we are migrating our Keycloak version from 2.5.4 to 3.2.0 Final.
> However we are getting below error when trying to run Keycloak 3.2.0 Final on our Test Environment.
> (We also tried to migrate from 2.5.4 to 3.0.0. That was successful. But when tried to migrate 3.0.0 to 3.2.0, again same error.)
>
> It seems the migration scripts wants to include some DB records but is violating a unique constraint.
> Is there anyone who has encountered the same problem or has an idea how we can resolve this issue?
> Any help would be greatly appreciated.
>
> Regards,
>
> Rody van der Vliet
> rody.van.der.vliet at accenture.com
>
> ERROR:
>
> 2017-07-17 11:33:05,475 DEBUG [org.hibernate.engine.spi.ActionQueue] (ServerService Thread Pool -- 57) Changes must be flushed to space: KEYCLOAK_ROLE
> 2017-07-17 11:33:05,475 DEBUG [org.hibernate.SQL] (ServerService Thread Pool -- 57)
>      insert
>      into
>          KEYCLOAK_ROLE
>          (CLIENT, CLIENT_REALM_CONSTRAINT, CLIENT_ROLE, DESCRIPTION, NAME, REALM, REALM_ID, SCOPE_PARAM_REQUIRED, ID)
>      values
>          (?, ?, ?, ?, ?, ?, ?, ?, ?)
> 2017-07-17 11:33:05,506 DEBUG [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) could not execute statement [n/a]: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (XYZ_KEYCLOAK.UK_J3RWUVD56ONTGSUHOGM184WW2-2) violated
>
>              at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:445)
>              at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
>              at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:879)
>              at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:450)
>              at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)
>              at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
>              at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
>              at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1044)
>              at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1329)
>              at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)
>              at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3665)
>              at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1352)
>              at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
>              at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>              at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
>              at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
>              at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
>              at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
>              at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
>              at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
>              at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
>              at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:50)
>              at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1251)
>              at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1319)
>              at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87)
>              at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606)
>              at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483)
>              at org.keycloak.models.jpa.JpaRealmProvider.getClientRole(JpaRealmProvider.java:252)
>              at org.keycloak.models.cache.infinispan.RealmCacheSession.getClientRole(RealmCacheSession.java:743)
>              at org.keycloak.models.cache.infinispan.ClientAdapter.getRole(ClientAdapter.java:572)
>              at org.keycloak.migration.migrators.MigrateTo3_2_0.addRoles(MigrateTo3_2_0.java:66)
>              at org.keycloak.migration.migrators.MigrateTo3_2_0.migrate(MigrateTo3_2_0.java:50)
>              at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:84)
>              at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:243)
>              at org.keycloak.services.resources.KeycloakApplication.migrateAndBootstrap(KeycloakApplication.java:184)
>              at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:143)
>              at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>              at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
>              at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>              at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>              at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>              at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>              at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>              at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>              at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>              at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>              at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>              at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>              at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>              at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>              at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>              at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>              at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>              at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>              at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>              at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>              at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>              at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>              at java.lang.Thread.run(Thread.java:745)
>              at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>
> 2017-07-17 11:33:05,506 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) SQL Error: 1, SQLState: 23000
> 2017-07-17 11:33:05,506 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) ORA-00001: unique constraint (XYZ_KEYCLOAK.UK_J3RWUVD56ONTGSUHOGM184WW2-2) violated
>
> ==================================================
> The information transmitted via this e-mail is intended only for the person or
> entity to which it is addressed and may contain confidential and/or privileged
> material.  Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon this information by persons or entities
> other than the intended recipient is prohibited. If you received this in error,
> please contact the sender and delete the material from any computer
>
> ________________________________
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
> ______________________________________________________________________________________
>
> www.accenture.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From bburke at redhat.com  Mon Jul 17 18:09:34 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 17 Jul 2017 18:09:34 -0400
Subject: [keycloak-user] Keycloak error 3.2.0 migration
In-Reply-To: <9a3e49e5-57ae-ef82-59ad-0bad890603b5@redhat.com>
References: <CY4P114MB0117787034F1F2FB50ACB1E18FA00@CY4P114MB0117.NAMP114.PROD.OUTLOOK.COM>
	<9a3e49e5-57ae-ef82-59ad-0bad890603b5@redhat.com>
Message-ID: <bcf1a5ae-959f-ea68-8e05-9dd5cd9c939d@redhat.com>

Ok, I tried this with out-of-the-box Keycloak 3.0 migrating to 3.2.  It 
works fine for me.  So, see below?


On 7/17/17 2:24 PM, Bill Burke wrote:
> I'll try to reproduce. Not sure why adding a role would be an error as
> that's what the code is doing.  Did you add roles to "realm-management"
> client?  Specifically "query-clients", "query-users", "query-realms" or
> "query-groups"?
>
>
> On 7/17/17 5:52 AM, van der Vliet, Rody wrote:
>> Hi All,
>>
>> Within our project we are migrating our Keycloak version from 2.5.4 to 3.2.0 Final.
>> However we are getting below error when trying to run Keycloak 3.2.0 Final on our Test Environment.
>> (We also tried to migrate from 2.5.4 to 3.0.0. That was successful. But when tried to migrate 3.0.0 to 3.2.0, again same error.)
>>
>> It seems the migration scripts wants to include some DB records but is violating a unique constraint.
>> Is there anyone who has encountered the same problem or has an idea how we can resolve this issue?
>> Any help would be greatly appreciated.
>>
>> Regards,
>>
>> Rody van der Vliet
>> rody.van.der.vliet at accenture.com
>>
>> ERROR:
>>
>> 2017-07-17 11:33:05,475 DEBUG [org.hibernate.engine.spi.ActionQueue] (ServerService Thread Pool -- 57) Changes must be flushed to space: KEYCLOAK_ROLE
>> 2017-07-17 11:33:05,475 DEBUG [org.hibernate.SQL] (ServerService Thread Pool -- 57)
>>       insert
>>       into
>>           KEYCLOAK_ROLE
>>           (CLIENT, CLIENT_REALM_CONSTRAINT, CLIENT_ROLE, DESCRIPTION, NAME, REALM, REALM_ID, SCOPE_PARAM_REQUIRED, ID)
>>       values
>>           (?, ?, ?, ?, ?, ?, ?, ?, ?)
>> 2017-07-17 11:33:05,506 DEBUG [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) could not execute statement [n/a]: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (XYZ_KEYCLOAK.UK_J3RWUVD56ONTGSUHOGM184WW2-2) violated
>>
>>               at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:445)
>>               at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
>>               at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:879)
>>               at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:450)
>>               at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)
>>               at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
>>               at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
>>               at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1044)
>>               at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1329)
>>               at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)
>>               at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3665)
>>               at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.java:1352)
>>               at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
>>               at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>>               at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
>>               at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
>>               at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
>>               at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
>>               at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
>>               at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
>>               at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
>>               at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:50)
>>               at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1251)
>>               at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1319)
>>               at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87)
>>               at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606)
>>               at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483)
>>               at org.keycloak.models.jpa.JpaRealmProvider.getClientRole(JpaRealmProvider.java:252)
>>               at org.keycloak.models.cache.infinispan.RealmCacheSession.getClientRole(RealmCacheSession.java:743)
>>               at org.keycloak.models.cache.infinispan.ClientAdapter.getRole(ClientAdapter.java:572)
>>               at org.keycloak.migration.migrators.MigrateTo3_2_0.addRoles(MigrateTo3_2_0.java:66)
>>               at org.keycloak.migration.migrators.MigrateTo3_2_0.migrate(MigrateTo3_2_0.java:50)
>>               at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:84)
>>               at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:243)
>>               at org.keycloak.services.resources.KeycloakApplication.migrateAndBootstrap(KeycloakApplication.java:184)
>>               at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:143)
>>               at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
>>               at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
>>               at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>               at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>               at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>               at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>               at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>>               at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>>               at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>>               at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>>               at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>>               at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>               at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>               at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>>               at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>               at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>>               at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>>               at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>>               at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>>               at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>>               at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>               at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>               at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>               at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>               at java.lang.Thread.run(Thread.java:745)
>>               at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>
>> 2017-07-17 11:33:05,506 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) SQL Error: 1, SQLState: 23000
>> 2017-07-17 11:33:05,506 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 57) ORA-00001: unique constraint (XYZ_KEYCLOAK.UK_J3RWUVD56ONTGSUHOGM184WW2-2) violated
>>
>> ==================================================
>> The information transmitted via this e-mail is intended only for the person or
>> entity to which it is addressed and may contain confidential and/or privileged
>> material.  Any review, retransmission, dissemination or other use of, or
>> taking of any action in reliance upon this information by persons or entities
>> other than the intended recipient is prohibited. If you received this in error,
>> please contact the sender and delete the material from any computer
>>
>> ________________________________
>>
>> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
>> ______________________________________________________________________________________
>>
>> www.accenture.com
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From akaya at expedia.com  Mon Jul 17 20:32:02 2017
From: akaya at expedia.com (Sarp Kaya)
Date: Tue, 18 Jul 2017 00:32:02 +0000
Subject: [keycloak-user] Keycloak 3.2.0 issue with PasswordHashProvider SPI
Message-ID: <AD946FFC-4E40-4CA8-B6E3-24970BB6DC14@expedia.com>

Hello,

I know that this is an internal SPI but I believe it?s broken.

I realised that interface has been changed, now it?s giving the iterations directly for the ?encode? method. The problem is it?s always calling encode method with iterations valued ?1 regardless of what you put in the UI. I realised that in keycloak for "Pbkdf2PasswordHashProvider? it?s defaulting to 20000 iterations; but if you want this to be higher or lower, it doesn?t work either (since iterations will always be ?1)

My question is, could you please check this? Also if you don?t support ?internal SPIs? how are we going to use other encryption methods such as bcrypt or scrypt etc?

From ivan at akvo.org  Tue Jul 18 02:58:45 2017
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Tue, 18 Jul 2017 08:58:45 +0200
Subject: [keycloak-user] "Failed to introspect token" problem
In-Reply-To: <CC941ED861F3AA469B6D50EE76C57483D378BDE6@s-mx14-bih01.charite.de>
References: <CC941ED861F3AA469B6D50EE76C57483D378BDE6@s-mx14-bih01.charite.de>
Message-ID: <fb727450-f4aa-0d97-8015-9d545aee9e84@akvo.org>

Hi,

On 07/17/2017 02:42 PM, Holtgrewe, Manuel wrote:
> OIDCOAuthIntrospectionEndpointParams token_type_hint=requesting_party_token

If you're doing a token introspection of an access token the
token_type_hint should be `access_token` as per RFC.

See the documentation:
https://github.com/keycloak/keycloak-documentation/blob/3.2.0.Final/securing_apps/topics/oidc/oidc-generic.adoc#introspection-endpoint

>From the RFC

> The following is a non-normative example request:
>
>     POST /introspect HTTP/1.1
>     Host: server.example.com
>     Accept: application/json
>     Content-Type: application/x-www-form-urlencoded
>     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>
>     token=mF_9.B5f-4.1JqM&token_type_hint=access_token

I have a some sample code in a test case:

https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/test.sh#L32-L39

I hope this helps.

-- 
Iv?n

From manuel.holtgrewe at bihealth.de  Tue Jul 18 03:43:46 2017
From: manuel.holtgrewe at bihealth.de (Holtgrewe, Manuel)
Date: Tue, 18 Jul 2017 07:43:46 +0000
Subject: [keycloak-user] "Failed to introspect token" problem
In-Reply-To: <fb727450-f4aa-0d97-8015-9d545aee9e84@akvo.org>
References: <CC941ED861F3AA469B6D50EE76C57483D378BDE6@s-mx14-bih01.charite.de>,
	<fb727450-f4aa-0d97-8015-9d545aee9e84@akvo.org>
Message-ID: <CC941ED861F3AA469B6D50EE76C57483D378D4BF@s-mx14-bih01.charite.de>

Thanks, that did the trick!

--
Dr. Manuel Holtgrewe
Bioinformatician
Core Unit Bioinformatics ? CUBI
Berlin Institute of Health / Max Delbr?ck Center for Molecular Medicine in the Helmholtz Association / Charit? ? Universit?tsmedizin Berlin

Visiting Address: Invalidenstr. 80, 3rd Floor, Room 03 028, 10117 Berlin
Postal Address: Chariteplatz 1, 10117 Berlin

E-Mail: manuel.holtgrewe at bihealth.de
Phone: +49 30 450 543 607
Fax: +49 30 450 7 543 901
Web: cubi.bihealth.org  www.bihealth.org  www.mdc-berlin.de  www.charite.de

________________________________________
From: keycloak-user-bounces at lists.jboss.org [keycloak-user-bounces at lists.jboss.org] on behalf of Iv?n Perdomo [ivan at akvo.org]
Sent: Tuesday, July 18, 2017 08:58
To: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] "Failed to introspect token" problem

Hi,

On 07/17/2017 02:42 PM, Holtgrewe, Manuel wrote:
> OIDCOAuthIntrospectionEndpointParams token_type_hint=requesting_party_token

If you're doing a token introspection of an access token the
token_type_hint should be `access_token` as per RFC.

See the documentation:
https://github.com/keycloak/keycloak-documentation/blob/3.2.0.Final/securing_apps/topics/oidc/oidc-generic.adoc#introspection-endpoint

>From the RFC

> The following is a non-normative example request:
>
>     POST /introspect HTTP/1.1
>     Host: server.example.com
>     Accept: application/json
>     Content-Type: application/x-www-form-urlencoded
>     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>
>     token=mF_9.B5f-4.1JqM&token_type_hint=access_token

I have a some sample code in a test case:

https://github.com/iperdomo/keycloak-oauth2-instrospection/blob/master/test.sh#L32-L39

I hope this helps.

--
Iv?n
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user


From manuel.holtgrewe at bihealth.de  Tue Jul 18 03:44:08 2017
From: manuel.holtgrewe at bihealth.de (Holtgrewe, Manuel)
Date: Tue, 18 Jul 2017 07:44:08 +0000
Subject: [keycloak-user] Increasing logging for debugging "Internal
 Server Error" response
In-Reply-To: <1930a3f7-121e-dfc8-d108-5d72d685bced@adbglobal.com>
References: <CC941ED861F3AA469B6D50EE76C57483D377BB89@s-mx14-bih01.charite.de>,
	<1930a3f7-121e-dfc8-d108-5d72d685bced@adbglobal.com>
Message-ID: <CC941ED861F3AA469B6D50EE76C57483D378D4D1@s-mx14-bih01.charite.de>

Thanks, that worked!


From mposolda at redhat.com  Tue Jul 18 05:59:07 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Jul 2017 11:59:07 +0200
Subject: [keycloak-user] Unable To Add Server to Existing Keycloak
	Cluster
In-Reply-To: <CAFcYf8-HaTrhwBCBYGuTVY=1Mx91c4+DBrE1STYN1bK1mutRfA@mail.gmail.com>
References: <CAFcYf8-HaTrhwBCBYGuTVY=1Mx91c4+DBrE1STYN1bK1mutRfA@mail.gmail.com>
Message-ID: <4d721dad-497f-9bdd-37b5-7ab05c13baf2@redhat.com>

Hi,

how many sessions (user logins) you have to see this error?

Maybe it helps to disable initial state transfer for the cache 
"sessions" (I think this shouldn't affect the functionality, but we 
didn't yet try this option) or to increase the timeout, which seem to be 
4 minutes by default. See Wildfly/infinispan docs about how to do that.

Marek

On 15/07/17 10:04, Sagar Ahire wrote:
> Hello,
>
> I'm trying to add/start one more server to our existing keycloak cluster of
> two nodes. I took the AMI snapshot of current running server and tried to
> launch new keycloak service keeping the same configuration but getting the
> following errors.
>
> I'm using
> *Keycloak version: 2.4.0*
> *Wildfly version: 2.0.10*
>
> *******Errors*******
> *07:39:08,605 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool
> -- 58) MSC000001: Failed to start service
> jboss.infinispan.keycloak.sessions: org.jboss.msc.service.StartException in
> service jboss.infinispan.keycloak.sessions:
> org.infinispan.commons.CacheException: Unable to invoke method public void
> org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
> throws java.lang.Exception on object of type StateTransferManagerImpl*
> * at
> org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)*
> * at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)*
> * at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)*
> * at java.lang.Thread.run(Thread.java:745)*
> * at org.jboss.threads.JBossThread.run(JBossThread.java:320)*
> *Caused by: org.infinispan.commons.CacheException: Unable to invoke method
> public void
> org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
> throws java.lang.Exception on object of type StateTransferManagerImpl*
>
> ---------------------------------------------------------------------------------------------------------------
>
> *07:39:08,615 ERROR [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address:
> ([*
> *    ("subsystem" => "infinispan"),*
> *    ("cache-container" => "keycloak"),*
> *    ("distributed-cache" => "sessions")*
> *]) - failure description: {"WFLYCTL0080: Failed services" =>
> {"jboss.infinispan.keycloak.sessions" =>
> "org.jboss.msc.service.StartException in service
> jboss.infinispan.keycloak.sessions: org.infinispan.commons.CacheException:
> Unable to invoke method public void
> org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
> throws java.lang.Exception on object of type StateTransferManagerImpl*
> *    Caused by: org.infinispan.commons.CacheException: Unable to invoke
> method public void
> org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete()
> throws java.lang.Exception on object of type StateTransferManagerImpl*
>
> *    Caused by: org.infinispan.commons.CacheException: Initial state
> transfer timed out for cache sessions on
> ip-172-31-23-136.ap-southeast-1.compute.internal"}} *
> *regards,*
> **************end*************
>
>
> *Any help is greatly appreciated.*
>
>
>
>   -Sagar
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Tue Jul 18 06:06:33 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 18 Jul 2017 12:06:33 +0200
Subject: [keycloak-user] Keycloak 3.2.0 issue with PasswordHashProvider
 SPI
In-Reply-To: <AD946FFC-4E40-4CA8-B6E3-24970BB6DC14@expedia.com>
References: <AD946FFC-4E40-4CA8-B6E3-24970BB6DC14@expedia.com>
Message-ID: <f30946ca-9cc4-9768-0859-3dd55699e1e3@redhat.com>

I've tried to reproduce but wasn't able. What I did was:
- Start 3.2.0
- During initial creation of admin user, I can see that it uses 
iterations -1, so it defaults to 27500 iterations, which is the default 
for Pbkdf2Sha256PasswordHashProviderFactory.
- I've manually changed the password policy in admin console and added 
Hash Iterations to be 10000.
- After relogin of admin user, I can see that it uses configured 10000 
iterations. New users are always created with 10000 iterations.

Marek

On 18/07/17 02:32, Sarp Kaya wrote:
> Hello,
>
> I know that this is an internal SPI but I believe it?s broken.
>
> I realised that interface has been changed, now it?s giving the iterations directly for the ?encode? method. The problem is it?s always calling encode method with iterations valued ?1 regardless of what you put in the UI. I realised that in keycloak for "Pbkdf2PasswordHashProvider? it?s defaulting to 20000 iterations; but if you want this to be higher or lower, it doesn?t work either (since iterations will always be ?1)
>
> My question is, could you please check this? Also if you don?t support ?internal SPIs? how are we going to use other encryption methods such as bcrypt or scrypt etc?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From thiago.addevico at gmail.com  Tue Jul 18 13:27:34 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Tue, 18 Jul 2017 14:27:34 -0300
Subject: [keycloak-user] Email verification timeout
Message-ID: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>

Hi,

We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're not
sure is intentional. The e-mail verification time changed from 5 minutes
(User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
Action Lifespan). It seems weird for us because it does not seem
admin-initiated, since it is part of the default user registration process
to verify his or her email. Is this a bug?

Best regards,
Thiago Presa

From Nicolas.Geadah at vec.virginia.gov  Tue Jul 18 15:20:55 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Tue, 18 Jul 2017 19:20:55 +0000
Subject: [keycloak-user] New Event Type
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230B12DB@COVMSGCES-MBX13>

We are in the process of customizing the browser login and self-registration flows. As part of the customization, we will require new "events" to be created for audit purposes.  Is it possible to create new event types that can be retrieved in keycloak's built-in admin console - or is the list of events supported by keycloak a predefined set that cannot be extended?

Thank you!

From smirabito at csh.rit.edu  Tue Jul 18 16:07:06 2017
From: smirabito at csh.rit.edu (Steven Mirabito)
Date: Tue, 18 Jul 2017 20:07:06 +0000
Subject: [keycloak-user] Kerberos auth type displays basic auth prompt under
	Windows
Message-ID: <CAHVh=dbuWYn-vQg5b-jQ=u519hbxq393tnYpQYtwCFsJoyPg-g@mail.gmail.com>

Hey,

I have Keycloak configured to check passwords against an MIT Kerberos
server in my user federation source, and that works fine. I then set the
Kerberos authentication type to "alternative" - most of our users will be
coming in from personal devices where they'll just log in via the form, but
we do have a shared machine where this would be nice to have. However, I
started receiving complaints that when this option is enabled, any browser
under Windows will show a basic auth dialog which the user has to cancel
out of to reach the login page (other platforms show a blank "Kerberos
Unsupported" page and then redirect to the normal login page without a
dialog). To make matters worse, I can't seem to turn the option off now -
switching the Kerberos auth type to "disabled" will work for a little bit,
but after a short period of time it will turn itself back on and users will
start to see the basic auth dialog again.

Are these known issues? Ideally, I'd like to be able to have the Kerberos
auth type enabled, but a solution to keep it disabled in the meantime would
be greatly appreciated as well.

Thank you!
-Steven

From stephane.granger at gmail.com  Tue Jul 18 16:56:48 2017
From: stephane.granger at gmail.com (Stephane Granger)
Date: Tue, 18 Jul 2017 16:56:48 -0400
Subject: [keycloak-user] Unexpected ForbiddenException on createClient with
	3.2.0.Final
Message-ID: <CAHX=cdXz_6uyNs_dptu+aWP4bU4Xt24L6CyGs_94reLXL5NEAg@mail.gmail.com>

Hi,

since upgrading to 3.2.0.Final, my client is not able to create clients in
a realm it just created.  This was working before with 3.1.0.Final and
earlier versions as well.

I wrote a small program to demonstrate the problem.

Before running the program, you'll need to add the "testClient" to the
master realm,
Protocol: openid-connect
Access type: confidential

You will need to modify the code to change the CLIENT_SECRET constant to
match your environment.  You'll also need to change the keycloak.version
property in the pom.xml to match the version you're testing against.

When running with 3.2.0.Final, we get the following:
14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
task-48) RESTEASY002005: Failed executing POST
/admin/realms/testRealm/clients: org.keycloak.services.ForbiddenException
at
org.keycloak.services.resources.admin.permissions.ClientPermissions.requireManage(ClientPermissions.java:248)
at
org.keycloak.services.resources.admin.ClientsResource.createClient(ClientsResource.java:164)

With 3.1.0.Final, the "testClient" is created successfully in the new
testRealm.

Stephane

From akaya at expedia.com  Wed Jul 19 01:01:14 2017
From: akaya at expedia.com (Sarp Kaya)
Date: Wed, 19 Jul 2017 05:01:14 +0000
Subject: [keycloak-user] Keycloak 3.2.0 issue with PasswordHashProvider
 SPI
In-Reply-To: <f30946ca-9cc4-9768-0859-3dd55699e1e3@redhat.com>
References: <AD946FFC-4E40-4CA8-B6E3-24970BB6DC14@expedia.com>
	<f30946ca-9cc4-9768-0859-3dd55699e1e3@redhat.com>
Message-ID: <E909952C-DC7D-4A80-A30A-B61230DFC97C@expedia.com>

Hi Marek,

The below are the steps to reproduce it:


  1.  Deploy a keycloak version 3.1.0
  2.  Deploy another keycloak instance v3.1; make sure they?re clustered
  3.  Login to admin master field
  4.  Change the encryption
  5.  Logout/login to make sure that iterations work as expected
  6.  Now re-deploy one of the keycloak instances with v3.2.0
  7.  Try to login on the keycloak instance v3.2; iterations will be -1

Thanks,
Sarp

From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Tuesday, July 18, 2017 at 8:06 PM
To: Abdullah Sarp <akaya at expedia.com<mailto:akaya at expedia.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Keycloak 3.2.0 issue with PasswordHashProvider SPI

I've tried to reproduce but wasn't able. What I did was:
- Start 3.2.0
- During initial creation of admin user, I can see that it uses iterations -1, so it defaults to 27500 iterations, which is the default for Pbkdf2Sha256PasswordHashProviderFactory.
- I've manually changed the password policy in admin console and added Hash Iterations to be 10000.
- After relogin of admin user, I can see that it uses configured 10000 iterations. New users are always created with 10000 iterations.

Marek

On 18/07/17 02:32, Sarp Kaya wrote:

Hello,

I know that this is an internal SPI but I believe it?s broken.

I realised that interface has been changed, now it?s giving the iterations directly for the ?encode? method. The problem is it?s always calling encode method with iterations valued ?1 regardless of what you put in the UI. I realised that in keycloak for "Pbkdf2PasswordHashProvider? it?s defaulting to 20000 iterations; but if you want this to be higher or lower, it doesn?t work either (since iterations will always be ?1)

My question is, could you please check this? Also if you don?t support ?internal SPIs? how are we going to use other encryption methods such as bcrypt or scrypt etc?
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user


From yizhoujiang at hengtiansoft.com  Wed Jul 19 01:07:48 2017
From: yizhoujiang at hengtiansoft.com (Yizhou Jiang(Yizhou))
Date: Wed, 19 Jul 2017 05:07:48 +0000
Subject: [keycloak-user] where does the tomcat client adapter save the
	session
Message-ID: <8410B795605D1A4C9DC12833971BFA753252BEF4@PWSDEX01.hengtiansoft.com>

Hi,
      I have two questions:


1      Where does the tomcat client  adapter store  the user  session ?


      when a user logged into a application procted by a tomcat client adapter . there is only  ?JSESSIONID=E1EAC81E52C97DD64FFB4C13A1231996? in the cookie?
But when I restart the tomcat , the user use the  cookie still can login into the application.  obviously , the session isn?t store in the memory of tomcat , Where does the tomcat client adapter store the  user session?

2     Is there any settings about policy enforcer that can  make unauthenticated  user  access some resources in a application protected by a tomcat client adapter?

Set the enforcement-mode  with value ?DISABLED? still require the user be authenticated.

  "policy-enforcer": {
        "enforcement-mode": "PERMISSIVE",
        "paths": [
            {
                "path": "/public/*",
                "enforcement-mode": "DISABLED"
            }
        ]
    }



thanks ,
yizhou


From hmlnarik at redhat.com  Wed Jul 19 01:30:35 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 19 Jul 2017 07:30:35 +0200
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
Message-ID: <CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>

I've checked email verification upon user registration - the timeout
in the e-mail is 5 minutes as expected. Can you share more details of
your setup?

--Hynek

On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa <thiago.addevico at gmail.com> wrote:
> Hi,
>
> We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're not
> sure is intentional. The e-mail verification time changed from 5 minutes
> (User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
> Action Lifespan). It seems weird for us because it does not seem
> admin-initiated, since it is part of the default user registration process
> to verify his or her email. Is this a bug?
>
> Best regards,
> Thiago Presa
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From sblanc at redhat.com  Wed Jul 19 01:44:21 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 19 Jul 2017 07:44:21 +0200
Subject: [keycloak-user] Unexpected ForbiddenException on createClient
 with 3.2.0.Final
In-Reply-To: <CAHX=cdXz_6uyNs_dptu+aWP4bU4Xt24L6CyGs_94reLXL5NEAg@mail.gmail.com>
References: <CAHX=cdXz_6uyNs_dptu+aWP4bU4Xt24L6CyGs_94reLXL5NEAg@mail.gmail.com>
Message-ID: <CAMZCGg-cug2E009ErvHxcpCkvoJyys=AnezH_SxD+cOukccfHQ@mail.gmail.com>

Hi,

Do you have a link to your test program/reproducer ?
And could you also open a ticket at https://issues.jboss.org/browse/KEYCLOAK
?

Seb


On Tue, Jul 18, 2017 at 10:56 PM, Stephane Granger <
stephane.granger at gmail.com> wrote:

> Hi,
>
> since upgrading to 3.2.0.Final, my client is not able to create clients in
> a realm it just created.  This was working before with 3.1.0.Final and
> earlier versions as well.
>
> I wrote a small program to demonstrate the problem.
>
> Before running the program, you'll need to add the "testClient" to the
> master realm,
> Protocol: openid-connect
> Access type: confidential
>
> You will need to modify the code to change the CLIENT_SECRET constant to
> match your environment.  You'll also need to change the keycloak.version
> property in the pom.xml to match the version you're testing against.
>
> When running with 3.2.0.Final, we get the following:
> 14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
> task-48) RESTEASY002005: Failed executing POST
> /admin/realms/testRealm/clients: org.keycloak.services.ForbiddenException
> at
> org.keycloak.services.resources.admin.permissions.ClientPermissions.
> requireManage(ClientPermissions.java:248)
> at
> org.keycloak.services.resources.admin.ClientsResource.createClient(
> ClientsResource.java:164)
>
> With 3.1.0.Final, the "testClient" is created successfully in the new
> testRealm.
>
> Stephane
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From akaya at expedia.com  Wed Jul 19 02:39:15 2017
From: akaya at expedia.com (Sarp Kaya)
Date: Wed, 19 Jul 2017 06:39:15 +0000
Subject: [keycloak-user] 3.2.0 to 3.1.0 Downgrade causing login errors
Message-ID: <D7FB327C-F421-478A-A9C2-70B58BE7817C@expedia.com>

Hello,

If we left the password encryptor default, upon upgrading from 3.1.0 to 3.2.0 and then followed by a downgrade to 3.1.0 causes login screen to give ?Invalid username or password? issue.

I am guessing this is due to default encryptor being changed in V3.2.0. My question is after downgrade, is there a way to fix this issue? Especially if it is done on the master realm, then you simply cannot login anymore.

Thank you,
Sarp

From mposolda at redhat.com  Wed Jul 19 03:28:19 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Jul 2017 09:28:19 +0200
Subject: [keycloak-user] Keycloak 3.2.0 issue with PasswordHashProvider
 SPI
In-Reply-To: <E909952C-DC7D-4A80-A30A-B61230DFC97C@expedia.com>
References: <AD946FFC-4E40-4CA8-B6E3-24970BB6DC14@expedia.com>
	<f30946ca-9cc4-9768-0859-3dd55699e1e3@redhat.com>
	<E909952C-DC7D-4A80-A30A-B61230DFC97C@expedia.com>
Message-ID: <28e9f987-6bc9-88da-a756-4b47215944fd@redhat.com>

Hi Sarp,

Ah, so it happens after migration from 3.1.0.

Could you please try with your steps, but after your step 6 do also:

7. re-deploy also the second keycloak instance with v 3.2.0
8. Try to login on any of the keycloak instance (both should be on v3.2) 
and doublecheck the behaviour?

The reason is, that we don't support the cluster when one node is 
running on v3.2 and second on v3.1. Both keycloak nodes should run on 
same version, otherwise the behaviour is unexpected. Also in step 6, 
once the first node with v3.2 is started, the DB is migrated to v3.2 and 
it's not supported to run keycloak with 3.1 or older version at this point.

If the issue still happens after both nodes migrated to v3.2, please 
create JIRA with the steps.

Thanks,
Marek


On 19/07/17 07:01, Sarp Kaya wrote:
> Hi Marek,
>
> The below are the steps to reproduce it:
>
>  1. Deploy a keycloak version 3.1.0
>  2. Deploy another keycloak instance v3.1; make sure they?re clustered
>  3. Login to admin master field
>  4. Change the encryption
>  5. Logout/login to make sure that iterations work as expected
>  6. Now re-deploy one of the keycloak instances with v3.2.0
>  7. Try to login on the keycloak instance v3.2; iterations will be -1
>
>
> Thanks,
> Sarp
>
> From: Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>>
> Date: Tuesday, July 18, 2017 at 8:06 PM
> To: Abdullah Sarp <akaya at expedia.com <mailto:akaya at expedia.com>>, 
> "keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>" 
> <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: [keycloak-user] Keycloak 3.2.0 issue with 
> PasswordHashProvider SPI
>
> I've tried to reproduce but wasn't able. What I did was:
> - Start 3.2.0
> - During initial creation of admin user, I can see that it uses 
> iterations -1, so it defaults to 27500 iterations, which is the 
> default for Pbkdf2Sha256PasswordHashProviderFactory.
> - I've manually changed the password policy in admin console and added 
> Hash Iterations to be 10000.
> - After relogin of admin user, I can see that it uses configured 10000 
> iterations. New users are always created with 10000 iterations.
>
> Marek
>
> On 18/07/17 02:32, Sarp Kaya wrote:
>> Hello,
>>
>> I know that this is an internal SPI but I believe it?s broken.
>>
>> I realised that interface has been changed, now it?s giving the iterations directly for the ?encode? method. The problem is it?s always calling encode method with iterations valued ?1 regardless of what you put in the UI. I realised that in keycloak for "Pbkdf2PasswordHashProvider? it?s defaulting to 20000 iterations; but if you want this to be higher or lower, it doesn?t work either (since iterations will always be ?1)
>>
>> My question is, could you please check this? Also if you don?t support ?internal SPIs? how are we going to use other encryption methods such as bcrypt or scrypt etc?
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>


From mposolda at redhat.com  Wed Jul 19 03:33:12 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Jul 2017 09:33:12 +0200
Subject: [keycloak-user] 3.2.0 to 3.1.0 Downgrade causing login errors
In-Reply-To: <D7FB327C-F421-478A-A9C2-70B58BE7817C@expedia.com>
References: <D7FB327C-F421-478A-A9C2-70B58BE7817C@expedia.com>
Message-ID: <3f7ada29-c822-f4ea-4289-1da46764cebd@redhat.com>

We don't support downgrade.

In other words, when you do this:
- Run keycloak on 3.1.0
- Stop keycloak 3.1.0 and run keycloak 3.2.0 against same database. At 
this point, your DB (both schema and data) are migrated to version 3.2.0
- At this point, it's not supported to run Keycloak 3.1.0 (or any other 
older version) against same DB, which was already migrated to 3.2.0. If 
you do this, the behaviour is completely unexpected.

See our migration guide for more details.

Marek

On 19/07/17 08:39, Sarp Kaya wrote:
> Hello,
>
> If we left the password encryptor default, upon upgrading from 3.1.0 to 3.2.0 and then followed by a downgrade to 3.1.0 causes login screen to give ?Invalid username or password? issue.
>
> I am guessing this is due to default encryptor being changed in V3.2.0. My question is after downgrade, is there a way to fix this issue? Especially if it is done on the master realm, then you simply cannot login anymore.
>
> Thank you,
> Sarp
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 19 03:42:05 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Jul 2017 09:42:05 +0200
Subject: [keycloak-user] where does the tomcat client adapter save the
 session
In-Reply-To: <8410B795605D1A4C9DC12833971BFA753252BEF4@PWSDEX01.hengtiansoft.com>
References: <8410B795605D1A4C9DC12833971BFA753252BEF4@PWSDEX01.hengtiansoft.com>
Message-ID: <33909ad0-25d3-8b83-c57e-1fd93aac03ec@redhat.com>

On 19/07/17 07:07, Yizhou Jiang(Yizhou) wrote:
> Hi,
>        I have two questions:
>
>
> 1      Where does the tomcat client  adapter store  the user  session ?
>
>
>        when a user logged into a application procted by a tomcat client adapter . there is only  ?JSESSIONID=E1EAC81E52C97DD64FFB4C13A1231996? in the cookie?
> But when I restart the tomcat , the user use the  cookie still can login into the application.  obviously , the session isn?t store in the memory of tomcat , Where does the tomcat client adapter store the  user session?
It's saved in the HTTP Session and AFAIK HTTP sessions are not persisted 
by Tomcat and are cleared after restart.

But I guess that when you restarted Tomcat, you didnn't restarted the 
Keycloak server, right? So you still have SSO cookie KEYCLOAK_IDENTITY 
on keycloak server. So what happens for you is that after restart of 
Tomcat and open the URL of your Tomcat application, user is redirected 
to Keycloak, here he is automatically authenticated due to SSO and hence 
in Tomcat is automatically authenticated too.

>
> 2     Is there any settings about policy enforcer that can  make unauthenticated  user  access some resources in a application protected by a tomcat client adapter?
>
> Set the enforcement-mode  with value ?DISABLED? still require the user be authenticated.
>
>    "policy-enforcer": {
>          "enforcement-mode": "PERMISSIVE",
>          "paths": [
>              {
>                  "path": "/public/*",
>                  "enforcement-mode": "DISABLED"
>              }
>          ]
>      }
Yes, true. There are security constraints declared in web.xml of your 
web application. And adapter always require user to be authenticated 
(and redirects to login screen) once user enters some "secured" URL from 
there. So you may need to rather change your security constraints in 
web.xml to ensure some URL is public.

Also I am not sure at 100%, but I think that those "public" URLs 
declared in web.xml will be just ignored by Keycloak adapter at all. 
Which means that declared "policy-enforcer" will be ignored too. In 
other words, the "policy-enforcer" is applied just for authenticated 
requests and it's done after user was authenticated (again not sure at 
100%, but rather something like 95% :)

Marek
>
>
>
> thanks ,
> yizhou
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 19 03:46:59 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Jul 2017 09:46:59 +0200
Subject: [keycloak-user] New Event Type
In-Reply-To: <AA9A1979BCCB3F4998617B9D33FA3900230B12DB@COVMSGCES-MBX13>
References: <AA9A1979BCCB3F4998617B9D33FA3900230B12DB@COVMSGCES-MBX13>
Message-ID: <7499b875-cc44-cfa2-a781-214284ebec92@redhat.com>

I think that it can't be extended and new EventType can't be added ATM. 
It's enum, not string. Feel free to create JIRA.

Maybe you can workaround by using some event of standard type like LOGIN 
or REGISTER, but add the custom event detail like "subtype" with 
anything you want?

Marek

On 18/07/17 21:20, Geadah, Nicolas (VEC) wrote:
> We are in the process of customizing the browser login and self-registration flows. As part of the customization, we will require new "events" to be created for audit purposes.  Is it possible to create new event types that can be retrieved in keycloak's built-in admin console - or is the list of events supported by keycloak a predefined set that cannot be extended?
>
> Thank you!
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Wed Jul 19 04:20:50 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Jul 2017 10:20:50 +0200
Subject: [keycloak-user] Kerberos auth type displays basic auth prompt
 under Windows
In-Reply-To: <CAHVh=dbuWYn-vQg5b-jQ=u519hbxq393tnYpQYtwCFsJoyPg-g@mail.gmail.com>
References: <CAHVh=dbuWYn-vQg5b-jQ=u519hbxq393tnYpQYtwCFsJoyPg-g@mail.gmail.com>
Message-ID: <48da6032-f2e6-52f4-f94f-69ced1144c0b@redhat.com>

On 18/07/17 22:07, Steven Mirabito wrote:
> Hey,
>
> I have Keycloak configured to check passwords against an MIT Kerberos
> server in my user federation source, and that works fine. I then set the
> Kerberos authentication type to "alternative" - most of our users will be
> coming in from personal devices where they'll just log in via the form, but
> we do have a shared machine where this would be nice to have. However, I
> started receiving complaints that when this option is enabled, any browser
> under Windows will show a basic auth dialog which the user has to cancel
> out of to reach the login page (other platforms show a blank "Kerberos
> Unsupported" page and then redirect to the normal login page without a
> dialog). To make matters worse, I can't seem to turn the option off now -
> switching the Kerberos auth type to "disabled" will work for a little bit,
> but after a short period of time it will turn itself back on and users will
> start to see the basic auth dialog again.
>
> Are these known issues? Ideally, I'd like to be able to have the Kerberos
> auth type enabled, but a solution to keep it disabled in the meantime would
> be greatly appreciated as well.
For the first question, I don't know how to disable the basic auth 
prompt TBH. I didn't tested on Windows. Are all the browsers like IE, 
Firefox, Chrome behave like this or just IE?

Maybe there is some switch in Windows domain or in browser to disable 
those prompts. Checked some sites, but not sure what is relevant: 
https://www.lansweeper.com/kb/141/enabling-or-disabling-login-prompts.html 
. Other option is to change authentication flow and replace 
SpnegoAuthenticator with custom one, which will return header 400 
instead of 401 . See this 
https://stackoverflow.com/questions/9859627/how-to-prevent-browser-to-invoke-basic-auth-popup-and-handle-401-error-using-jqu 
. However not sure if automatic kerberos/spnego authentication will 
still work in case that user has kerberos ticket, I guess likely not :/

For the second question, Kerberos authenticator is switched to 
ALTERNATIVE when you create or edit Kerberos federation provider or LDAP 
provider with Kerberos switched ON. So if you disable Kerberos on your 
LDAP storage provider or remove Kerberos provider, it won't change from 
DISABLED to ALTERNATIVE anymore.

Marek

>
> Thank you!
> -Steven
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From yizhoujiang at hengtiansoft.com  Wed Jul 19 04:51:36 2017
From: yizhoujiang at hengtiansoft.com (Yizhou Jiang(Yizhou))
Date: Wed, 19 Jul 2017 08:51:36 +0000
Subject: [keycloak-user] where does the tomcat client adapter save the
 session
In-Reply-To: <33909ad0-25d3-8b83-c57e-1fd93aac03ec@redhat.com>
References: <8410B795605D1A4C9DC12833971BFA753252BEF4@PWSDEX01.hengtiansoft.com>
	<33909ad0-25d3-8b83-c57e-1fd93aac03ec@redhat.com>
Message-ID: <8410B795605D1A4C9DC12833971BFA753252BF1E@PWSDEX01.hengtiansoft.com>

Dear Marek Posolda,
	
Thanks for your kindly help. I  understand the second question now. but the first question still confuse me.

>But I guess that when you restarted Tomcat, you didnn't restarted the Keycloak server, right?

Yes,I didn't restart the keycloak server and there is a SSO cookie on keycloak server.

After I restart the tomcat, the user isn't redirect to keyclaok but login in derectly. 
I have checked it in the firebug, there is really no redirect. 
So, I guess the user session with the cookie of the application is still Exist, not cleared.


thanks ,
yizhou

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Wednesday, July 19, 2017 3:42 PM
To: Yizhou Jiang(Yizhou); keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] where does the tomcat client adapter save the session

On 19/07/17 07:07, Yizhou Jiang(Yizhou) wrote:
> Hi,
>        I have two questions:
>
>
> 1      Where does the tomcat client  adapter store  the user  session ?
>
>
>        when a user logged into a application procted by a tomcat 
> client adapter . there is only  
> ?JSESSIONID=E1EAC81E52C97DD64FFB4C13A1231996? in the cookie?
> But when I restart the tomcat , the user use the  cookie still can login into the application.  obviously , the session isn?t store in the memory of tomcat , Where does the tomcat client adapter store the  user session?
It's saved in the HTTP Session and AFAIK HTTP sessions are not persisted by Tomcat and are cleared after restart.

But I guess that when you restarted Tomcat, you didnn't restarted the Keycloak server, right? So you still have SSO cookie KEYCLOAK_IDENTITY on keycloak server. So what happens for you is that after restart of Tomcat and open the URL of your Tomcat application, user is redirected to Keycloak, here he is automatically authenticated due to SSO and hence in Tomcat is automatically authenticated too.

>
> 2     Is there any settings about policy enforcer that can  make unauthenticated  user  access some resources in a application protected by a tomcat client adapter?
>
> Set the enforcement-mode  with value ?DISABLED? still require the user be authenticated.
>
>    "policy-enforcer": {
>          "enforcement-mode": "PERMISSIVE",
>          "paths": [
>              {
>                  "path": "/public/*",
>                  "enforcement-mode": "DISABLED"
>              }
>          ]
>      }
Yes, true. There are security constraints declared in web.xml of your web application. And adapter always require user to be authenticated (and redirects to login screen) once user enters some "secured" URL from there. So you may need to rather change your security constraints in web.xml to ensure some URL is public.

Also I am not sure at 100%, but I think that those "public" URLs declared in web.xml will be just ignored by Keycloak adapter at all. 
Which means that declared "policy-enforcer" will be ignored too. In other words, the "policy-enforcer" is applied just for authenticated requests and it's done after user was authenticated (again not sure at 100%, but rather something like 95% :)

Marek
>
>
>
> thanks ,
> yizhou
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




From thiago.addevico at gmail.com  Wed Jul 19 08:48:01 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Wed, 19 Jul 2017 09:48:01 -0300
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
Message-ID: <CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>

Sure. We've tested the login registration itself and the timeout is in fact
correct. However, when the user tries to federate with google (and Keycloak
tries to verify that e-mail) the timeout is 12 hours. Can you confirm that?

Best regards,
Thiago Presa

On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> I've checked email verification upon user registration - the timeout
> in the e-mail is 5 minutes as expected. Can you share more details of
> your setup?
>
> --Hynek
>
> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa <thiago.addevico at gmail.com>
> wrote:
> > Hi,
> >
> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're not
> > sure is intentional. The e-mail verification time changed from 5 minutes
> > (User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
> > Action Lifespan). It seems weird for us because it does not seem
> > admin-initiated, since it is part of the default user registration
> process
> > to verify his or her email. Is this a bug?
> >
> > Best regards,
> > Thiago Presa
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> --Hynek
>

From hmlnarik at redhat.com  Wed Jul 19 09:25:09 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 19 Jul 2017 15:25:09 +0200
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
	<CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
Message-ID: <CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>

Yes, thank you.

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

--Hynek

On Wed, Jul 19, 2017 at 2:48 PM, Thiago Presa <thiago.addevico at gmail.com> wrote:
> Sure. We've tested the login registration itself and the timeout is in fact
> correct. However, when the user tries to federate with google (and Keycloak
> tries to verify that e-mail) the timeout is 12 hours. Can you confirm that?
>
> Best regards,
> Thiago Presa
>
> On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> I've checked email verification upon user registration - the timeout
>> in the e-mail is 5 minutes as expected. Can you share more details of
>> your setup?
>>
>> --Hynek
>>
>> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa <thiago.addevico at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're
>> > not
>> > sure is intentional. The e-mail verification time changed from 5 minutes
>> > (User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
>> > Action Lifespan). It seems weird for us because it does not seem
>> > admin-initiated, since it is part of the default user registration
>> > process
>> > to verify his or her email. Is this a bug?
>> >
>> > Best regards,
>> > Thiago Presa
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> --
>>
>> --Hynek
>
>



-- 

--Hynek

From madaras_adrian at yahoo.com  Wed Jul 19 10:08:46 2017
From: madaras_adrian at yahoo.com (Adrian Madaras)
Date: Wed, 19 Jul 2017 14:08:46 +0000 (UTC)
Subject: [keycloak-user] Is there a way to tell which protocolMappers are
 active for a client using kcadm.bat/sh?
References: <2067435985.442341.1500473326511.ref@mail.yahoo.com>
Message-ID: <2067435985.442341.1500473326511@mail.yahoo.com>

Hi everyone,
I am using the kcadm.bat to create clients. Everything works well until the part with the "protocolMappers". Is there a command in kcadm.bat which can assign and activate the "protocolMappers" ("Mappers" in the client tab of the U.I.) for my specific client?
I couldn't find any reference to this point online. Theoretically there should be a variable in the protocolMapper, like isActive=true, that tells the client to send the following mappers in the response, but currently there is none.
This is what a current protocolMapper contains (this is active in the U.I. by the way):"protocolMappers" : [ {? ? "id" : "e41c6882-da3f-4f95-b5e4-9c584615fb1e",? ? "name" : "X500 givenName",? ? "protocol" : "saml",? ? "protocolMapper" : "saml-user-property-mapper",? ? "consentRequired" : true,? ? "consentText" : "${givenName}",? ? "config" : {? ? ? "attribute.nameformat" : "urn:oasis:names:tc:SAML:2.0:attrname-format:uri",? ? ? "user.attribute" : "firstName",? ? ? "friendly.name" : "givenName",? ? ? "attribute.name" : "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"? ? }? }, { ........... THE REST OF THE MAPPERS ...............} ]
As you can see there is no attribute which tells us that this mapper is active for this client. I think there is only a table in the DB that marks this but this is kind of odd being so that I can create a client but not attribute mappers to it.
Am I missing something?
Thanks,
Adrian

From stephane.granger at gmail.com  Wed Jul 19 10:25:51 2017
From: stephane.granger at gmail.com (Stephane Granger)
Date: Wed, 19 Jul 2017 10:25:51 -0400
Subject: [keycloak-user] Unexpected ForbiddenException on createClient
 with 3.2.0.Final
In-Reply-To: <CAMZCGg-cug2E009ErvHxcpCkvoJyys=AnezH_SxD+cOukccfHQ@mail.gmail.com>
References: <CAHX=cdXz_6uyNs_dptu+aWP4bU4Xt24L6CyGs_94reLXL5NEAg@mail.gmail.com>
	<CAMZCGg-cug2E009ErvHxcpCkvoJyys=AnezH_SxD+cOukccfHQ@mail.gmail.com>
Message-ID: <CAHX=cdVLSPygVduk=-UhBmSyD7ewbLHrQePe3AKQRDCnEtNARA@mail.gmail.com>

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

On Wed, Jul 19, 2017 at 1:44 AM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi,
>
> Do you have a link to your test program/reproducer ?
> And could you also open a ticket at https://issues.jboss.org/
> browse/KEYCLOAK ?
>
> Seb
>
>
> On Tue, Jul 18, 2017 at 10:56 PM, Stephane Granger <
> stephane.granger at gmail.com> wrote:
>
>> Hi,
>>
>> since upgrading to 3.2.0.Final, my client is not able to create clients in
>> a realm it just created.  This was working before with 3.1.0.Final and
>> earlier versions as well.
>>
>> I wrote a small program to demonstrate the problem.
>>
>> Before running the program, you'll need to add the "testClient" to the
>> master realm,
>> Protocol: openid-connect
>> Access type: confidential
>>
>> You will need to modify the code to change the CLIENT_SECRET constant to
>> match your environment.  You'll also need to change the keycloak.version
>> property in the pom.xml to match the version you're testing against.
>>
>> When running with 3.2.0.Final, we get the following:
>> 14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>> task-48) RESTEASY002005: Failed executing POST
>> /admin/realms/testRealm/clients: org.keycloak.services.ForbiddenException
>> at
>> org.keycloak.services.resources.admin.permissions.ClientPerm
>> issions.requireManage(ClientPermissions.java:248)
>> at
>> org.keycloak.services.resources.admin.ClientsResource.
>> createClient(ClientsResource.java:164)
>>
>> With 3.1.0.Final, the "testClient" is created successfully in the new
>> testRealm.
>>
>> Stephane
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From sblanc at redhat.com  Wed Jul 19 10:44:54 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 19 Jul 2017 16:44:54 +0200
Subject: [keycloak-user] Unexpected ForbiddenException on createClient
 with 3.2.0.Final
In-Reply-To: <CAHX=cdVLSPygVduk=-UhBmSyD7ewbLHrQePe3AKQRDCnEtNARA@mail.gmail.com>
References: <CAHX=cdXz_6uyNs_dptu+aWP4bU4Xt24L6CyGs_94reLXL5NEAg@mail.gmail.com>
	<CAMZCGg-cug2E009ErvHxcpCkvoJyys=AnezH_SxD+cOukccfHQ@mail.gmail.com>
	<CAHX=cdVLSPygVduk=-UhBmSyD7ewbLHrQePe3AKQRDCnEtNARA@mail.gmail.com>
Message-ID: <CAMZCGg-_ezK5F2Vj9_amWrjjRE2VtBqu_9ghOutyPy3QcxEy=A@mail.gmail.com>

Thx and it's https://issues.jboss.org/browse/KEYCLOAK-5211 I believe ;)

On Wed, Jul 19, 2017 at 4:25 PM, Stephane Granger <
stephane.granger at gmail.com> wrote:

> https://issues.jboss.org/browse/KEYCLOAK-5015
>
> On Wed, Jul 19, 2017 at 1:44 AM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> Hi,
>>
>> Do you have a link to your test program/reproducer ?
>> And could you also open a ticket at https://issues.jboss.org/brows
>> e/KEYCLOAK ?
>>
>> Seb
>>
>>
>> On Tue, Jul 18, 2017 at 10:56 PM, Stephane Granger <
>> stephane.granger at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> since upgrading to 3.2.0.Final, my client is not able to create clients
>>> in
>>> a realm it just created.  This was working before with 3.1.0.Final and
>>> earlier versions as well.
>>>
>>> I wrote a small program to demonstrate the problem.
>>>
>>> Before running the program, you'll need to add the "testClient" to the
>>> master realm,
>>> Protocol: openid-connect
>>> Access type: confidential
>>>
>>> You will need to modify the code to change the CLIENT_SECRET constant to
>>> match your environment.  You'll also need to change the keycloak.version
>>> property in the pom.xml to match the version you're testing against.
>>>
>>> When running with 3.2.0.Final, we get the following:
>>> 14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>>> task-48) RESTEASY002005: Failed executing POST
>>> /admin/realms/testRealm/clients: org.keycloak.services.Forbidde
>>> nException
>>> at
>>> org.keycloak.services.resources.admin.permissions.ClientPerm
>>> issions.requireManage(ClientPermissions.java:248)
>>> at
>>> org.keycloak.services.resources.admin.ClientsResource.create
>>> Client(ClientsResource.java:164)
>>>
>>> With 3.1.0.Final, the "testClient" is created successfully in the new
>>> testRealm.
>>>
>>> Stephane
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>

From jdennis at redhat.com  Wed Jul 19 10:45:32 2017
From: jdennis at redhat.com (John Dennis)
Date: Wed, 19 Jul 2017 10:45:32 -0400
Subject: [keycloak-user] Kerberos auth type displays basic auth prompt
 under Windows
In-Reply-To: <48da6032-f2e6-52f4-f94f-69ced1144c0b@redhat.com>
References: <CAHVh=dbuWYn-vQg5b-jQ=u519hbxq393tnYpQYtwCFsJoyPg-g@mail.gmail.com>
	<48da6032-f2e6-52f4-f94f-69ced1144c0b@redhat.com>
Message-ID: <16a1cdbb-c873-0d93-292f-9861ee4b3076@redhat.com>

On 07/19/2017 04:20 AM, Marek Posolda wrote:
> On 18/07/17 22:07, Steven Mirabito wrote:
>> Hey,
>>
>> I have Keycloak configured to check passwords against an MIT Kerberos
>> server in my user federation source, and that works fine. I then set the
>> Kerberos authentication type to "alternative" - most of our users will be
>> coming in from personal devices where they'll just log in via the form, but
>> we do have a shared machine where this would be nice to have. However, I
>> started receiving complaints that when this option is enabled, any browser
>> under Windows will show a basic auth dialog which the user has to cancel
>> out of to reach the login page (other platforms show a blank "Kerberos
>> Unsupported" page and then redirect to the normal login page without a
>> dialog). To make matters worse, I can't seem to turn the option off now -
>> switching the Kerberos auth type to "disabled" will work for a little bit,
>> but after a short period of time it will turn itself back on and users will
>> start to see the basic auth dialog again.
>>
>> Are these known issues? Ideally, I'd like to be able to have the Kerberos
>> auth type enabled, but a solution to keep it disabled in the meantime would
>> be greatly appreciated as well.
> For the first question, I don't know how to disable the basic auth
> prompt TBH. I didn't tested on Windows. Are all the browsers like IE,
> Firefox, Chrome behave like this or just IE?

This is a known issue with just IE. I first became aware of it with Red 
Hat's IPA product (I often work with that team). Let me ping those folks 
and see if there is a known resolution.


> Maybe there is some switch in Windows domain or in browser to disable
> those prompts. Checked some sites, but not sure what is relevant:
> https://www.lansweeper.com/kb/141/enabling-or-disabling-login-prompts.html
> . Other option is to change authentication flow and replace
> SpnegoAuthenticator with custom one, which will return header 400
> instead of 401 . See this
> https://stackoverflow.com/questions/9859627/how-to-prevent-browser-to-invoke-basic-auth-popup-and-handle-401-error-using-jqu
> . However not sure if automatic kerberos/spnego authentication will
> still work in case that user has kerberos ticket, I guess likely not :/
> 
> For the second question, Kerberos authenticator is switched to
> ALTERNATIVE when you create or edit Kerberos federation provider or LDAP
> provider with Kerberos switched ON. So if you disable Kerberos on your
> LDAP storage provider or remove Kerberos provider, it won't change from
> DISABLED to ALTERNATIVE anymore.
> 
> Marek
> 
>>
>> Thank you!
>> -Steven
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 


-- 
John

From stephane.granger at gmail.com  Wed Jul 19 10:55:27 2017
From: stephane.granger at gmail.com (Stephane Granger)
Date: Wed, 19 Jul 2017 07:55:27 -0700
Subject: [keycloak-user] Unexpected ForbiddenException on createClient
 with 3.2.0.Final
In-Reply-To: <CAMZCGg-_ezK5F2Vj9_amWrjjRE2VtBqu_9ghOutyPy3QcxEy=A@mail.gmail.com>
Message-ID: <CAHX=cdU+ZWLjFWakUhYPJcFHgmxmF_rzqP4akzo6dk3xLHAHXg@mail.gmail.com>

 Doh!  You are right :).

Bad cut & paste!



2017-07-19 14:44:54 +0000 Sebastien Blanc <sblanc at redhat.com> :

> Thx and it's https://issues.jboss.org/browse/KEYCLOAK-5211 I believe ;)
>
> On Wed, Jul 19, 2017 at 4:25 PM, Stephane Granger <
> stephane.granger at gmail.com> wrote:
>
>> https://issues.jboss.org/browse/KEYCLOAK-5015
>>
>> On Wed, Jul 19, 2017 at 1:44 AM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Do you have a link to your test program/reproducer ?
>>> And could you also open a ticket at https://issues.jboss.org/brows
>>> e/KEYCLOAK ?
>>>
>>> Seb
>>>
>>>
>>> On Tue, Jul 18, 2017 at 10:56 PM, Stephane Granger <
>>> stephane.granger at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> since upgrading to 3.2.0.Final, my client is not able to create clients
>>>> in
>>>> a realm it just created.  This was working before with 3.1.0.Final and
>>>> earlier versions as well.
>>>>
>>>> I wrote a small program to demonstrate the problem.
>>>>
>>>> Before running the program, you'll need to add the "testClient" to the
>>>> master realm,
>>>> Protocol: openid-connect
>>>> Access type: confidential
>>>>
>>>> You will need to modify the code to change the CLIENT_SECRET constant to
>>>> match your environment.  You'll also need to change the keycloak.version
>>>> property in the pom.xml to match the version you're testing against.
>>>>
>>>> When running with 3.2.0.Final, we get the following:
>>>> 14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>>>> task-48) RESTEASY002005: Failed executing POST
>>>> /admin/realms/testRealm/clients: org.keycloak.services.Forbidde
>>>> nException
>>>> at
>>>> org.keycloak.services.resources.admin.permissions.ClientPerm
>>>> issions.requireManage(ClientPermissions.java:248)
>>>> at
>>>> org.keycloak.services.resources.admin.ClientsResource.create
>>>> Client(ClientsResource.java:164)
>>>>
>>>> With 3.1.0.Final, the "testClient" is created successfully in the new
>>>> testRealm.
>>>>
>>>> Stephane
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>

From jdennis at redhat.com  Wed Jul 19 11:13:14 2017
From: jdennis at redhat.com (John Dennis)
Date: Wed, 19 Jul 2017 11:13:14 -0400
Subject: [keycloak-user] Kerberos auth type displays basic auth prompt
 under Windows
In-Reply-To: <16a1cdbb-c873-0d93-292f-9861ee4b3076@redhat.com>
References: <CAHVh=dbuWYn-vQg5b-jQ=u519hbxq393tnYpQYtwCFsJoyPg-g@mail.gmail.com>
	<48da6032-f2e6-52f4-f94f-69ced1144c0b@redhat.com>
	<16a1cdbb-c873-0d93-292f-9861ee4b3076@redhat.com>
Message-ID: <e6c4f4da-6216-02ee-6838-8cbcb1cee03c@redhat.com>

On 07/19/2017 10:45 AM, John Dennis wrote:
> This is a known issue with just IE. I first became aware of it with Red 
> Hat's IPA product (I often work with that team). Let me ping those folks 
> and see if there is a known resolution.

OK, I got an answer back, here is what was said:

> https://bugzilla.redhat.com/show_bug.cgi?id=1309041
> 
> tl;dr it's a problem in IE, Edge, and Chrome on Windows. They both use
> the same library to handle authenticate. HTTP Status Code 401 +
> "WWW-Authenticate: Negotiate" header cause the log-in prompt to pop up.
> I was even able to reproduce it with a very simple Python server that
> just emits the status code and header.
> 
> Until this issue is fixed by Microsoft, there is only one workaround:
> use some sort of browser detection and don't return "WWW-Authenticate:
> Negotiate" HTTP header for any IE, Edge, and Chrome on Windows.


-- 
John

From john.d.ament at gmail.com  Wed Jul 19 11:46:01 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 19 Jul 2017 15:46:01 +0000
Subject: [keycloak-user] Automatically logging in after performing an
	Update Password
In-Reply-To: <CAOqetn_FtkKncPg2VqtyE0xUG6deSxfQV6BtmttNyxGneMot4A@mail.gmail.com>
References: <CAOqetn_FtkKncPg2VqtyE0xUG6deSxfQV6BtmttNyxGneMot4A@mail.gmail.com>
Message-ID: <CAOqetn9t2gr0S0FSJksXYjYPYYh8ia=8==ttr+W7YyTW_G5TJw@mail.gmail.com>

Any thoughts?

On Thu, Jul 13, 2017 at 10:27 PM John D. Ament <john.d.ament at gmail.com>
wrote:

> Hi,
>
> Based on the Required Actions guide (
> https://keycloak.gitbooks.io/documentation/server_admin/topics/users/required-actions.html)
> we've implemented a custom required action that acts a lot like Update
> Password (it performs a few other sync items for us).  One of our needs is
> to automatically log the user in to their destination application upon
> setting this password.  This was working for us in 3.1 by creating a custom
> template that was rendered upon the completion of the Update Password
> action that forwarded the user to our application and set the necessary
> cookies.
>
> This no longer works in 3.2.  We believe it has to do with the ability to
> reuse required action links.  Before, the link was one time use so it was
> only working once, however our need is to make those links work unlimited
> times until consumed.  By setting a new challenge to the user after
> updating their password, the token is no longer being marked as consumed
> and the link remains working.
>
> So I was wondering, what other ways could we achieve this behavior?  It
> sounds like a challenge isn't the right approach.
>
> John
>

From bburke at redhat.com  Wed Jul 19 12:49:45 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Jul 2017 12:49:45 -0400
Subject: [keycloak-user] Unexpected ForbiddenException on createClient
 with 3.2.0.Final
In-Reply-To: <CAMZCGg-_ezK5F2Vj9_amWrjjRE2VtBqu_9ghOutyPy3QcxEy=A@mail.gmail.com>
References: <CAHX=cdXz_6uyNs_dptu+aWP4bU4Xt24L6CyGs_94reLXL5NEAg@mail.gmail.com>
	<CAMZCGg-cug2E009ErvHxcpCkvoJyys=AnezH_SxD+cOukccfHQ@mail.gmail.com>
	<CAHX=cdVLSPygVduk=-UhBmSyD7ewbLHrQePe3AKQRDCnEtNARA@mail.gmail.com>
	<CAMZCGg-_ezK5F2Vj9_amWrjjRE2VtBqu_9ghOutyPy3QcxEy=A@mail.gmail.com>
Message-ID: <788ed83c-b96e-654b-cfbb-fe21b728d046@redhat.com>

Ok, i'll get this into 3.2.1 too.  Its related to the fine grain 
permission stuff I"ve done.


On 7/19/17 10:44 AM, Sebastien Blanc wrote:
> Thx and it's https://issues.jboss.org/browse/KEYCLOAK-5211 I believe ;)
>
> On Wed, Jul 19, 2017 at 4:25 PM, Stephane Granger <
> stephane.granger at gmail.com> wrote:
>
>> https://issues.jboss.org/browse/KEYCLOAK-5015
>>
>> On Wed, Jul 19, 2017 at 1:44 AM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Do you have a link to your test program/reproducer ?
>>> And could you also open a ticket at https://issues.jboss.org/brows
>>> e/KEYCLOAK ?
>>>
>>> Seb
>>>
>>>
>>> On Tue, Jul 18, 2017 at 10:56 PM, Stephane Granger <
>>> stephane.granger at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> since upgrading to 3.2.0.Final, my client is not able to create clients
>>>> in
>>>> a realm it just created.  This was working before with 3.1.0.Final and
>>>> earlier versions as well.
>>>>
>>>> I wrote a small program to demonstrate the problem.
>>>>
>>>> Before running the program, you'll need to add the "testClient" to the
>>>> master realm,
>>>> Protocol: openid-connect
>>>> Access type: confidential
>>>>
>>>> You will need to modify the code to change the CLIENT_SECRET constant to
>>>> match your environment.  You'll also need to change the keycloak.version
>>>> property in the pom.xml to match the version you're testing against.
>>>>
>>>> When running with 3.2.0.Final, we get the following:
>>>> 14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>>>> task-48) RESTEASY002005: Failed executing POST
>>>> /admin/realms/testRealm/clients: org.keycloak.services.Forbidde
>>>> nException
>>>> at
>>>> org.keycloak.services.resources.admin.permissions.ClientPerm
>>>> issions.requireManage(ClientPermissions.java:248)
>>>> at
>>>> org.keycloak.services.resources.admin.ClientsResource.create
>>>> Client(ClientsResource.java:164)
>>>>
>>>> With 3.1.0.Final, the "testClient" is created successfully in the new
>>>> testRealm.
>>>>
>>>> Stephane
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From mposolda at redhat.com  Wed Jul 19 13:06:54 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 19 Jul 2017 19:06:54 +0200
Subject: [keycloak-user] where does the tomcat client adapter save the
 session
In-Reply-To: <8410B795605D1A4C9DC12833971BFA753252BF1E@PWSDEX01.hengtiansoft.com>
References: <8410B795605D1A4C9DC12833971BFA753252BEF4@PWSDEX01.hengtiansoft.com>
	<33909ad0-25d3-8b83-c57e-1fd93aac03ec@redhat.com>
	<8410B795605D1A4C9DC12833971BFA753252BF1E@PWSDEX01.hengtiansoft.com>
Message-ID: <8eb11936-8330-f92d-d1b0-d774e675ad0c@redhat.com>

On 19/07/17 10:51, Yizhou Jiang(Yizhou) wrote:
> Dear Marek Posolda,
> 	
> Thanks for your kindly help. I  understand the second question now. but the first question still confuse me.
>
>> But I guess that when you restarted Tomcat, you didnn't restarted the Keycloak server, right?
> Yes,I didn't restart the keycloak server and there is a SSO cookie on keycloak server.
>
> After I restart the tomcat, the user isn't redirect to keyclaok but login in derectly.
> I have checked it in the firebug, there is really no redirect.
> So, I guess the user session with the cookie of the application is still Exist, not cleared.
Maybe yes. I am not 100% sure where Tomcat saves it's HTTP Sessions. 
Maybe there is some file on the disc. If you want those cleared, you can 
maybe delete all those "tmp" and "work" directories? Hopefully Tomcat 
docs have more details around this.

Marek
>
>
> thanks ,
> yizhou
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Wednesday, July 19, 2017 3:42 PM
> To: Yizhou Jiang(Yizhou); keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] where does the tomcat client adapter save the session
>
> On 19/07/17 07:07, Yizhou Jiang(Yizhou) wrote:
>> Hi,
>>         I have two questions:
>>
>>
>> 1      Where does the tomcat client  adapter store  the user  session ?
>>
>>
>>         when a user logged into a application procted by a tomcat
>> client adapter . there is only
>> ?JSESSIONID=E1EAC81E52C97DD64FFB4C13A1231996? in the cookie?
>> But when I restart the tomcat , the user use the  cookie still can login into the application.  obviously , the session isn?t store in the memory of tomcat , Where does the tomcat client adapter store the  user session?
> It's saved in the HTTP Session and AFAIK HTTP sessions are not persisted by Tomcat and are cleared after restart.
>
> But I guess that when you restarted Tomcat, you didnn't restarted the Keycloak server, right? So you still have SSO cookie KEYCLOAK_IDENTITY on keycloak server. So what happens for you is that after restart of Tomcat and open the URL of your Tomcat application, user is redirected to Keycloak, here he is automatically authenticated due to SSO and hence in Tomcat is automatically authenticated too.
>
>> 2     Is there any settings about policy enforcer that can  make unauthenticated  user  access some resources in a application protected by a tomcat client adapter?
>>
>> Set the enforcement-mode  with value ?DISABLED? still require the user be authenticated.
>>
>>     "policy-enforcer": {
>>           "enforcement-mode": "PERMISSIVE",
>>           "paths": [
>>               {
>>                   "path": "/public/*",
>>                   "enforcement-mode": "DISABLED"
>>               }
>>           ]
>>       }
> Yes, true. There are security constraints declared in web.xml of your web application. And adapter always require user to be authenticated (and redirects to login screen) once user enters some "secured" URL from there. So you may need to rather change your security constraints in web.xml to ensure some URL is public.
>
> Also I am not sure at 100%, but I think that those "public" URLs declared in web.xml will be just ignored by Keycloak adapter at all.
> Which means that declared "policy-enforcer" will be ignored too. In other words, the "policy-enforcer" is applied just for authenticated requests and it's done after user was authenticated (again not sure at 100%, but rather something like 95% :)
>
> Marek
>>
>>
>> thanks ,
>> yizhou
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>


From nicolaouantonia at gmail.com  Wed Jul 19 15:57:44 2017
From: nicolaouantonia at gmail.com (Antonia Nicolaou)
Date: Wed, 19 Jul 2017 22:57:44 +0300
Subject: [keycloak-user] Problem with email verification expiration time
Message-ID: <CADQwdOor_Fe_-e9RU1pyM-Zhpuf3veUTY0OyeN0mn9LKm2+EEw@mail.gmail.com>

Hello,

I am using single sign on service from redhat v7.1 and I need to change the
email verification expiration time from 5 minutes to 24 hours. I did it by
changing the 'Login action timeout' to 1 day.The text in the email
verification was changed to '1440 minutes' , but the link still expires in
5 minutes.


Could anyone help me?


Thank you in advanced

From mevans at aconex.com  Wed Jul 19 18:56:38 2017
From: mevans at aconex.com (Matt Evans)
Date: Wed, 19 Jul 2017 22:56:38 +0000
Subject: [keycloak-user] Upgrading from 2.5.4 to 3.2.0
In-Reply-To: <CAJgngAceMhWKGPZLAYPdxqP_AZb17wq9a4XwO+ugxZ61rGrXCg@mail.gmail.com>
References: <ME1PR01MB0769EDC404DFA75E8CD2F015A9AC0@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<CAJgngAceMhWKGPZLAYPdxqP_AZb17wq9a4XwO+ugxZ61rGrXCg@mail.gmail.com>
Message-ID: <ME1PR01MB0769327251601E3D8552639BA9A60@ME1PR01MB0769.ausprd01.prod.outlook.com>

Thanks Stian.

I tested running 2.5.4 with the 3.2.0 schema and keycloak runs and works in our environment. I assume as long as I don?t request an offline token?

However in light of your comments and some other issues we discovered we?re going to have to perform the migration in downtime so using the newer schema with an older release won?t happen.

Matt


From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Friday, 14 July 2017 3:30 PM
To: Matt Evans <mevans at aconex.com>
Cc: keycloak-user <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Upgrading from 2.5.4 to 3.2.0

Are you asking if you can upgrade the DB to 3.2 and still run 2.5.4? The answer to that question is no. It simply won't work.

On 14 July 2017 at 01:11, Matt Evans <mevans at aconex.com<mailto:mevans at aconex.com>> wrote:
Hi

We're looking to upgrade keycloak from 2.5.4 to 3.2.0, but I noticed in the liquibase changesets that one of the changes in 3.2.0 jpa changelog the column OFFLINE_CLIENT_SESSION has been deleted in the OFFLINE_CLIENT_SESSION table.

My question is how will 2.5.4 handle that column missing if we update the schema first? I've tested this scenario in our environment and it seems to work, but we don't request offline tokens. Will that be enough to ensure that we won't get failures because of the missing column?

Thanks

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


From rationull at gmail.com  Wed Jul 19 19:35:46 2017
From: rationull at gmail.com (Jonathan Little)
Date: Wed, 19 Jul 2017 16:35:46 -0700
Subject: [keycloak-user] Updating Default Admin-Initiated Action Lifespan
Message-ID: <CALLLnfWOKX1=_v5VCa2uWeNWo3VSQVgmJiv6qEPoiH_mc-z=9w@mail.gmail.com>

Maybe I'm being dense but how do you change the Default Admin-Initiated
Action Lifespan? It's documented here:

https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/timeouts.html

but even in that documentation the screenshot does not show those options
present. They are not present in the UI as far as I can tell. I'm running
3.1.0.

What am I missing?

From bburke at redhat.com  Wed Jul 19 19:38:50 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Jul 2017 19:38:50 -0400
Subject: [keycloak-user] Unexpected ForbiddenException on createClient
 with 3.2.0.Final
In-Reply-To: <CAHX=cdU+ZWLjFWakUhYPJcFHgmxmF_rzqP4akzo6dk3xLHAHXg@mail.gmail.com>
References: <CAHX=cdU+ZWLjFWakUhYPJcFHgmxmF_rzqP4akzo6dk3xLHAHXg@mail.gmail.com>
Message-ID: <fc9ab079-3cd4-a3ce-619c-28133ef0a275@redhat.com>

See my response in the JIRA.  This bug was rejected as it is expected 
behavior.  The code I used to reproduce and explanation is in the JIRA 
comment


On 7/19/17 10:55 AM, Stephane Granger wrote:
>   Doh!  You are right :).
>
> Bad cut & paste!
>
>
>
> 2017-07-19 14:44:54 +0000 Sebastien Blanc <sblanc at redhat.com> :
>
>> Thx and it's https://issues.jboss.org/browse/KEYCLOAK-5211 I believe ;)
>>
>> On Wed, Jul 19, 2017 at 4:25 PM, Stephane Granger <
>> stephane.granger at gmail.com> wrote:
>>
>>> https://issues.jboss.org/browse/KEYCLOAK-5015
>>>
>>> On Wed, Jul 19, 2017 at 1:44 AM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Do you have a link to your test program/reproducer ?
>>>> And could you also open a ticket at https://issues.jboss.org/brows
>>>> e/KEYCLOAK ?
>>>>
>>>> Seb
>>>>
>>>>
>>>> On Tue, Jul 18, 2017 at 10:56 PM, Stephane Granger <
>>>> stephane.granger at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> since upgrading to 3.2.0.Final, my client is not able to create clients
>>>>> in
>>>>> a realm it just created.  This was working before with 3.1.0.Final and
>>>>> earlier versions as well.
>>>>>
>>>>> I wrote a small program to demonstrate the problem.
>>>>>
>>>>> Before running the program, you'll need to add the "testClient" to the
>>>>> master realm,
>>>>> Protocol: openid-connect
>>>>> Access type: confidential
>>>>>
>>>>> You will need to modify the code to change the CLIENT_SECRET constant to
>>>>> match your environment.  You'll also need to change the keycloak.version
>>>>> property in the pom.xml to match the version you're testing against.
>>>>>
>>>>> When running with 3.2.0.Final, we get the following:
>>>>> 14:50:28,552 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>>>>> task-48) RESTEASY002005: Failed executing POST
>>>>> /admin/realms/testRealm/clients: org.keycloak.services.Forbidde
>>>>> nException
>>>>> at
>>>>> org.keycloak.services.resources.admin.permissions.ClientPerm
>>>>> issions.requireManage(ClientPermissions.java:248)
>>>>> at
>>>>> org.keycloak.services.resources.admin.ClientsResource.create
>>>>> Client(ClientsResource.java:164)
>>>>>
>>>>> With 3.1.0.Final, the "testClient" is created successfully in the new
>>>>> testRealm.
>>>>>
>>>>> Stephane
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From brandon at finitemoment.com  Wed Jul 19 21:28:15 2017
From: brandon at finitemoment.com (Brandon Dale Koepke)
Date: Wed, 19 Jul 2017 18:28:15 -0700
Subject: [keycloak-user] Widget For Embedding in Single Page App
Message-ID: <1500514095.369525.1046563200.0150BB6E@webmail.messagingengine.com>

Hello,

I was hoping to duplicate this functionality with Keycloak: https://auth0.com/docs/libraries/lock/v10/ui-customization#primarycolor-string-. (I want a single-page app ideally where the user can register without being forwarded to a separate page.)
Auth0 has a nice API for both logging in **and** registering users so everything can be done from a single page app on the client side. Login seems to be supported fully and easily from an API with Keycloak using frontend only code but registering users doesn?t seem to be so simple.
In order to do this with Keycloak, it seem that I have a few options.

(1) Embed the Keycloak login/register page in an iframe and theme the login/registration page. (I?m certain there are vulnerabilities I?m introducing by taking this route, CSRF?)(2) Create another separate backend API that has an admin token for registering users. Then you post a JSON describing to the user to a ?/register? endpoint. (Secure I think but wasteful of resources? Also introduces an additional failure point).(3) Capture the required fields and POST them using the same format as a client would when using the regular Keycloak registration page. (Seems like I have to do some interesting fetching in order to get an authorization token for the login here as well, at least according to the pcap I generated. Would really like to avoid doing this if possible.)(4) Create a limited admin user (or client?) that can only create users and nothing more. Pass login information for this user through the frontend and use that user on the frontend to make the admin API calls for registering users. (Difficult to make secure? Seems strange that I would be exposing an admin/client secret to the frontend but as long as it is possible to lock it down enough that the user can?t be used for anything else then I think the is roughly equivalent to how the key cloak page works anyway. Unless I?m missing something important? )(5) Variant of (2), create a new plugin for key cloak that has the required ?/register? api without authenticating users. (Seems like this would already exist if it was possible to do securely.)(6) Have keycloak resolve to a subdomain on my main server, that way even though it isn?t seamless users won?t be redirected to a different domain entirely. (If possible I would like to avoid this since auth0 seems to have solved it.)
Is there something better than any of these? If not, which options are still secure and which would you recommend?
At the end of the day I would like something similar to the login/registration page for Buffer: https://www.buxfer.com[1]. A modal window opens with a create account option, my ideal login/registration flow would be similar.
Any word on this would be greatly appreciated.

Links:

  1. https://www.buxfer.com/

From hmlnarik at redhat.com  Thu Jul 20 02:46:47 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 20 Jul 2017 08:46:47 +0200
Subject: [keycloak-user] Automatically logging in after performing an
 Update Password
In-Reply-To: <CAOqetn9t2gr0S0FSJksXYjYPYYh8ia=8==ttr+W7YyTW_G5TJw@mail.gmail.com>
References: <CAOqetn_FtkKncPg2VqtyE0xUG6deSxfQV6BtmttNyxGneMot4A@mail.gmail.com>
	<CAOqetn9t2gr0S0FSJksXYjYPYYh8ia=8==ttr+W7YyTW_G5TJw@mail.gmail.com>
Message-ID: <CAMvXD=E+6nd6P4CReyZWEY=5a3_QBGba5WGeFgjSGdJYM_=AZQ@mail.gmail.com>

There was a change in internals of authentication flows due to
cross-dc support. It seems that you need to use action token for
achieving this functionality. Action tokens have option to make them
expire after first successful use. Documentation is not rendered yet
but you can see the current version at [1]. Would something similar to
either [2] or [3] work for your case?

Note that action token API is not yet stabilized and comments to its
usability are more than welcome.

--Hynek

[1] https://github.com/keycloak/keycloak-documentation/blob/master/server_development/topics/action-token-spi.adoc
[2] https://github.com/keycloak/keycloak-quickstarts/tree/master/action-token-authenticator
[3] https://github.com/keycloak/keycloak-quickstarts/tree/master/action-token-required-action

On Wed, Jul 19, 2017 at 5:46 PM, John D. Ament <john.d.ament at gmail.com> wrote:
> Any thoughts?
>
> On Thu, Jul 13, 2017 at 10:27 PM John D. Ament <john.d.ament at gmail.com>
> wrote:
>
>> Hi,
>>
>> Based on the Required Actions guide (
>> https://keycloak.gitbooks.io/documentation/server_admin/topics/users/required-actions.html)
>> we've implemented a custom required action that acts a lot like Update
>> Password (it performs a few other sync items for us).  One of our needs is
>> to automatically log the user in to their destination application upon
>> setting this password.  This was working for us in 3.1 by creating a custom
>> template that was rendered upon the completion of the Update Password
>> action that forwarded the user to our application and set the necessary
>> cookies.
>>
>> This no longer works in 3.2.  We believe it has to do with the ability to
>> reuse required action links.  Before, the link was one time use so it was
>> only working once, however our need is to make those links work unlimited
>> times until consumed.  By setting a new challenge to the user after
>> updating their password, the token is no longer being marked as consumed
>> and the link remains working.
>>
>> So I was wondering, what other ways could we achieve this behavior?  It
>> sounds like a challenge isn't the right approach.
>>
>> John
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From hmlnarik at redhat.com  Thu Jul 20 02:48:14 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 20 Jul 2017 08:48:14 +0200
Subject: [keycloak-user] Updating Default Admin-Initiated Action Lifespan
In-Reply-To: <CALLLnfWOKX1=_v5VCa2uWeNWo3VSQVgmJiv6qEPoiH_mc-z=9w@mail.gmail.com>
References: <CALLLnfWOKX1=_v5VCa2uWeNWo3VSQVgmJiv6qEPoiH_mc-z=9w@mail.gmail.com>
Message-ID: <CAMvXD=Fd4DJTUWnD-HzZQN9Xag9ZuWL0534b=tvjXbd_EjQCFA@mail.gmail.com>

These options were added in 3.2.0.

--Hynek

On Thu, Jul 20, 2017 at 1:35 AM, Jonathan Little <rationull at gmail.com> wrote:
> Maybe I'm being dense but how do you change the Default Admin-Initiated
> Action Lifespan? It's documented here:
>
> https://keycloak.gitbooks.io/documentation/server_admin/topics/sessions/timeouts.html
>
> but even in that documentation the screenshot does not show those options
> present. They are not present in the UI as far as I can tell. I'm running
> 3.1.0.
>
> What am I missing?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From hmlnarik at redhat.com  Thu Jul 20 05:31:16 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 20 Jul 2017 11:31:16 +0200
Subject: [keycloak-user] Problems logging out using JEE to keycloak to
 SAML (ADFS) (better formatted)
In-Reply-To: <1621105909.2492952.1499697892635@mail.yahoo.com>
References: <2140990500.5387792.1499205110788.ref@mail.yahoo.com>
	<2140990500.5387792.1499205110788@mail.yahoo.com>
	<CAMvXD=GippnWuNH_XZFaeJjyoJuhZJpor8egbgaMwwAKzSLG4w@mail.gmail.com>
	<1621105909.2492952.1499697892635@mail.yahoo.com>
Message-ID: <CAMvXD=G8hiYJPkNNXb+vqesSz5gygL-TdtWyC=AmxEUEiyk1Yg@mail.gmail.com>

What is the setup of the ADFS in keycloak? Can you check whether it
works with frontchannel logout? If you could inspect SAML interchange
between Keycloak and ADFS (e.g. by enabling debug logging in keycloak
as shown in the blog post [1]), you should be able to see the SAML
messages and how they are processed. It is possible that e.g. the
logout status from ADFS is unsuccessful, that might cause this type of
issue.

If you could file a JIRA and share the communication or even server
log there, together with you reproducer application, that would be
very helpful.

Thanks

--Hynek

On Mon, Jul 10, 2017 at 4:44 PM, Jason Spittel <jasonspittel at yahoo.com> wrote:
> Hi Hynek,
>
> My setup is exactly from that tutorial. And I found the problem with logging
> out, I'm not sure how to report the issue (not sure if it's really a KC
> issue at all), raise a Jira ticket?
>
> Setup:
> JEE app running JSF calling EJBs.
> JEE app using wildfly keycloak saml adapters to talk to Keycloak (KC)
> Keycloak setup to use ADFS as its IdP.
>
> Problem:
> JEE app needs to logout twice to logout. (That is, after first logout, you
> can still hit the protected resource on the JEE app without logging in
> again)
>
> Cause:
> 1) first logout:
> - JSF's redirects
> (externalContext.redirect(externalContext.getRequestContextPath() +
> "/?GLO=true" );) removes the jsessionId cookie, which causes an initial auth
> from JEE to KC when logout is hit.
> -rest of logout proceeds properly, Realm Session ID is removed from KC, ADFS
> logs use out.
> 2) second logout
> -JSF's redirect again removes the jsessionId cookie, tries to do an initial
> auth from JEE to KC, but KC doesn't have any sessions to auth user with, and
> user is kicked out, 'successfully' logging out.
>
> Solution:
> preserve the jsessionid on redirect, initial auth to KC doesn't occur on
> logout.
>
>    public void logout() throws IOException, ServletException
>    {
>       ExternalContext externalContext = _context.getExternalContext();
>
>       try
>       {
>          externalContext.invalidateSession();
>
>          _httpRequest.logout();
>       }
>       catch (Exception ex)
>       {
>          _logger.error(ex);
>       }
>       finally
>       {
>          // need to set the cookie for the jsessionid, or will re-auth with
> KC, and will require two logouts to logout completely
>          preserveJsessionidCookie(externalContext);
>
>          externalContext.redirect(externalContext.getRequestContextPath() +
> "/?GLO=true" );
>       }
>    }
>
>    private void preserveJsessionidCookie(ExternalContext externalContext)
>    {
>       for (Cookie cookie :
> ((HttpServletRequest)externalContext.getRequest()).getCookies())
>       {
>          if (cookie.getName().equalsIgnoreCase("jsessionid"))
>          {
>
> ((HttpServletResponse)externalContext.getResponse()).addCookie(cookie);
>             break;
>          }
>       }
>    }
>
> Cheers,
>
> Jason
> On Monday, July 10, 2017, 6:09:36 AM PDT, Hynek Mlnarik
> <hmlnarik at redhat.com> wrote:
>
>
> How are ADFS and Keycloak configured? If according to [1], the
> sessions should be cleared. Beware that ADFS also leaves ssoCookie in
> the browser so that it might just relogin the user behind the scenes,
> see discussion on [2] for further details.
>
> --Hynek
>
> [1]
> http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as-brokered.html
> [2] https://issues.jboss.org/browse/KEYCLOAK-4398
>
> On Tue, Jul 4, 2017 at 11:51 PM, Jason Spittel <jasonspittel at yahoo.com>
> wrote:
>> Apparently my formatting was lost. So I'm reposting this in a more
>> readable format:
>>
>> Hello,
>>
>> I'm having difficulty completing a logout.
>> SETUP:
>> JEE webapp to keycloak to IdP (ADFS (SAML))
>>
>> WORKFLOW:
>> 1) On logout in the webapp
>> externalContext.redirect(externalContext.getRequestContextPath() +
>> "?GLO=true");
>>
>> 2) User is sent to ADFS letting them know they have successfully logged
>> out.
>>
>> 3) However, there is still a keycloak user session alive (seen in the
>> admin console)
>>
>> 4) Hitting a protected resource in the webapp lets user in without having
>> to log back in.
>>
>> Debugging the keycloak server, I found this bit of code in
>> AuthenticationManager.browserLogout() line 262:
>>
>> String brokerId = userSession.getNote(Details.IDENTITY_PROVIDER);
>>
>> if (brokerId != null) {
>>    IdentityProvider identityProvider =
>> IdentityBrokerService.getIdentityProvider(session, realm, brokerId);
>>    Response response =
>> identityProvider.keycloakInitiatedBrowserLogout(session, userSession,
>> uriInfo, realm);
>>    if (response != null) return response;
>> }
>>
>> return finishBrowserLogout(session, realm, userSession, uriInfo,
>> connection, headers);
>>
>> I think, unless I'm misunderstanding it, that I need to hit the
>> finishBrowserLogout method, to clear the keycloak user session.
>> But the way this is written makes it so it never will. Is keycloak
>> expecting ADFS to clear its user session? Am I logging out incorrectly?
>> Thanks,
>> Jason
>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> --Hynek
>



-- 

--Hynek

From mitya at cargosoft.ru  Thu Jul 20 13:48:53 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Thu, 20 Jul 2017 20:48:53 +0300
Subject: [keycloak-user] Provider + Entity SPI + hot redeploy = exception
Message-ID: <1500572933.4267.1.camel@cargosoft.ru>

Hi,

I've got a provider using Entity SPI. If I hot redeploy it, I've got
the following exception upon the first access to my custom entity:

20:37:54,227 ERROR [io.undertow.request] (default task-10) UT005023:
Exception handling request to /auth/realms/master/beer:
org.jboss.resteasy.spi.UnhandledException:
org.keycloak.models.ModelException: java.lang.IllegalArgumentException:
Type specified for TypedQuery
[beercloak.models.jpa.entities.BeerEntity] is incompatible with query
return type [class beercloak.models.jpa.entities.BeerEntity]

Full stacktrace: https://pastebin.com/i6jXfQMY

Seems like upon redeployment JPA entity classes are not unloaded, and
Hibernate keeps using them, while the reloaded provider code uses newly
loaded classes. Is there anything we can do about it?

Dmitry

From mposolda at redhat.com  Thu Jul 20 14:51:37 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 20 Jul 2017 20:51:37 +0200
Subject: [keycloak-user] Kerberos auth type displays basic auth prompt
 under Windows
In-Reply-To: <e6c4f4da-6216-02ee-6838-8cbcb1cee03c@redhat.com>
References: <CAHVh=dbuWYn-vQg5b-jQ=u519hbxq393tnYpQYtwCFsJoyPg-g@mail.gmail.com>
	<48da6032-f2e6-52f4-f94f-69ced1144c0b@redhat.com>
	<16a1cdbb-c873-0d93-292f-9861ee4b3076@redhat.com>
	<e6c4f4da-6216-02ee-6838-8cbcb1cee03c@redhat.com>
Message-ID: <711c5e63-27d9-c0eb-046a-13edd1771fd0@redhat.com>

Thanks for the reference!

Marek

On 19/07/17 17:13, John Dennis wrote:
> On 07/19/2017 10:45 AM, John Dennis wrote:
>> This is a known issue with just IE. I first became aware of it with 
>> Red Hat's IPA product (I often work with that team). Let me ping 
>> those folks and see if there is a known resolution.
>
> OK, I got an answer back, here is what was said:
>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1309041
>>
>> tl;dr it's a problem in IE, Edge, and Chrome on Windows. They both use
>> the same library to handle authenticate. HTTP Status Code 401 +
>> "WWW-Authenticate: Negotiate" header cause the log-in prompt to pop up.
>> I was even able to reproduce it with a very simple Python server that
>> just emits the status code and header.
>>
>> Until this issue is fixed by Microsoft, there is only one workaround:
>> use some sort of browser detection and don't return "WWW-Authenticate:
>> Negotiate" HTTP header for any IE, Edge, and Chrome on Windows.
>
>


From thiago.addevico at gmail.com  Thu Jul 20 15:29:45 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Thu, 20 Jul 2017 16:29:45 -0300
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
	<CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
	<CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>
Message-ID: <CAHDpToX81WVWgTbdML_pAUWpHwNz-wHDQ-L9pO23s3fHPSSX7g@mail.gmail.com>

Hi,

Another change that I've noticed from 3.1.0.Final to 3.2.0.Final is that
the email "Test connection" button now fails with the message "*Error!* Logged
in user does not have an e-mail.". The email validation, however, keeps
working just fine. Is this working as intended?

Best regards,
Thiago

On Wed, Jul 19, 2017 at 10:25 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Yes, thank you.
>
> https://issues.jboss.org/browse/KEYCLOAK-5209
>
> --Hynek
>
> On Wed, Jul 19, 2017 at 2:48 PM, Thiago Presa <thiago.addevico at gmail.com>
> wrote:
> > Sure. We've tested the login registration itself and the timeout is in
> fact
> > correct. However, when the user tries to federate with google (and
> Keycloak
> > tries to verify that e-mail) the timeout is 12 hours. Can you confirm
> that?
> >
> > Best regards,
> > Thiago Presa
> >
> > On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
> >>
> >> I've checked email verification upon user registration - the timeout
> >> in the e-mail is 5 minutes as expected. Can you share more details of
> >> your setup?
> >>
> >> --Hynek
> >>
> >> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa <
> thiago.addevico at gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're
> >> > not
> >> > sure is intentional. The e-mail verification time changed from 5
> minutes
> >> > (User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
> >> > Action Lifespan). It seems weird for us because it does not seem
> >> > admin-initiated, since it is part of the default user registration
> >> > process
> >> > to verify his or her email. Is this a bug?
> >> >
> >> > Best regards,
> >> > Thiago Presa
> >> > _______________________________________________
> >> > keycloak-user mailing list
> >> > keycloak-user at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
>
>
>
> --
>
> --Hynek
>

From rationull at gmail.com  Thu Jul 20 18:31:47 2017
From: rationull at gmail.com (Jonathan Little)
Date: Thu, 20 Jul 2017 15:31:47 -0700
Subject: [keycloak-user] Updating Default Admin-Initiated Action Lifespan
In-Reply-To: <CAMvXD=Fd4DJTUWnD-HzZQN9Xag9ZuWL0534b=tvjXbd_EjQCFA@mail.gmail.com>
References: <CALLLnfWOKX1=_v5VCa2uWeNWo3VSQVgmJiv6qEPoiH_mc-z=9w@mail.gmail.com>
	<CAMvXD=Fd4DJTUWnD-HzZQN9Xag9ZuWL0534b=tvjXbd_EjQCFA@mail.gmail.com>
Message-ID: <CALLLnfUZy0K4c3AYK1shF2+_gDjnEHCJBVDff+y+ApB9ifTCkA@mail.gmail.com>

Ack -- well that would be why then! Thanks.

On Wed, Jul 19, 2017 at 11:48 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> These options were added in 3.2.0.
>
> --Hynek
>
> On Thu, Jul 20, 2017 at 1:35 AM, Jonathan Little <rationull at gmail.com>
> wrote:
> > Maybe I'm being dense but how do you change the Default Admin-Initiated
> > Action Lifespan? It's documented here:
> >
> > https://keycloak.gitbooks.io/documentation/server_admin/
> topics/sessions/timeouts.html
> >
> > but even in that documentation the screenshot does not show those options
> > present. They are not present in the UI as far as I can tell. I'm running
> > 3.1.0.
> >
> > What am I missing?
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> --Hynek
>

From John.Craft at geocent.com  Thu Jul 20 21:28:03 2017
From: John.Craft at geocent.com (John Craft)
Date: Fri, 21 Jul 2017 01:28:03 +0000
Subject: [keycloak-user] Server 2016 ADFS won't accept descriptor
Message-ID: <F32C3FA1-E14B-42A5-9FF3-36AB25D32A2F@geocent.com>

I've installed Windows Server 2016 with ADFS.  When I try to create the trust as per the Keycloak help docs, ADFS reports the descriptor as malformed.  Anybody had experience with this?

John Craft
Senior Software Engineer, GISP
Geocent, LLC
Cell : 601-299-1830
Stennis Space Center MS
www.geocent.com | John.Craft at Geocent.com

Confidentiality Notice:
This email communication may contain confidential information, may be legally privileged, and is intended only for the use of the intended recipients(s) identified. Any unauthorized review, use, distribution, downloading, or copying of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, immediately notify the sender by reply email, delete the communication, and destroy all copies. Thank you.


From mevans at aconex.com  Fri Jul 21 01:57:38 2017
From: mevans at aconex.com (Matt Evans)
Date: Fri, 21 Jul 2017 05:57:38 +0000
Subject: [keycloak-user] When should auth_time claim be updated?
Message-ID: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>

Hi

We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.

Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.

However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.

Is this intended behaviour?

Thanks

Matt

From redmitry at list.ru  Fri Jul 21 07:48:36 2017
From: redmitry at list.ru (Dmitry Repchevsky)
Date: Fri, 21 Jul 2017 13:48:36 +0200
Subject: [keycloak-user] Multiple LDAP Providers
Message-ID: <09ac713b-010a-6874-2ad0-59d78ef9211f@list.ru>

Hello,

Is there any way to define different user profiles to be stored in LDAP?
I would like to distinguish between local users and users that come from 
Google.
The user groups should be different (with different attributes). For 
instance local users have "homeDirectory" and "google" ones are treated 
as "guests".

If I define two LDAP "WRITABLE" providers the attempt to write the new 
user to LDAP is done by priority order, right?
I mean if I define a mandatory "homeDirectory" attribute and "google" 
user has no this attribute, the user is stored in the second provider?

Thank you in advance,

Dmitry


From mposolda at redhat.com  Fri Jul 21 10:36:31 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Jul 2017 16:36:31 +0200
Subject: [keycloak-user] Keycloak 3.2.1.Final released
Message-ID: <d27477dc-fac7-44d2-3341-61815ef6cebb@redhat.com>

Keycloak 3.2.1.Final has just been released.

This release doesn't contain any new features. However there are few 
fixed bugs related to authorization services and new permissions for 
admin REST API.

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

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

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


From olivier.nappert at thalesgroup.com  Fri Jul 21 10:38:06 2017
From: olivier.nappert at thalesgroup.com (NAPPERT Olivier)
Date: Fri, 21 Jul 2017 16:38:06 +0200
Subject: [keycloak-user] Keycloak OpenIDConnect bearer token problem
Message-ID: <214AE1E82329484FBEA49BB83551A5E5330C7809F9@THSONEA01CMS06P.one.grp>

Hello,

I am trying to use Keycloak v3.2 standalone (Final) as an OpenID Connect Identity Provider, with an instance of LemonLDAP::NG working as my OIDC Relying Party. The latter is already configured and works well with multiple OIDC Identity Providers, like Google or other LL::NG instances.

When accessing the Keycloak token endpoint, the authentication fails with the following message :


Token type is bearer but must be Bearer
[perl:debug] CGI.pm(114): /usr/share/perl5/Lemonldap/NG/Portal/AuthOpenIDConnect.pm 133:
[perl:error] Token response is not valid


Do you know how to change the token type sent in the Keycloak configuration please ? From my understanding the OpenID Connect standard states that the Token type MUST be Bearer, so I suspect that I'm not the first who's had this problem.

Best regards,

Olivier NAPPERT


From mposolda at redhat.com  Fri Jul 21 10:42:47 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Jul 2017 16:42:47 +0200
Subject: [keycloak-user] Multiple LDAP Providers
In-Reply-To: <09ac713b-010a-6874-2ad0-59d78ef9211f@list.ru>
References: <09ac713b-010a-6874-2ad0-59d78ef9211f@list.ru>
Message-ID: <cf218ac5-45d9-08e4-c7d3-85f08c78f032@redhat.com>

On 21/07/17 13:48, Dmitry Repchevsky wrote:
> Hello,
>
> Is there any way to define different user profiles to be stored in LDAP?
> I would like to distinguish between local users and users that come from
> Google.
> The user groups should be different (with different attributes). For
> instance local users have "homeDirectory" and "google" ones are treated
> as "guests".
>
> If I define two LDAP "WRITABLE" providers the attempt to write the new
> user to LDAP is done by priority order, right?
Yes, right. It all depends on priority right now.

We have opened JIRA for the case when you want to add social users 
locally or to specified user Storage provider (not the default one with 
biggest priority). It's not yet available OOTB. However you can achieve 
something if you define firstBrokerLogin flow and replace 
IdpCreateUserIfUniqueAuthenticator with something else, which will 
register user either locally or to different LDAP provider that the one 
with biggest priority. But you would need to code that.

Marek
> I mean if I define a mandatory "homeDirectory" attribute and "google"
> user has no this attribute, the user is stored in the second provider?
>
> Thank you in advance,
>
> Dmitry
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Fri Jul 21 10:45:23 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Jul 2017 16:45:23 +0200
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
Message-ID: <9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>

On 21/07/17 07:57, Matt Evans wrote:
> Hi
>
> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>
> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>
> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>
> Is this intended behaviour?
Yes. The claim "auth_time" points to the time of the active 
authentication. And the re-authentication with SSO cookie is not treated 
as "active" authentication, so this won't update auth_time. With 
"prompt=login" you need actively authenticate, so that will update 
auth_time.

Marek
>
> Thanks
>
> Matt
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From redmitry at list.ru  Fri Jul 21 11:06:18 2017
From: redmitry at list.ru (Dmitry Repchevsky)
Date: Fri, 21 Jul 2017 17:06:18 +0200
Subject: [keycloak-user] Multiple LDAP Providers
In-Reply-To: <cf218ac5-45d9-08e4-c7d3-85f08c78f032@redhat.com>
References: <09ac713b-010a-6874-2ad0-59d78ef9211f@list.ru>
	<cf218ac5-45d9-08e4-c7d3-85f08c78f032@redhat.com>
Message-ID: <c4c28561-3fe4-bcb1-5e05-aa4d7f887fd6@list.ru>

Hello Marek,

Thank you for the prompt answer.

My current idea is to make first LDAP expect a "social" attribute which 
I hardcode for "google" provider.
Other users (registered via cli or rest) will fail on it and move to the 
second LDAP which is for the local users.

Dmitry

On 7/21/2017 4:42 PM, Marek Posolda wrote:
> On 21/07/17 13:48, Dmitry Repchevsky wrote:
>> Hello,
>>
>> Is there any way to define different user profiles to be stored in LDAP?
>> I would like to distinguish between local users and users that come from
>> Google.
>> The user groups should be different (with different attributes). For
>> instance local users have "homeDirectory" and "google" ones are treated
>> as "guests".
>>
>> If I define two LDAP "WRITABLE" providers the attempt to write the new
>> user to LDAP is done by priority order, right?
> Yes, right. It all depends on priority right now.
>
> We have opened JIRA for the case when you want to add social users 
> locally or to specified user Storage provider (not the default one 
> with biggest priority). It's not yet available OOTB. However you can 
> achieve something if you define firstBrokerLogin flow and replace 
> IdpCreateUserIfUniqueAuthenticator with something else, which will 
> register user either locally or to different LDAP provider that the 
> one with biggest priority. But you would need to code that.
>
> Marek
>> I mean if I define a mandatory "homeDirectory" attribute and "google"
>> user has no this attribute, the user is stored in the second provider?
>>
>> Thank you in advance,
>>
>> Dmitry
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>


From olivier.nappert at thalesgroup.com  Fri Jul 21 11:39:38 2017
From: olivier.nappert at thalesgroup.com (NAPPERT Olivier)
Date: Fri, 21 Jul 2017 17:39:38 +0200
Subject: [keycloak-user] Keycloak OpenIDConnect bearer token problem
Message-ID: <214AE1E82329484FBEA49BB83551A5E5330C780B2D@THSONEA01CMS06P.one.grp>

I searched more and found the RFC that specifies the OAuth2 specifications for Token_type, it should be case insensitive as specified here https://tools.ietf.org/html/rfc6749#section-4.2.2 :

"token_type
         REQUIRED.  The type of the token issued as described in
         Section 7.1<https://tools.ietf.org/html/rfc6749#section-7.1>.  Value is case insensitive."

But in LemonLDAP::NG, the file that verifies if the token is valid isn't compliant with this because of the following line in /usr/share/perl5/Lemonldap/NG/Portal/_OpenIDConnect.pm:465 :


"unless ( $json->{token_type} eq "Bearer" ) {"

So in fact it wasn't a problem on Keycloak's side, but LL::NG.

Best regards,

Olivier Nappert


De : NAPPERT Olivier
Envoy? : vendredi 21 juillet 2017 16:38
? : 'keycloak-user at lists.jboss.org'
Objet : Keycloak OpenIDConnect bearer token problem

Hello,

I am trying to use Keycloak v3.2 standalone (Final) as an OpenID Connect Identity Provider, with an instance of LemonLDAP::NG working as my OIDC Relying Party. The latter is already configured and works well with multiple OIDC Identity Providers, like Google or other LL::NG instances.

When accessing the Keycloak token endpoint, the authentication fails with the following message :


Token type is bearer but must be Bearer
[perl:debug] CGI.pm(114): /usr/share/perl5/Lemonldap/NG/Portal/AuthOpenIDConnect.pm 133:
[perl:error] Token response is not valid


Do you know how to change the token type sent in the Keycloak configuration please ? From my understanding the OpenID Connect standard states that the Token type MUST be Bearer, so I suspect that I'm not the first who's had this problem.

Best regards,

Olivier NAPPERT


From redmitry at list.ru  Fri Jul 21 14:30:57 2017
From: redmitry at list.ru (Dmitry Repchevsky)
Date: Fri, 21 Jul 2017 20:30:57 +0200
Subject: [keycloak-user] Make "hardcoded-ldap-attribute-mapper" both way.
Message-ID: <f8b0f39b-e95d-abca-f8e9-cca37e6d8b24@list.ru>

Hello,

According the tooltip "hardcoded-ldap-attribute-mapper" is for putting 
the hardcoded attribute to the LDAP.
How can I hardcode a user attribute when reading from LDAP? (I want to 
know whether the user comes from LDAP).

Kind regards,

Dmitry


From viggo.navarsete at gmail.com  Sat Jul 22 12:02:05 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sat, 22 Jul 2017 16:02:05 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable container
	must be specified
Message-ID: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>

Hi,

I'm new to Keycloak, and have just started to familiarize with the
tutorials. I've cloned the quickstarters and started with the
service-jee-jarxrs.

I *think* I've followed all the instructions there, but still it fails
while trying to both run the tests and deploy it.

I've attached the output and hope someone are kind enough to take a look at
it:) I think Keycloak looks great, but please help me over the first bump
here :)

Best regards,
Viggo

From sblanc at redhat.com  Sat Jul 22 14:56:43 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sat, 22 Jul 2017 20:56:43 +0200
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
Message-ID: <CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>

Hi,

Looks like the attachments didn't make it, make can you paste it in a gist
or something like that,

Seb


On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <viggo.navarsete at gmail.com>
wrote:

> Hi,
>
> I'm new to Keycloak, and have just started to familiarize with the
> tutorials. I've cloned the quickstarters and started with the
> service-jee-jarxrs.
>
> I *think* I've followed all the instructions there, but still it fails
> while trying to both run the tests and deploy it.
>
> I've attached the output and hope someone are kind enough to take a look at
> it:) I think Keycloak looks great, but please help me over the first bump
> here :)
>
> Best regards,
> Viggo
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From viggo.navarsete at gmail.com  Sat Jul 22 17:59:36 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sat, 22 Jul 2017 21:59:36 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
Message-ID: <CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>

Hi,

sorry for the missing attachment. Here is the gist:
https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93

Regards,
Viggo

On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi,
>
> Looks like the attachments didn't make it, make can you paste it in a gist
> or something like that,
>
> Seb
>
>
> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
> viggo.navarsete at gmail.com> wrote:
>
>> Hi,
>>
>> I'm new to Keycloak, and have just started to familiarize with the
>> tutorials. I've cloned the quickstarters and started with the
>> service-jee-jarxrs.
>>
>> I *think* I've followed all the instructions there, but still it fails
>> while trying to both run the tests and deploy it.
>>
>> I've attached the output and hope someone are kind enough to take a look
>> at
>> it:) I think Keycloak looks great, but please help me over the first bump
>> here :)
>>
>> Best regards,
>> Viggo
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From sblanc at redhat.com  Sat Jul 22 18:06:11 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sat, 22 Jul 2017 22:06:11 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
Message-ID: <CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>

What is the command you issued ?

Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <viggo.navarsete at gmail.com>
a ?crit :

> Hi,
>
> sorry for the missing attachment. Here is the gist:
> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>
> Regards,
> Viggo
>
> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> Hi,
>>
>> Looks like the attachments didn't make it, make can you paste it in a
>> gist or something like that,
>>
>> Seb
>>
>>
>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm new to Keycloak, and have just started to familiarize with the
>>> tutorials. I've cloned the quickstarters and started with the
>>> service-jee-jarxrs.
>>>
>>> I *think* I've followed all the instructions there, but still it fails
>>> while trying to both run the tests and deploy it.
>>>
>>> I've attached the output and hope someone are kind enough to take a look
>>> at
>>> it:) I think Keycloak looks great, but please help me over the first bump
>>> here :)
>>>
>>> Best regards,
>>> Viggo
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>

From viggo.navarsete at gmail.com  Sat Jul 22 18:16:39 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sat, 22 Jul 2017 22:16:39 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
Message-ID: <CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>

mvn install wildfly:deploy

On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com> wrote:

> What is the command you issued ?
>
> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <viggo.navarsete at gmail.com>
> a ?crit :
>
>> Hi,
>>
>> sorry for the missing attachment. Here is the gist:
>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>
>> Regards,
>> Viggo
>>
>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Looks like the attachments didn't make it, make can you paste it in a
>>> gist or something like that,
>>>
>>> Seb
>>>
>>>
>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>> tutorials. I've cloned the quickstarters and started with the
>>>> service-jee-jarxrs.
>>>>
>>>> I *think* I've followed all the instructions there, but still it fails
>>>> while trying to both run the tests and deploy it.
>>>>
>>>> I've attached the output and hope someone are kind enough to take a
>>>> look at
>>>> it:) I think Keycloak looks great, but please help me over the first
>>>> bump
>>>> here :)
>>>>
>>>> Best regards,
>>>> Viggo
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>

From viggo.navarsete at gmail.com  Sun Jul 23 06:17:14 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 10:17:14 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
Message-ID: <CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>

Are you able to run the same tutorials from your side?

- I'm using Maven 3.2.5, JDK 1.8.0_131
- I've started keycloack server (3.2.1.Final) with this command:
 ./standalone.sh -Djboss.socket.binding.port-offset=100
- I've started Wildfly server (10.1.0.Final) with this command:
./standalone.sh
- I've installed the client adapter for Wildfly 10 for Linux:
https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
- I've configured a Client in Keycloak, and the file I've downloaded and
put into the config directory of the tutorial looks like this:
{
  "realm": "master",
  "bearer-only": true,
  "auth-server-url": "http://localhost:8180/auth",
  "ssl-required": "external",
  "resource": "service-jaxrs",
  "enable-cors": true
}

- I've added an admin user, viggis75, to Keycloak
- I've added a "user" role, and also assigned it to viggis75
- The admin user, viggis75, is refered to in the test:
    static {
        try {
            TestsHelper.appName = "test-demo";
            TestsHelper.baseUrl = "http://localhost:8080/test-demo";
            TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; // The
URL Keycloak runs at
            importTestRealm("viggis75", "mypassword",
"/quickstart-realm.json");
            createDirectGrantClient();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

If I run this command: mvn clean install -Pwildfly-managed
-Denforcer.skip=true
I get this:
https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91

if I run this command: mvn install wildfly:deploy
I get this:
https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7

I've tried to reinstall both Wildfly and Keycloak and do everything from
scratch, but end up with the same result each time, so I wonder what I'm
missing...

Regards,
Viggo

On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <viggo.navarsete at gmail.com>
wrote:

> mvn install wildfly:deploy
>
> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> What is the command you issued ?
>>
>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <viggo.navarsete at gmail.com>
>> a ?crit :
>>
>>> Hi,
>>>
>>> sorry for the missing attachment. Here is the gist:
>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>
>>> Regards,
>>> Viggo
>>>
>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Looks like the attachments didn't make it, make can you paste it in a
>>>> gist or something like that,
>>>>
>>>> Seb
>>>>
>>>>
>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>> service-jee-jarxrs.
>>>>>
>>>>> I *think* I've followed all the instructions there, but still it fails
>>>>> while trying to both run the tests and deploy it.
>>>>>
>>>>> I've attached the output and hope someone are kind enough to take a
>>>>> look at
>>>>> it:) I think Keycloak looks great, but please help me over the first
>>>>> bump
>>>>> here :)
>>>>>
>>>>> Best regards,
>>>>> Viggo
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>

From sblanc at redhat.com  Sun Jul 23 06:28:03 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 23 Jul 2017 12:28:03 +0200
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
Message-ID: <CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>

On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <viggo.navarsete at gmail.com
> wrote:

> Are you able to run the same tutorials from your side?
>
> - I'm using Maven 3.2.5, JDK 1.8.0_131
> - I've started keycloack server (3.2.1.Final) with this command:
>  ./standalone.sh -Djboss.socket.binding.port-offset=100
> - I've started Wildfly server (10.1.0.Final) with this command:
> ./standalone.sh
> - I've installed the client adapter for Wildfly 10 for Linux:
> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/
> keycloak-wildfly-adapter-dist-3.2.1.Final.zip
> - I've configured a Client in Keycloak, and the file I've downloaded and
> put into the config directory of the tutorial looks like this:
> {
>   "realm": "master",
>   "bearer-only": true,
>   "auth-server-url": "http://localhost:8180/auth",
>   "ssl-required": "external",
>   "resource": "service-jaxrs",
>   "enable-cors": true
> }
>
> - I've added an admin user, viggis75, to Keycloak
> - I've added a "user" role, and also assigned it to viggis75
> - The admin user, viggis75, is refered to in the test:
>     static {
>         try {
>             TestsHelper.appName = "test-demo";
>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; //
> The URL Keycloak runs at
>             importTestRealm("viggis75", "mypassword",
> "/quickstart-realm.json");
>             createDirectGrantClient();
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
>
> If I run this command: mvn clean install -Pwildfly-managed
> -Denforcer.skip=true
> I get this:  https://gist.github.com/anonymous/
> adb0d9699a5012b2e9f65e7ed22a7c91
>
This is failing because you have already manually started a Wildfly and
this is conflicting with the one that arquillian will start. If you don't
bother about the integration tests you can run :

 mvn clean install -DskipTests -Denforcer.skip=true

This will create the WARs that you can then deploy.


>
> if I run this command: mvn install wildfly:deploy
> I get this: https://gist.github.com/anonymous/
> c39610ee19b73e57daed542973bf0ed7
>
> I've tried to reinstall both Wildfly and Keycloak and do everything from
> scratch, but end up with the same result each time, so I wonder what I'm
> missing...
>
> Regards,
> Viggo
>
> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
> viggo.navarsete at gmail.com> wrote:
>
>> mvn install wildfly:deploy
>>
>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> What is the command you issued ?
>>>
>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>> viggo.navarsete at gmail.com> a ?crit :
>>>
>>>> Hi,
>>>>
>>>> sorry for the missing attachment. Here is the gist:
>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>
>>>> Regards,
>>>> Viggo
>>>>
>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Looks like the attachments didn't make it, make can you paste it in a
>>>>> gist or something like that,
>>>>>
>>>>> Seb
>>>>>
>>>>>
>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>> service-jee-jarxrs.
>>>>>>
>>>>>> I *think* I've followed all the instructions there, but still it fails
>>>>>> while trying to both run the tests and deploy it.
>>>>>>
>>>>>> I've attached the output and hope someone are kind enough to take a
>>>>>> look at
>>>>>> it:) I think Keycloak looks great, but please help me over the first
>>>>>> bump
>>>>>> here :)
>>>>>>
>>>>>> Best regards,
>>>>>> Viggo
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>
>>>>>

From cschneiderpublic at gmail.com  Sun Jul 23 06:51:41 2017
From: cschneiderpublic at gmail.com (Christian Schneider)
Date: Sun, 23 Jul 2017 10:51:41 +0000
Subject: [keycloak-user] Keycloak standalone-ha cluster jgroups without
	multicast
Message-ID: <CAJv_xg-RFgco=gCJxOZ6AUdJ79fh=mEjk-vgyMt8jSnrSEwB8w@mail.gmail.com>

Hi,
I'm trying to setup a keycloak cluster.

We copy binaries and configuration through our build pipeline to the
servers, so we decided to for the "standalone clustered mode".

Since our operations don't enable ip multicast, we wan't to work with ip
static ip addresses.

The only source for this I found is:
https://kb.novaordis.com/index.php/WildFly_Clustering_without_Multicast
<https://deref-gmx.net/mail/client/Wiot_0qYjM4/dereferrer/?redirectUrl=https%3A%2F%2Fkb.novaordis.com%2Findex.php%2FWildFly_Clustering_without_Multicast>

I configured both servers like this:

        <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
            <channels default="ee">
                <channel name="ee" stack="tcp"/>
            </channels>
            <stacks default="tcp">
                <stack name="tcp">
                    <transfer type="TCP" socket-binding="jgroups-tcp"/>
                    <protocol type="TCPPING">
                        <property
name="initial_hosts">10.62.168.51[7600],10.62.168.52[7600]</property>
                        <property name="num_initial_members">2</property>
                        <property name="port_range">0</property>
                        <property name="timeout">2000</property>
                    </protocol>
                    <protocol type="MERGE3"/>
                    <protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd"/>
                    <protocol type="FD"/>
                    <protocol type="VERIFY_SUSPECT"/>
                    <protocol type="pbcast.NAKACK2"/>
                    <protocol type="UNICAST3"/>
                    <protocol type="pbcast.STABLE"/>
                    <protocol type="pbcast.GMS"/>
                    <protocol type="MFC"/>
                    <protocol type="FRAG2"/>
                </stack>
            </stacks>
        </subsystem>

I can't figure out whether the two nodes paired each other. In the logfile
I only find this:

INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
Starting JGroups channel hibernate
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
Starting JGroups channel web
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
Starting JGroups channel keycloak
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
Starting JGroups channel ejb
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
Starting JGroups channel server
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
Received new cluster view for channel keycloak: [app02.2.xxx.net|0] (1) [
app02.2.xxx.net]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
Received new cluster view for channel hibernate: [app02.2.xxx.net|0] (1) [
app02.2.xxx.net]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
Received new cluster view for channel ejb: [app02.2.xxx.net|0] (1) [
app02.2.xxx.net]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
Received new cluster view for channel server: [app02.2.xxx.net|0] (1) [
app02.2.xxx.net]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
Received new cluster view for channel web: [app02.2.xxx.net|0] (1) [
app02.2.xxx.net]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
Channel server local address is app02.2.xxx.net, physical addresses are [
127.0.0.1:7600]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
Channel ejb local address is app02.2.xxx.net, physical addresses are [
127.0.0.1:7600]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
Channel web local address is app02.2.xxx.net, physical addresses are [
127.0.0.1:7600]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
Channel keycloak local address is app02.2.xxx.net, physical addresses are [
127.0.0.1:7600]
INFO  2017-07-21 20:35:43 []
org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
Channel hibernate local address is app02.2.xxx.net, physical addresses are [
127.0.0.1:7600

I checked that the ports 7060 are open.
When I access just a single node, the setup works fine. With two nodes I
get {"error":"invalid_grant","error_description":"Session not active"} on
one of them.
The goal is that all userSessions are synced between the cluster nodes, so
that the loadbalancer can roundrobbin between all nodes.
Since we have around 20k users only, it would be fine to store the users in
our database. But keycloak doesn't provide this, right?
Do you have any idea how to figure out whats wrong?

Best Regards,
Christian.

P.S.: You can find the whole configuration here:
https://pastebin.com/WC46pXGp
<https://deref-gmx.net/mail/client/UIuwfhWwMZ0/dereferrer/?redirectUrl=https%3A%2F%2Fpastebin.com%2FWC46pXGp>

From Jesus.Bernal at checkit.net  Sun Jul 23 13:56:29 2017
From: Jesus.Bernal at checkit.net (Jesus Bernal)
Date: Sun, 23 Jul 2017 17:56:29 +0000
Subject: [keycloak-user] Be able to define an email template per action when
 using resource execute-actions-email endpoint
References: <E6D09C37-3F0F-4FAF-A7D8-CBCB544E050A@checkit.net>
Message-ID: <001C60AC-94C4-40A4-AB61-F1570649F1BB@checkit.net>

Is there a way to define a mail per action invoked by execute-actions endpoint over a user?

I can find a generic executeAction mail, however, the actions you are able to trigger can be quite different (from update password to verify mail or terms and conditions) and hence, the need to provide a different mail content for each of them.

Also, I have been looking for how to grab the action in the mail template so I can render a different message based on it. However, as per the documentation only realm, user, clientId, link and expiration are available.

Thanks a lot in advance,

Best Regards,

Jesus Bernal

Senior Software Engineer
jesus.bernal at checkit.net<mailto:jesus.bernal at checkit.net>

Elektron Technology
Broers Building, JJ Thomson Avenue, Cambridge, CB3 0FA, UK
www.elektron-technology.com<http://www.elektron-technology.com/>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

From viggo.navarsete at gmail.com  Sun Jul 23 15:17:13 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:17:13 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
Message-ID: <CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>

Thanks Sebastian,

indeed, the running Wildfly caused the tests to fail, so as soon as I
stopped the server they (at least) ran further :)

I then tried to deploy the service.war from the target directory into
Wildfly from the console, but ended up with this error in the console:
Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
{"jboss.undertow.deployment.default-server.default-host./service" =>
"org.jboss.msc.service.StartException in service
jboss.undertow.deployment.default-server.default-host./service:
java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
java.lang.RuntimeException: UT010039: Unknown authentication mechanism
KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
are not installed:" =>
["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
Services with missing/unavailable dependencies" => undefined}

Any clue here?

Regards,
Viggo

On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
> viggo.navarsete at gmail.com> wrote:
>
>> Are you able to run the same tutorials from your side?
>>
>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>> - I've started keycloack server (3.2.1.Final) with this command:
>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>> - I've started Wildfly server (10.1.0.Final) with this command:
>> ./standalone.sh
>> - I've installed the client adapter for Wildfly 10 for Linux:
>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>> - I've configured a Client in Keycloak, and the file I've downloaded and
>> put into the config directory of the tutorial looks like this:
>> {
>>   "realm": "master",
>>   "bearer-only": true,
>>   "auth-server-url": "http://localhost:8180/auth",
>>   "ssl-required": "external",
>>   "resource": "service-jaxrs",
>>   "enable-cors": true
>> }
>>
>> - I've added an admin user, viggis75, to Keycloak
>> - I've added a "user" role, and also assigned it to viggis75
>> - The admin user, viggis75, is refered to in the test:
>>     static {
>>         try {
>>             TestsHelper.appName = "test-demo";
>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; //
>> The URL Keycloak runs at
>>             importTestRealm("viggis75", "mypassword",
>> "/quickstart-realm.json");
>>             createDirectGrantClient();
>>         } catch (Exception e) {
>>             e.printStackTrace();
>>         }
>>     }
>>
>> If I run this command: mvn clean install -Pwildfly-managed
>> -Denforcer.skip=true
>> I get this:
>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>
> This is failing because you have already manually started a Wildfly and
> this is conflicting with the one that arquillian will start. If you don't
> bother about the integration tests you can run :
>
>  mvn clean install -DskipTests -Denforcer.skip=true
>
> This will create the WARs that you can then deploy.
>
>
>>
>> if I run this command: mvn install wildfly:deploy
>> I get this:
>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>
>> I've tried to reinstall both Wildfly and Keycloak and do everything from
>> scratch, but end up with the same result each time, so I wonder what I'm
>> missing...
>>
>> Regards,
>> Viggo
>>
>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> mvn install wildfly:deploy
>>>
>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> What is the command you issued ?
>>>>
>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>
>>>>> Hi,
>>>>>
>>>>> sorry for the missing attachment. Here is the gist:
>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>
>>>>> Regards,
>>>>> Viggo
>>>>>
>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Looks like the attachments didn't make it, make can you paste it in a
>>>>>> gist or something like that,
>>>>>>
>>>>>> Seb
>>>>>>
>>>>>>
>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>> service-jee-jarxrs.
>>>>>>>
>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>> fails
>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>
>>>>>>> I've attached the output and hope someone are kind enough to take a
>>>>>>> look at
>>>>>>> it:) I think Keycloak looks great, but please help me over the first
>>>>>>> bump
>>>>>>> here :)
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Viggo
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>

From sblanc at redhat.com  Sun Jul 23 15:30:25 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 23 Jul 2017 19:30:25 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
Message-ID: <CAMZCGg-z2GOcP4heRP7S3zoXcDcSh2kuBb1om-tXYsBejwB5qw@mail.gmail.com>

>From the error message looks like you haven't installed correctly the
keycloak adapter in wildfly.

Le dim. 23 juil. 2017 ? 21:17, Viggo Navarsete <viggo.navarsete at gmail.com>
a ?crit :

> Thanks Sebastian,
>
> indeed, the running Wildfly caused the tests to fail, so as soon as I
> stopped the server they (at least) ran further :)
>
> I then tried to deploy the service.war from the target directory into
> Wildfly from the console, but ended up with this error in the console:
> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
> {"jboss.undertow.deployment.default-server.default-host./service" =>
> "org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./service:
> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
> are not installed:" =>
> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
> Services with missing/unavailable dependencies" => undefined}
>
> Any clue here?
>
> Regards,
> Viggo
>
> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Are you able to run the same tutorials from your side?
>>>
>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>> ./standalone.sh
>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>> - I've configured a Client in Keycloak, and the file I've downloaded and
>>> put into the config directory of the tutorial looks like this:
>>> {
>>>   "realm": "master",
>>>   "bearer-only": true,
>>>   "auth-server-url": "http://localhost:8180/auth",
>>>   "ssl-required": "external",
>>>   "resource": "service-jaxrs",
>>>   "enable-cors": true
>>> }
>>>
>>> - I've added an admin user, viggis75, to Keycloak
>>> - I've added a "user" role, and also assigned it to viggis75
>>> - The admin user, viggis75, is refered to in the test:
>>>     static {
>>>         try {
>>>             TestsHelper.appName = "test-demo";
>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; //
>>> The URL Keycloak runs at
>>>             importTestRealm("viggis75", "mypassword",
>>> "/quickstart-realm.json");
>>>             createDirectGrantClient();
>>>         } catch (Exception e) {
>>>             e.printStackTrace();
>>>         }
>>>     }
>>>
>>> If I run this command: mvn clean install -Pwildfly-managed
>>> -Denforcer.skip=true
>>> I get this:
>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>
>> This is failing because you have already manually started a Wildfly and
>> this is conflicting with the one that arquillian will start. If you don't
>> bother about the integration tests you can run :
>>
>>  mvn clean install -DskipTests -Denforcer.skip=true
>>
>> This will create the WARs that you can then deploy.
>>
>>
>>>
>>> if I run this command: mvn install wildfly:deploy
>>> I get this:
>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>
>>> I've tried to reinstall both Wildfly and Keycloak and do everything from
>>> scratch, but end up with the same result each time, so I wonder what I'm
>>> missing...
>>>
>>> Regards,
>>> Viggo
>>>
>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> mvn install wildfly:deploy
>>>>
>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> What is the command you issued ?
>>>>>
>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>
>>>>>> Regards,
>>>>>> Viggo
>>>>>>
>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Looks like the attachments didn't make it, make can you paste it in
>>>>>>> a gist or something like that,
>>>>>>>
>>>>>>> Seb
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>> service-jee-jarxrs.
>>>>>>>>
>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>> fails
>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>
>>>>>>>> I've attached the output and hope someone are kind enough to take a
>>>>>>>> look at
>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>> first bump
>>>>>>>> here :)
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Viggo
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 15:31:07 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:31:07 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
Message-ID: <CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>

Update: I read another post where someone else also had issues deploying
the examples to a "vanilla Wildfly instance" and got the recommendation to
deploy them to the Keycloak server (which is a Wildfly with Keycloak
installed). I tried this, and the example worked, but then I wonder: Isn't
it normal to have Keycloack running on a separate instance?



On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <viggo.navarsete at gmail.com>
wrote:

> Thanks Sebastian,
>
> indeed, the running Wildfly caused the tests to fail, so as soon as I
> stopped the server they (at least) ran further :)
>
> I then tried to deploy the service.war from the target directory into
> Wildfly from the console, but ended up with this error in the console:
> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
> {"jboss.undertow.deployment.default-server.default-host./service" =>
> "org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./service:
> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
> are not installed:" =>
> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
> Services with missing/unavailable dependencies" => undefined}
>
> Any clue here?
>
> Regards,
> Viggo
>
> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Are you able to run the same tutorials from your side?
>>>
>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>> ./standalone.sh
>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>> - I've configured a Client in Keycloak, and the file I've downloaded and
>>> put into the config directory of the tutorial looks like this:
>>> {
>>>   "realm": "master",
>>>   "bearer-only": true,
>>>   "auth-server-url": "http://localhost:8180/auth",
>>>   "ssl-required": "external",
>>>   "resource": "service-jaxrs",
>>>   "enable-cors": true
>>> }
>>>
>>> - I've added an admin user, viggis75, to Keycloak
>>> - I've added a "user" role, and also assigned it to viggis75
>>> - The admin user, viggis75, is refered to in the test:
>>>     static {
>>>         try {
>>>             TestsHelper.appName = "test-demo";
>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; //
>>> The URL Keycloak runs at
>>>             importTestRealm("viggis75", "mypassword",
>>> "/quickstart-realm.json");
>>>             createDirectGrantClient();
>>>         } catch (Exception e) {
>>>             e.printStackTrace();
>>>         }
>>>     }
>>>
>>> If I run this command: mvn clean install -Pwildfly-managed
>>> -Denforcer.skip=true
>>> I get this:
>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>
>> This is failing because you have already manually started a Wildfly and
>> this is conflicting with the one that arquillian will start. If you don't
>> bother about the integration tests you can run :
>>
>>  mvn clean install -DskipTests -Denforcer.skip=true
>>
>> This will create the WARs that you can then deploy.
>>
>>
>>>
>>> if I run this command: mvn install wildfly:deploy
>>> I get this:
>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>
>>> I've tried to reinstall both Wildfly and Keycloak and do everything from
>>> scratch, but end up with the same result each time, so I wonder what I'm
>>> missing...
>>>
>>> Regards,
>>> Viggo
>>>
>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> mvn install wildfly:deploy
>>>>
>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> What is the command you issued ?
>>>>>
>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>
>>>>>> Regards,
>>>>>> Viggo
>>>>>>
>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Looks like the attachments didn't make it, make can you paste it in
>>>>>>> a gist or something like that,
>>>>>>>
>>>>>>> Seb
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>> service-jee-jarxrs.
>>>>>>>>
>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>> fails
>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>
>>>>>>>> I've attached the output and hope someone are kind enough to take a
>>>>>>>> look at
>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>> first bump
>>>>>>>> here :)
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Viggo
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 15:35:21 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:35:21 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
Message-ID: <CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>

When I look here:
https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
I did this:

$ cd bin
$ ./jboss-cli.sh --file=*adapter-install-offline.cli*

but, when I look here:
https://github.com/keycloak/keycloak-quickstarts#keycloak
it seems that it's another adapter that I should have installed?

For Linux:

  WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
  WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload


..so I wonder which guide is the correct?

Regards,
Viggo


On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <viggo.navarsete at gmail.com>
wrote:

> Update: I read another post where someone else also had issues deploying
> the examples to a "vanilla Wildfly instance" and got the recommendation to
> deploy them to the Keycloak server (which is a Wildfly with Keycloak
> installed). I tried this, and the example worked, but then I wonder: Isn't
> it normal to have Keycloack running on a separate instance?
>
>
>
> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <viggo.navarsete at gmail.com>
> wrote:
>
>> Thanks Sebastian,
>>
>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>> stopped the server they (at least) ran further :)
>>
>> I then tried to deploy the service.war from the target directory into
>> Wildfly from the console, but ended up with this error in the console:
>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>> "org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./service:
>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>> are not installed:" =>
>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>> Services with missing/unavailable dependencies" => undefined}
>>
>> Any clue here?
>>
>> Regards,
>> Viggo
>>
>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> Are you able to run the same tutorials from your side?
>>>>
>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>> ./standalone.sh
>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>> - I've configured a Client in Keycloak, and the file I've downloaded
>>>> and put into the config directory of the tutorial looks like this:
>>>> {
>>>>   "realm": "master",
>>>>   "bearer-only": true,
>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>   "ssl-required": "external",
>>>>   "resource": "service-jaxrs",
>>>>   "enable-cors": true
>>>> }
>>>>
>>>> - I've added an admin user, viggis75, to Keycloak
>>>> - I've added a "user" role, and also assigned it to viggis75
>>>> - The admin user, viggis75, is refered to in the test:
>>>>     static {
>>>>         try {
>>>>             TestsHelper.appName = "test-demo";
>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; //
>>>> The URL Keycloak runs at
>>>>             importTestRealm("viggis75", "mypassword",
>>>> "/quickstart-realm.json");
>>>>             createDirectGrantClient();
>>>>         } catch (Exception e) {
>>>>             e.printStackTrace();
>>>>         }
>>>>     }
>>>>
>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>> -Denforcer.skip=true
>>>> I get this:
>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>
>>> This is failing because you have already manually started a Wildfly and
>>> this is conflicting with the one that arquillian will start. If you don't
>>> bother about the integration tests you can run :
>>>
>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>
>>> This will create the WARs that you can then deploy.
>>>
>>>
>>>>
>>>> if I run this command: mvn install wildfly:deploy
>>>> I get this:
>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>
>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>> from scratch, but end up with the same result each time, so I wonder what
>>>> I'm missing...
>>>>
>>>> Regards,
>>>> Viggo
>>>>
>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> mvn install wildfly:deploy
>>>>>
>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> What is the command you issued ?
>>>>>>
>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>
>>>>>>> Regards,
>>>>>>> Viggo
>>>>>>>
>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Looks like the attachments didn't make it, make can you paste it in
>>>>>>>> a gist or something like that,
>>>>>>>>
>>>>>>>> Seb
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>
>>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>>> fails
>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>
>>>>>>>>> I've attached the output and hope someone are kind enough to take
>>>>>>>>> a look at
>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>> first bump
>>>>>>>>> here :)
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Viggo
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>

From sblanc at redhat.com  Sun Jul 23 15:45:55 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 23 Jul 2017 19:45:55 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
Message-ID: <CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>

It's the same , one can be used offline and the other needs wildfly running.


Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <viggo.navarsete at gmail.com>
a ?crit :

> When I look here:
> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
> I did this:
>
> $ cd bin
> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>
> but, when I look here:
> https://github.com/keycloak/keycloak-quickstarts#keycloak
> it seems that it's another adapter that I should have installed?
>
> For Linux:
>
>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>
>
> ..so I wonder which guide is the correct?
>
> Regards,
> Viggo
>
>
> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <viggo.navarsete at gmail.com>
> wrote:
>
>> Update: I read another post where someone else also had issues deploying
>> the examples to a "vanilla Wildfly instance" and got the recommendation to
>> deploy them to the Keycloak server (which is a Wildfly with Keycloak
>> installed). I tried this, and the example worked, but then I wonder: Isn't
>> it normal to have Keycloack running on a separate instance?
>>
>>
>>
>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Thanks Sebastian,
>>>
>>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>>> stopped the server they (at least) ran further :)
>>>
>>> I then tried to deploy the service.war from the target directory into
>>> Wildfly from the console, but ended up with this error in the console:
>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>> "org.jboss.msc.service.StartException in service
>>> jboss.undertow.deployment.default-server.default-host./service:
>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>> are not installed:" =>
>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>> Services with missing/unavailable dependencies" => undefined}
>>>
>>> Any clue here?
>>>
>>> Regards,
>>> Viggo
>>>
>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> Are you able to run the same tutorials from your side?
>>>>>
>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>> ./standalone.sh
>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>> - I've configured a Client in Keycloak, and the file I've downloaded
>>>>> and put into the config directory of the tutorial looks like this:
>>>>> {
>>>>>   "realm": "master",
>>>>>   "bearer-only": true,
>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>   "ssl-required": "external",
>>>>>   "resource": "service-jaxrs",
>>>>>   "enable-cors": true
>>>>> }
>>>>>
>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>     static {
>>>>>         try {
>>>>>             TestsHelper.appName = "test-demo";
>>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>> // The URL Keycloak runs at
>>>>>             importTestRealm("viggis75", "mypassword",
>>>>> "/quickstart-realm.json");
>>>>>             createDirectGrantClient();
>>>>>         } catch (Exception e) {
>>>>>             e.printStackTrace();
>>>>>         }
>>>>>     }
>>>>>
>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>> -Denforcer.skip=true
>>>>> I get this:
>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>
>>>> This is failing because you have already manually started a Wildfly and
>>>> this is conflicting with the one that arquillian will start. If you don't
>>>> bother about the integration tests you can run :
>>>>
>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>
>>>> This will create the WARs that you can then deploy.
>>>>
>>>>
>>>>>
>>>>> if I run this command: mvn install wildfly:deploy
>>>>> I get this:
>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>
>>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>>> from scratch, but end up with the same result each time, so I wonder what
>>>>> I'm missing...
>>>>>
>>>>> Regards,
>>>>> Viggo
>>>>>
>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>
>>>>>> mvn install wildfly:deploy
>>>>>>
>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> What is the command you issued ?
>>>>>>>
>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Viggo
>>>>>>>>
>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Looks like the attachments didn't make it, make can you paste it
>>>>>>>>> in a gist or something like that,
>>>>>>>>>
>>>>>>>>> Seb
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>
>>>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>>>> fails
>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>
>>>>>>>>>> I've attached the output and hope someone are kind enough to take
>>>>>>>>>> a look at
>>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>>> first bump
>>>>>>>>>> here :)
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Viggo
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 15:47:15 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:47:15 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
	<CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
Message-ID: <CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>

hmm...ok:) Then, have you some other clue to why the adapter doesn't seem
to be installed correctly? Should I try the Wildfly 11 adapter instead?



On Sun, Jul 23, 2017 at 9:46 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> It's the same , one can be used offline and the other needs wildfly
> running.
>
>
> Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <viggo.navarsete at gmail.com>
> a ?crit :
>
>> When I look here:
>> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
>> I did this:
>>
>> $ cd bin
>> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>>
>> but, when I look here:
>> https://github.com/keycloak/keycloak-quickstarts#keycloak
>> it seems that it's another adapter that I should have installed?
>>
>> For Linux:
>>
>>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>>
>>
>> ..so I wonder which guide is the correct?
>>
>> Regards,
>> Viggo
>>
>>
>> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Update: I read another post where someone else also had issues deploying
>>> the examples to a "vanilla Wildfly instance" and got the recommendation to
>>> deploy them to the Keycloak server (which is a Wildfly with Keycloak
>>> installed). I tried this, and the example worked, but then I wonder: Isn't
>>> it normal to have Keycloack running on a separate instance?
>>>
>>>
>>>
>>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> Thanks Sebastian,
>>>>
>>>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>>>> stopped the server they (at least) ran further :)
>>>>
>>>> I then tried to deploy the service.war from the target directory into
>>>> Wildfly from the console, but ended up with this error in the console:
>>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>>> "org.jboss.msc.service.StartException in service
>>>> jboss.undertow.deployment.default-server.default-host./service:
>>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>>> are not installed:" =>
>>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>>> Services with missing/unavailable dependencies" => undefined}
>>>>
>>>> Any clue here?
>>>>
>>>> Regards,
>>>> Viggo
>>>>
>>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>
>>>>>> Are you able to run the same tutorials from your side?
>>>>>>
>>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>>> ./standalone.sh
>>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>>> - I've configured a Client in Keycloak, and the file I've downloaded
>>>>>> and put into the config directory of the tutorial looks like this:
>>>>>> {
>>>>>>   "realm": "master",
>>>>>>   "bearer-only": true,
>>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>>   "ssl-required": "external",
>>>>>>   "resource": "service-jaxrs",
>>>>>>   "enable-cors": true
>>>>>> }
>>>>>>
>>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>>     static {
>>>>>>         try {
>>>>>>             TestsHelper.appName = "test-demo";
>>>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>>> // The URL Keycloak runs at
>>>>>>             importTestRealm("viggis75", "mypassword",
>>>>>> "/quickstart-realm.json");
>>>>>>             createDirectGrantClient();
>>>>>>         } catch (Exception e) {
>>>>>>             e.printStackTrace();
>>>>>>         }
>>>>>>     }
>>>>>>
>>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>>> -Denforcer.skip=true
>>>>>> I get this:
>>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>>
>>>>> This is failing because you have already manually started a Wildfly
>>>>> and this is conflicting with the one that arquillian will start. If you
>>>>> don't bother about the integration tests you can run :
>>>>>
>>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>>
>>>>> This will create the WARs that you can then deploy.
>>>>>
>>>>>
>>>>>>
>>>>>> if I run this command: mvn install wildfly:deploy
>>>>>> I get this:
>>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>>
>>>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>>>> from scratch, but end up with the same result each time, so I wonder what
>>>>>> I'm missing...
>>>>>>
>>>>>> Regards,
>>>>>> Viggo
>>>>>>
>>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>
>>>>>>> mvn install wildfly:deploy
>>>>>>>
>>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> What is the command you issued ?
>>>>>>>>
>>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Viggo
>>>>>>>>>
>>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Looks like the attachments didn't make it, make can you paste it
>>>>>>>>>> in a gist or something like that,
>>>>>>>>>>
>>>>>>>>>> Seb
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with
>>>>>>>>>>> the
>>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>>
>>>>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>>>>> fails
>>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>>
>>>>>>>>>>> I've attached the output and hope someone are kind enough to
>>>>>>>>>>> take a look at
>>>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>>>> first bump
>>>>>>>>>>> here :)
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Viggo
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

From sblanc at redhat.com  Sun Jul 23 15:48:07 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 23 Jul 2017 19:48:07 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
Message-ID: <CAMZCGg8yR7pFSAWzdt2yYtPEwDTmiFqvXEGksrwLqtmkx+nOcA@mail.gmail.com>

No this is not a good recommandation, you should always keep your kc server
separate and deploy on another wildfly.
In case you have no choice, we have a kc server overlay for existing
wildfly instances but again it's the best practice

Le dim. 23 juil. 2017 ? 21:31, Viggo Navarsete <viggo.navarsete at gmail.com>
a ?crit :

> Update: I read another post where someone else also had issues deploying
> the examples to a "vanilla Wildfly instance" and got the recommendation to
> deploy them to the Keycloak server (which is a Wildfly with Keycloak
> installed). I tried this, and the example worked, but then I wonder: Isn't
> it normal to have Keycloack running on a separate instance?
>
>
>
> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <viggo.navarsete at gmail.com>
> wrote:
>
>> Thanks Sebastian,
>>
>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>> stopped the server they (at least) ran further :)
>>
>> I then tried to deploy the service.war from the target directory into
>> Wildfly from the console, but ended up with this error in the console:
>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>> "org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./service:
>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>> are not installed:" =>
>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>> Services with missing/unavailable dependencies" => undefined}
>>
>> Any clue here?
>>
>> Regards,
>> Viggo
>>
>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> Are you able to run the same tutorials from your side?
>>>>
>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>> ./standalone.sh
>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>> - I've configured a Client in Keycloak, and the file I've downloaded
>>>> and put into the config directory of the tutorial looks like this:
>>>> {
>>>>   "realm": "master",
>>>>   "bearer-only": true,
>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>   "ssl-required": "external",
>>>>   "resource": "service-jaxrs",
>>>>   "enable-cors": true
>>>> }
>>>>
>>>> - I've added an admin user, viggis75, to Keycloak
>>>> - I've added a "user" role, and also assigned it to viggis75
>>>> - The admin user, viggis75, is refered to in the test:
>>>>     static {
>>>>         try {
>>>>             TestsHelper.appName = "test-demo";
>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180"; //
>>>> The URL Keycloak runs at
>>>>             importTestRealm("viggis75", "mypassword",
>>>> "/quickstart-realm.json");
>>>>             createDirectGrantClient();
>>>>         } catch (Exception e) {
>>>>             e.printStackTrace();
>>>>         }
>>>>     }
>>>>
>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>> -Denforcer.skip=true
>>>> I get this:
>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>
>>> This is failing because you have already manually started a Wildfly and
>>> this is conflicting with the one that arquillian will start. If you don't
>>> bother about the integration tests you can run :
>>>
>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>
>>> This will create the WARs that you can then deploy.
>>>
>>>
>>>>
>>>> if I run this command: mvn install wildfly:deploy
>>>> I get this:
>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>
>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>> from scratch, but end up with the same result each time, so I wonder what
>>>> I'm missing...
>>>>
>>>> Regards,
>>>> Viggo
>>>>
>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> mvn install wildfly:deploy
>>>>>
>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> What is the command you issued ?
>>>>>>
>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>
>>>>>>> Regards,
>>>>>>> Viggo
>>>>>>>
>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Looks like the attachments didn't make it, make can you paste it in
>>>>>>>> a gist or something like that,
>>>>>>>>
>>>>>>>> Seb
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>
>>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>>> fails
>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>
>>>>>>>>> I've attached the output and hope someone are kind enough to take
>>>>>>>>> a look at
>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>> first bump
>>>>>>>>> here :)
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Viggo
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 15:49:53 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:49:53 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg8yR7pFSAWzdt2yYtPEwDTmiFqvXEGksrwLqtmkx+nOcA@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CAMZCGg8yR7pFSAWzdt2yYtPEwDTmiFqvXEGksrwLqtmkx+nOcA@mail.gmail.com>
Message-ID: <CADtfDANBzJFPQtQ35KQSqJ3k036csBOLNB0T3CgmBUNTcv2nAg@mail.gmail.com>

Exactly, then I rather try what we're trying to figure out: Why I can't
deploy the service-jee-jaxrs to my wildfly instance.

On Sun, Jul 23, 2017 at 9:48 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> No this is not a good recommandation, you should always keep your kc
> server separate and deploy on another wildfly.
> In case you have no choice, we have a kc server overlay for existing
> wildfly instances but again it's the best practice
>
> Le dim. 23 juil. 2017 ? 21:31, Viggo Navarsete <viggo.navarsete at gmail.com>
> a ?crit :
>
>> Update: I read another post where someone else also had issues deploying
>> the examples to a "vanilla Wildfly instance" and got the recommendation to
>> deploy them to the Keycloak server (which is a Wildfly with Keycloak
>> installed). I tried this, and the example worked, but then I wonder: Isn't
>> it normal to have Keycloack running on a separate instance?
>>
>>
>>
>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Thanks Sebastian,
>>>
>>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>>> stopped the server they (at least) ran further :)
>>>
>>> I then tried to deploy the service.war from the target directory into
>>> Wildfly from the console, but ended up with this error in the console:
>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>> "org.jboss.msc.service.StartException in service
>>> jboss.undertow.deployment.default-server.default-host./service:
>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>> are not installed:" =>
>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>> Services with missing/unavailable dependencies" => undefined}
>>>
>>> Any clue here?
>>>
>>> Regards,
>>> Viggo
>>>
>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> Are you able to run the same tutorials from your side?
>>>>>
>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>> ./standalone.sh
>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>> - I've configured a Client in Keycloak, and the file I've downloaded
>>>>> and put into the config directory of the tutorial looks like this:
>>>>> {
>>>>>   "realm": "master",
>>>>>   "bearer-only": true,
>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>   "ssl-required": "external",
>>>>>   "resource": "service-jaxrs",
>>>>>   "enable-cors": true
>>>>> }
>>>>>
>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>     static {
>>>>>         try {
>>>>>             TestsHelper.appName = "test-demo";
>>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo";
>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>> // The URL Keycloak runs at
>>>>>             importTestRealm("viggis75", "mypassword",
>>>>> "/quickstart-realm.json");
>>>>>             createDirectGrantClient();
>>>>>         } catch (Exception e) {
>>>>>             e.printStackTrace();
>>>>>         }
>>>>>     }
>>>>>
>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>> -Denforcer.skip=true
>>>>> I get this:
>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>
>>>> This is failing because you have already manually started a Wildfly and
>>>> this is conflicting with the one that arquillian will start. If you don't
>>>> bother about the integration tests you can run :
>>>>
>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>
>>>> This will create the WARs that you can then deploy.
>>>>
>>>>
>>>>>
>>>>> if I run this command: mvn install wildfly:deploy
>>>>> I get this:
>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>
>>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>>> from scratch, but end up with the same result each time, so I wonder what
>>>>> I'm missing...
>>>>>
>>>>> Regards,
>>>>> Viggo
>>>>>
>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>
>>>>>> mvn install wildfly:deploy
>>>>>>
>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> What is the command you issued ?
>>>>>>>
>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Viggo
>>>>>>>>
>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Looks like the attachments didn't make it, make can you paste it
>>>>>>>>> in a gist or something like that,
>>>>>>>>>
>>>>>>>>> Seb
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with the
>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>
>>>>>>>>>> I *think* I've followed all the instructions there, but still it
>>>>>>>>>> fails
>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>
>>>>>>>>>> I've attached the output and hope someone are kind enough to take
>>>>>>>>>> a look at
>>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>>> first bump
>>>>>>>>>> here :)
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Viggo
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

From sblanc at redhat.com  Sun Jul 23 15:49:54 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 23 Jul 2017 19:49:54 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
	<CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
	<CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>
Message-ID: <CAMZCGg-1DGxFveg28Y6RWahrvqNm538Zw82DLtUzmyvx-ff1tg@mail.gmail.com>

No stick to WF10 for now. What is the output of the cli command when you
install the adapter ?

Le dim. 23 juil. 2017 ? 21:47, Viggo Navarsete <viggo.navarsete at gmail.com>
a ?crit :

> hmm...ok:) Then, have you some other clue to why the adapter doesn't seem
> to be installed correctly? Should I try the Wildfly 11 adapter instead?
>
>
>
> On Sun, Jul 23, 2017 at 9:46 PM Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> It's the same , one can be used offline and the other needs wildfly
>> running.
>>
>>
>> Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <viggo.navarsete at gmail.com>
>> a ?crit :
>>
>>> When I look here:
>>> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
>>> I did this:
>>>
>>> $ cd bin
>>> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>>>
>>> but, when I look here:
>>> https://github.com/keycloak/keycloak-quickstarts#keycloak
>>> it seems that it's another adapter that I should have installed?
>>>
>>> For Linux:
>>>
>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>>>
>>>
>>> ..so I wonder which guide is the correct?
>>>
>>> Regards,
>>> Viggo
>>>
>>>
>>> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <
>>> viggo.navarsete at gmail.com> wrote:
>>>
>>>> Update: I read another post where someone else also had issues
>>>> deploying the examples to a "vanilla Wildfly instance" and got the
>>>> recommendation to deploy them to the Keycloak server (which is a Wildfly
>>>> with Keycloak installed). I tried this, and the example worked, but then I
>>>> wonder: Isn't it normal to have Keycloack running on a separate instance?
>>>>
>>>>
>>>>
>>>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> Thanks Sebastian,
>>>>>
>>>>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>>>>> stopped the server they (at least) ran further :)
>>>>>
>>>>> I then tried to deploy the service.war from the target directory into
>>>>> Wildfly from the console, but ended up with this error in the console:
>>>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>>>> "org.jboss.msc.service.StartException in service
>>>>> jboss.undertow.deployment.default-server.default-host./service:
>>>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>>>> are not installed:" =>
>>>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>>>> Services with missing/unavailable dependencies" => undefined}
>>>>>
>>>>> Any clue here?
>>>>>
>>>>> Regards,
>>>>> Viggo
>>>>>
>>>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>
>>>>>>> Are you able to run the same tutorials from your side?
>>>>>>>
>>>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>>>> ./standalone.sh
>>>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>>>> - I've configured a Client in Keycloak, and the file I've downloaded
>>>>>>> and put into the config directory of the tutorial looks like this:
>>>>>>> {
>>>>>>>   "realm": "master",
>>>>>>>   "bearer-only": true,
>>>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>>>   "ssl-required": "external",
>>>>>>>   "resource": "service-jaxrs",
>>>>>>>   "enable-cors": true
>>>>>>> }
>>>>>>>
>>>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>>>     static {
>>>>>>>         try {
>>>>>>>             TestsHelper.appName = "test-demo";
>>>>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo
>>>>>>> ";
>>>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>>>> // The URL Keycloak runs at
>>>>>>>             importTestRealm("viggis75", "mypassword",
>>>>>>> "/quickstart-realm.json");
>>>>>>>             createDirectGrantClient();
>>>>>>>         } catch (Exception e) {
>>>>>>>             e.printStackTrace();
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>>>> -Denforcer.skip=true
>>>>>>> I get this:
>>>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>>>
>>>>>> This is failing because you have already manually started a Wildfly
>>>>>> and this is conflicting with the one that arquillian will start. If you
>>>>>> don't bother about the integration tests you can run :
>>>>>>
>>>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>>>
>>>>>> This will create the WARs that you can then deploy.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> if I run this command: mvn install wildfly:deploy
>>>>>>> I get this:
>>>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>>>
>>>>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>>>>> from scratch, but end up with the same result each time, so I wonder what
>>>>>>> I'm missing...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Viggo
>>>>>>>
>>>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>
>>>>>>>> mvn install wildfly:deploy
>>>>>>>>
>>>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <sblanc at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> What is the command you issued ?
>>>>>>>>>
>>>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Viggo
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Looks like the attachments didn't make it, make can you paste it
>>>>>>>>>>> in a gist or something like that,
>>>>>>>>>>>
>>>>>>>>>>> Seb
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with
>>>>>>>>>>>> the
>>>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>>>
>>>>>>>>>>>> I *think* I've followed all the instructions there, but still
>>>>>>>>>>>> it fails
>>>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>>>
>>>>>>>>>>>> I've attached the output and hope someone are kind enough to
>>>>>>>>>>>> take a look at
>>>>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>>>>> first bump
>>>>>>>>>>>> here :)
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Viggo
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 15:53:37 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:53:37 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg-1DGxFveg28Y6RWahrvqNm538Zw82DLtUzmyvx-ff1tg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
	<CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
	<CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>
	<CAMZCGg-1DGxFveg28Y6RWahrvqNm538Zw82DLtUzmyvx-ff1tg@mail.gmail.com>
Message-ID: <CADtfDAO95Qu3Xa=ceoUgsfB9_oduEA81T-Cjme_OgCNXDWPx=A@mail.gmail.com>

Here is the output (I reinstalled Wildfly also now to get a clean start):
viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$ ./jboss-cli.sh
--file=adapter-install-offline.cli
{"outcome" => "success"}
{"outcome" => "success"}
{
    "outcome" => "success",
    "result" => [("keycloak" => "1.1.0")]
}
{"outcome" => "success"}
viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$



On Sun, Jul 23, 2017 at 9:50 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> No stick to WF10 for now. What is the output of the cli command when you
> install the adapter ?
>
> Le dim. 23 juil. 2017 ? 21:47, Viggo Navarsete <viggo.navarsete at gmail.com>
> a ?crit :
>
>> hmm...ok:) Then, have you some other clue to why the adapter doesn't seem
>> to be installed correctly? Should I try the Wildfly 11 adapter instead?
>>
>>
>>
>> On Sun, Jul 23, 2017 at 9:46 PM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> It's the same , one can be used offline and the other needs wildfly
>>> running.
>>>
>>>
>>> Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <
>>> viggo.navarsete at gmail.com> a ?crit :
>>>
>>>> When I look here:
>>>> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
>>>> I did this:
>>>>
>>>> $ cd bin
>>>> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>>>>
>>>> but, when I look here:
>>>> https://github.com/keycloak/keycloak-quickstarts#keycloak
>>>> it seems that it's another adapter that I should have installed?
>>>>
>>>> For Linux:
>>>>
>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>>>>
>>>>
>>>> ..so I wonder which guide is the correct?
>>>>
>>>> Regards,
>>>> Viggo
>>>>
>>>>
>>>> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> wrote:
>>>>
>>>>> Update: I read another post where someone else also had issues
>>>>> deploying the examples to a "vanilla Wildfly instance" and got the
>>>>> recommendation to deploy them to the Keycloak server (which is a Wildfly
>>>>> with Keycloak installed). I tried this, and the example worked, but then I
>>>>> wonder: Isn't it normal to have Keycloack running on a separate instance?
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>
>>>>>> Thanks Sebastian,
>>>>>>
>>>>>> indeed, the running Wildfly caused the tests to fail, so as soon as I
>>>>>> stopped the server they (at least) ran further :)
>>>>>>
>>>>>> I then tried to deploy the service.war from the target directory into
>>>>>> Wildfly from the console, but ended up with this error in the console:
>>>>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>>>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>>>>> "org.jboss.msc.service.StartException in service
>>>>>> jboss.undertow.deployment.default-server.default-host./service:
>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>>>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>>>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>>>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>>>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>>>>> are not installed:" =>
>>>>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>>>>> Services with missing/unavailable dependencies" => undefined}
>>>>>>
>>>>>> Any clue here?
>>>>>>
>>>>>> Regards,
>>>>>> Viggo
>>>>>>
>>>>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>
>>>>>>>> Are you able to run the same tutorials from your side?
>>>>>>>>
>>>>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>>>>> ./standalone.sh
>>>>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>>>>> - I've configured a Client in Keycloak, and the file I've
>>>>>>>> downloaded and put into the config directory of the tutorial looks like
>>>>>>>> this:
>>>>>>>> {
>>>>>>>>   "realm": "master",
>>>>>>>>   "bearer-only": true,
>>>>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>>>>   "ssl-required": "external",
>>>>>>>>   "resource": "service-jaxrs",
>>>>>>>>   "enable-cors": true
>>>>>>>> }
>>>>>>>>
>>>>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>>>>     static {
>>>>>>>>         try {
>>>>>>>>             TestsHelper.appName = "test-demo";
>>>>>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo
>>>>>>>> ";
>>>>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>>>>> // The URL Keycloak runs at
>>>>>>>>             importTestRealm("viggis75", "mypassword",
>>>>>>>> "/quickstart-realm.json");
>>>>>>>>             createDirectGrantClient();
>>>>>>>>         } catch (Exception e) {
>>>>>>>>             e.printStackTrace();
>>>>>>>>         }
>>>>>>>>     }
>>>>>>>>
>>>>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>>>>> -Denforcer.skip=true
>>>>>>>> I get this:
>>>>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>>>>
>>>>>>> This is failing because you have already manually started a Wildfly
>>>>>>> and this is conflicting with the one that arquillian will start. If you
>>>>>>> don't bother about the integration tests you can run :
>>>>>>>
>>>>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>>>>
>>>>>>> This will create the WARs that you can then deploy.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> if I run this command: mvn install wildfly:deploy
>>>>>>>> I get this:
>>>>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>>>>
>>>>>>>> I've tried to reinstall both Wildfly and Keycloak and do everything
>>>>>>>> from scratch, but end up with the same result each time, so I wonder what
>>>>>>>> I'm missing...
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Viggo
>>>>>>>>
>>>>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> mvn install wildfly:deploy
>>>>>>>>>
>>>>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <
>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> What is the command you issued ?
>>>>>>>>>>
>>>>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Viggo
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <
>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like the attachments didn't make it, make can you paste
>>>>>>>>>>>> it in a gist or something like that,
>>>>>>>>>>>>
>>>>>>>>>>>> Seb
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I *think* I've followed all the instructions there, but still
>>>>>>>>>>>>> it fails
>>>>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've attached the output and hope someone are kind enough to
>>>>>>>>>>>>> take a look at
>>>>>>>>>>>>> it:) I think Keycloak looks great, but please help me over the
>>>>>>>>>>>>> first bump
>>>>>>>>>>>>> here :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Viggo
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>

From sblanc at redhat.com  Sun Jul 23 15:58:05 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Sun, 23 Jul 2017 19:58:05 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDAO95Qu3Xa=ceoUgsfB9_oduEA81T-Cjme_OgCNXDWPx=A@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
	<CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
	<CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>
	<CAMZCGg-1DGxFveg28Y6RWahrvqNm538Zw82DLtUzmyvx-ff1tg@mail.gmail.com>
	<CADtfDAO95Qu3Xa=ceoUgsfB9_oduEA81T-Cjme_OgCNXDWPx=A@mail.gmail.com>
Message-ID: <CAMZCGg8B5=KiG_7hge1nWe_fTo6xmGZFQSEDoJ_SqSUzzR3Ccw@mail.gmail.com>

This sounds good, not sure when it is not deploying correctly and the
integration tests which does the same is passing.
I will take a look tomorrow morning.


Le dim. 23 juil. 2017 ? 21:53, Viggo Navarsete <viggo.navarsete at gmail.com>
a ?crit :

> Here is the output (I reinstalled Wildfly also now to get a clean start):
> viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$ ./jboss-cli.sh
> --file=adapter-install-offline.cli
> {"outcome" => "success"}
> {"outcome" => "success"}
> {
>     "outcome" => "success",
>     "result" => [("keycloak" => "1.1.0")]
> }
> {"outcome" => "success"}
> viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$
>
>
>
> On Sun, Jul 23, 2017 at 9:50 PM Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> No stick to WF10 for now. What is the output of the cli command when you
>> install the adapter ?
>>
>> Le dim. 23 juil. 2017 ? 21:47, Viggo Navarsete <viggo.navarsete at gmail.com>
>> a ?crit :
>>
>>> hmm...ok:) Then, have you some other clue to why the adapter doesn't
>>> seem to be installed correctly? Should I try the Wildfly 11 adapter instead?
>>>
>>>
>>>
>>> On Sun, Jul 23, 2017 at 9:46 PM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> It's the same , one can be used offline and the other needs wildfly
>>>> running.
>>>>
>>>>
>>>> Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>
>>>>> When I look here:
>>>>> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
>>>>> I did this:
>>>>>
>>>>> $ cd bin
>>>>> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>>>>>
>>>>> but, when I look here:
>>>>> https://github.com/keycloak/keycloak-quickstarts#keycloak
>>>>> it seems that it's another adapter that I should have installed?
>>>>>
>>>>> For Linux:
>>>>>
>>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>>>>>
>>>>>
>>>>> ..so I wonder which guide is the correct?
>>>>>
>>>>> Regards,
>>>>> Viggo
>>>>>
>>>>>
>>>>> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>
>>>>>> Update: I read another post where someone else also had issues
>>>>>> deploying the examples to a "vanilla Wildfly instance" and got the
>>>>>> recommendation to deploy them to the Keycloak server (which is a Wildfly
>>>>>> with Keycloak installed). I tried this, and the example worked, but then I
>>>>>> wonder: Isn't it normal to have Keycloack running on a separate instance?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>
>>>>>>> Thanks Sebastian,
>>>>>>>
>>>>>>> indeed, the running Wildfly caused the tests to fail, so as soon as
>>>>>>> I stopped the server they (at least) ran further :)
>>>>>>>
>>>>>>> I then tried to deploy the service.war from the target directory
>>>>>>> into Wildfly from the console, but ended up with this error in the console:
>>>>>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>>>>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>>>>>> "org.jboss.msc.service.StartException in service
>>>>>>> jboss.undertow.deployment.default-server.default-host./service:
>>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>>>>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>>>>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>>>>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>>>>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>>>>>> are not installed:" =>
>>>>>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>>>>>> Services with missing/unavailable dependencies" => undefined}
>>>>>>>
>>>>>>> Any clue here?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Viggo
>>>>>>>
>>>>>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Are you able to run the same tutorials from your side?
>>>>>>>>>
>>>>>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>>>>>> ./standalone.sh
>>>>>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>>>>>> - I've configured a Client in Keycloak, and the file I've
>>>>>>>>> downloaded and put into the config directory of the tutorial looks like
>>>>>>>>> this:
>>>>>>>>> {
>>>>>>>>>   "realm": "master",
>>>>>>>>>   "bearer-only": true,
>>>>>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>>>>>   "ssl-required": "external",
>>>>>>>>>   "resource": "service-jaxrs",
>>>>>>>>>   "enable-cors": true
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>>>>>     static {
>>>>>>>>>         try {
>>>>>>>>>             TestsHelper.appName = "test-demo";
>>>>>>>>>             TestsHelper.baseUrl = "http://localhost:8080/test-demo
>>>>>>>>> ";
>>>>>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>>>>>> // The URL Keycloak runs at
>>>>>>>>>             importTestRealm("viggis75", "mypassword",
>>>>>>>>> "/quickstart-realm.json");
>>>>>>>>>             createDirectGrantClient();
>>>>>>>>>         } catch (Exception e) {
>>>>>>>>>             e.printStackTrace();
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>>>>>> -Denforcer.skip=true
>>>>>>>>> I get this:
>>>>>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>>>>>
>>>>>>>> This is failing because you have already manually started a Wildfly
>>>>>>>> and this is conflicting with the one that arquillian will start. If you
>>>>>>>> don't bother about the integration tests you can run :
>>>>>>>>
>>>>>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>>>>>
>>>>>>>> This will create the WARs that you can then deploy.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> if I run this command: mvn install wildfly:deploy
>>>>>>>>> I get this:
>>>>>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>>>>>
>>>>>>>>> I've tried to reinstall both Wildfly and Keycloak and do
>>>>>>>>> everything from scratch, but end up with the same result each time, so I
>>>>>>>>> wonder what I'm missing...
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Viggo
>>>>>>>>>
>>>>>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> mvn install wildfly:deploy
>>>>>>>>>>
>>>>>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> What is the command you issued ?
>>>>>>>>>>>
>>>>>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Viggo
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <
>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks like the attachments didn't make it, make can you paste
>>>>>>>>>>>>> it in a gist or something like that,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I *think* I've followed all the instructions there, but still
>>>>>>>>>>>>>> it fails
>>>>>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've attached the output and hope someone are kind enough to
>>>>>>>>>>>>>> take a look at
>>>>>>>>>>>>>> it:) I think Keycloak looks great, but please help me over
>>>>>>>>>>>>>> the first bump
>>>>>>>>>>>>>> here :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Viggo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 15:59:06 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 19:59:06 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CAMZCGg8B5=KiG_7hge1nWe_fTo6xmGZFQSEDoJ_SqSUzzR3Ccw@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
	<CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
	<CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>
	<CAMZCGg-1DGxFveg28Y6RWahrvqNm538Zw82DLtUzmyvx-ff1tg@mail.gmail.com>
	<CADtfDAO95Qu3Xa=ceoUgsfB9_oduEA81T-Cjme_OgCNXDWPx=A@mail.gmail.com>
	<CAMZCGg8B5=KiG_7hge1nWe_fTo6xmGZFQSEDoJ_SqSUzzR3Ccw@mail.gmail.com>
Message-ID: <CADtfDANGhmVWYq4EBdR=dQik+sytwKmP_2wu0XDE3Hc4tvO3zg@mail.gmail.com>

Thanks a lot so far Sebastian:) Looking forward to hear from you again
tomorrow :)

Regards,
Viggo

On Sun, Jul 23, 2017 at 9:58 PM Sebastien Blanc <sblanc at redhat.com> wrote:

> This sounds good, not sure when it is not deploying correctly and the
> integration tests which does the same is passing.
> I will take a look tomorrow morning.
>
>
> Le dim. 23 juil. 2017 ? 21:53, Viggo Navarsete <viggo.navarsete at gmail.com>
> a ?crit :
>
>> Here is the output (I reinstalled Wildfly also now to get a clean start):
>> viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$ ./jboss-cli.sh
>> --file=adapter-install-offline.cli
>> {"outcome" => "success"}
>> {"outcome" => "success"}
>> {
>>     "outcome" => "success",
>>     "result" => [("keycloak" => "1.1.0")]
>> }
>> {"outcome" => "success"}
>> viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$
>>
>>
>>
>> On Sun, Jul 23, 2017 at 9:50 PM Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> No stick to WF10 for now. What is the output of the cli command when you
>>> install the adapter ?
>>>
>>> Le dim. 23 juil. 2017 ? 21:47, Viggo Navarsete <
>>> viggo.navarsete at gmail.com> a ?crit :
>>>
>>>> hmm...ok:) Then, have you some other clue to why the adapter doesn't
>>>> seem to be installed correctly? Should I try the Wildfly 11 adapter instead?
>>>>
>>>>
>>>>
>>>> On Sun, Jul 23, 2017 at 9:46 PM Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> It's the same , one can be used offline and the other needs wildfly
>>>>> running.
>>>>>
>>>>>
>>>>> Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <
>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>
>>>>>> When I look here:
>>>>>> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
>>>>>> I did this:
>>>>>>
>>>>>> $ cd bin
>>>>>> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>>>>>>
>>>>>> but, when I look here:
>>>>>> https://github.com/keycloak/keycloak-quickstarts#keycloak
>>>>>> it seems that it's another adapter that I should have installed?
>>>>>>
>>>>>> For Linux:
>>>>>>
>>>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>>>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>>>>>>
>>>>>>
>>>>>> ..so I wonder which guide is the correct?
>>>>>>
>>>>>> Regards,
>>>>>> Viggo
>>>>>>
>>>>>>
>>>>>> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>
>>>>>>> Update: I read another post where someone else also had issues
>>>>>>> deploying the examples to a "vanilla Wildfly instance" and got the
>>>>>>> recommendation to deploy them to the Keycloak server (which is a Wildfly
>>>>>>> with Keycloak installed). I tried this, and the example worked, but then I
>>>>>>> wonder: Isn't it normal to have Keycloack running on a separate instance?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Sebastian,
>>>>>>>>
>>>>>>>> indeed, the running Wildfly caused the tests to fail, so as soon as
>>>>>>>> I stopped the server they (at least) ran further :)
>>>>>>>>
>>>>>>>> I then tried to deploy the service.war from the target directory
>>>>>>>> into Wildfly from the console, but ended up with this error in the console:
>>>>>>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>>>>>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>>>>>>> "org.jboss.msc.service.StartException in service
>>>>>>>> jboss.undertow.deployment.default-server.default-host./service:
>>>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>>>>>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>>>>>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>>>>>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>>>>>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>>>>>>> are not installed:" =>
>>>>>>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>>>>>>> Services with missing/unavailable dependencies" => undefined}
>>>>>>>>
>>>>>>>> Any clue here?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Viggo
>>>>>>>>
>>>>>>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <sblanc at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Are you able to run the same tutorials from your side?
>>>>>>>>>>
>>>>>>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>>>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>>>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>>>>>>> ./standalone.sh
>>>>>>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>>>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>>>>>>> - I've configured a Client in Keycloak, and the file I've
>>>>>>>>>> downloaded and put into the config directory of the tutorial looks like
>>>>>>>>>> this:
>>>>>>>>>> {
>>>>>>>>>>   "realm": "master",
>>>>>>>>>>   "bearer-only": true,
>>>>>>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>>>>>>   "ssl-required": "external",
>>>>>>>>>>   "resource": "service-jaxrs",
>>>>>>>>>>   "enable-cors": true
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>>>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>>>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>>>>>>     static {
>>>>>>>>>>         try {
>>>>>>>>>>             TestsHelper.appName = "test-demo";
>>>>>>>>>>             TestsHelper.baseUrl = "
>>>>>>>>>> http://localhost:8080/test-demo";
>>>>>>>>>>             TestsHelper.keycloakBaseUrl  = "http://localhost:8180";
>>>>>>>>>> // The URL Keycloak runs at
>>>>>>>>>>             importTestRealm("viggis75", "mypassword",
>>>>>>>>>> "/quickstart-realm.json");
>>>>>>>>>>             createDirectGrantClient();
>>>>>>>>>>         } catch (Exception e) {
>>>>>>>>>>             e.printStackTrace();
>>>>>>>>>>         }
>>>>>>>>>>     }
>>>>>>>>>>
>>>>>>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>>>>>>> -Denforcer.skip=true
>>>>>>>>>> I get this:
>>>>>>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>>>>>>
>>>>>>>>> This is failing because you have already manually started a
>>>>>>>>> Wildfly and this is conflicting with the one that arquillian will start. If
>>>>>>>>> you don't bother about the integration tests you can run :
>>>>>>>>>
>>>>>>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>>>>>>
>>>>>>>>> This will create the WARs that you can then deploy.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> if I run this command: mvn install wildfly:deploy
>>>>>>>>>> I get this:
>>>>>>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>>>>>>
>>>>>>>>>> I've tried to reinstall both Wildfly and Keycloak and do
>>>>>>>>>> everything from scratch, but end up with the same result each time, so I
>>>>>>>>>> wonder what I'm missing...
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Viggo
>>>>>>>>>>
>>>>>>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> mvn install wildfly:deploy
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <
>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> What is the command you issued ?
>>>>>>>>>>>>
>>>>>>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Viggo
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <
>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looks like the attachments didn't make it, make can you paste
>>>>>>>>>>>>>> it in a gist or something like that,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize
>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>> tutorials. I've cloned the quickstarters and started with the
>>>>>>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I *think* I've followed all the instructions there, but
>>>>>>>>>>>>>>> still it fails
>>>>>>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've attached the output and hope someone are kind enough to
>>>>>>>>>>>>>>> take a look at
>>>>>>>>>>>>>>> it:) I think Keycloak looks great, but please help me over
>>>>>>>>>>>>>>> the first bump
>>>>>>>>>>>>>>> here :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Viggo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 16:03:12 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 20:03:12 +0000
Subject: [keycloak-user] tutorial service-jee-jaxrs: Deployable
 container must be specified
In-Reply-To: <CADtfDANGhmVWYq4EBdR=dQik+sytwKmP_2wu0XDE3Hc4tvO3zg@mail.gmail.com>
References: <CADtfDAMpWxfiznKv1r19m1kc8wUri8D9e-TCC4EdZWE+e4dK5w@mail.gmail.com>
	<CAMZCGg84EyMygyGYV=qN5ZpUJtsk7jSpOten+v4XdwYyjO3-Dg@mail.gmail.com>
	<CADtfDAMr3U+NA31Wfz_HAxrJyuCbyuHv=7SAeoTV78PdfV8e-Q@mail.gmail.com>
	<CAMZCGg8VU2BLb87wG-eg=dB88yzrAovLKhU0-=R_SU1gAcQEQQ@mail.gmail.com>
	<CADtfDAMdciAeE6Z2qvqHnAWmZxHXDx1Vkhb1gh2=EvXe3Xu2Rg@mail.gmail.com>
	<CADtfDANB3CLKUZdsicdBYz_Cej90i7RcMu_tpzmpHhTwTOx+SA@mail.gmail.com>
	<CAMZCGg-MG8e4sMtbTxR8vW1Ex+c5Q5=4mvuyR+RO16xwwvoZyg@mail.gmail.com>
	<CADtfDAPm_gj7BtUqZik12KpV=E3v_cK4HmcGqyUCkFRb6xhEYg@mail.gmail.com>
	<CADtfDAOyky25Aj6dX=31q+YnhmyCJrt30g1YzvTkDRL4sKy1qg@mail.gmail.com>
	<CADtfDAN2a8F_X3mnQaOfSBeE67CCqfu+HfQqYEd1uvFZDqdKQg@mail.gmail.com>
	<CAMZCGg8uussqr4_WEneJgyiM8DyPWBfsP5-rpZNXzE8OnSgVdA@mail.gmail.com>
	<CADtfDAOto4iNpmVmACa_YC-Qe9JhO4sOESot4b07MBm2SoVNSA@mail.gmail.com>
	<CAMZCGg-1DGxFveg28Y6RWahrvqNm538Zw82DLtUzmyvx-ff1tg@mail.gmail.com>
	<CADtfDAO95Qu3Xa=ceoUgsfB9_oduEA81T-Cjme_OgCNXDWPx=A@mail.gmail.com>
	<CAMZCGg8B5=KiG_7hge1nWe_fTo6xmGZFQSEDoJ_SqSUzzR3Ccw@mail.gmail.com>
	<CADtfDANGhmVWYq4EBdR=dQik+sytwKmP_2wu0XDE3Hc4tvO3zg@mail.gmail.com>
Message-ID: <CADtfDAOOREMA=Vxdr3Pg6u5vRxuFj9ds+2B6R0P53yn3MVh6Yw@mail.gmail.com>

I tried once more to deploy the service-jee-jaxrs to Wildfly, and this time
it worked! Really not sure what went wrong the first times, but now I have
both a Keycloak running (with an offset on ports) and a wildfly on default
ports, so now I can start playing with the other tutorials which connects
to the service :)

Thanks for great help Sebastian, assuming it's your good karma that finally
did it ;)

Regards,
Viggo

On Sun, Jul 23, 2017 at 9:59 PM Viggo Navarsete <viggo.navarsete at gmail.com>
wrote:

> Thanks a lot so far Sebastian:) Looking forward to hear from you again
> tomorrow :)
>
> Regards,
> Viggo
>
> On Sun, Jul 23, 2017 at 9:58 PM Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> This sounds good, not sure when it is not deploying correctly and the
>> integration tests which does the same is passing.
>> I will take a look tomorrow morning.
>>
>>
>> Le dim. 23 juil. 2017 ? 21:53, Viggo Navarsete <viggo.navarsete at gmail.com>
>> a ?crit :
>>
>>> Here is the output (I reinstalled Wildfly also now to get a clean start):
>>> viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$ ./jboss-cli.sh
>>> --file=adapter-install-offline.cli
>>> {"outcome" => "success"}
>>> {"outcome" => "success"}
>>> {
>>>     "outcome" => "success",
>>>     "result" => [("keycloak" => "1.1.0")]
>>> }
>>> {"outcome" => "success"}
>>> viggo at pepsimax:~/devtools/wildfly-10.1.0.Final/bin$
>>>
>>>
>>>
>>> On Sun, Jul 23, 2017 at 9:50 PM Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> No stick to WF10 for now. What is the output of the cli command when
>>>> you install the adapter ?
>>>>
>>>> Le dim. 23 juil. 2017 ? 21:47, Viggo Navarsete <
>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>
>>>>> hmm...ok:) Then, have you some other clue to why the adapter doesn't
>>>>> seem to be installed correctly? Should I try the Wildfly 11 adapter instead?
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 23, 2017 at 9:46 PM Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> It's the same , one can be used offline and the other needs wildfly
>>>>>> running.
>>>>>>
>>>>>>
>>>>>> Le dim. 23 juil. 2017 ? 21:35, Viggo Navarsete <
>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>
>>>>>>> When I look here:
>>>>>>> https://keycloak.gitbooks.io/documentation/getting_started/topics/secure-jboss-app/install-client-adapter.html
>>>>>>> I did this:
>>>>>>>
>>>>>>> $ cd bin
>>>>>>> $ ./jboss-cli.sh --file=*adapter-install-offline.cli*
>>>>>>>
>>>>>>> but, when I look here:
>>>>>>> https://github.com/keycloak/keycloak-quickstarts#keycloak
>>>>>>> it seems that it's another adapter that I should have installed?
>>>>>>>
>>>>>>> For Linux:
>>>>>>>
>>>>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --file=WILDFLY_HOME/*bin/adapter-install.cli*
>>>>>>>   WILDFLY_HOME/bin/jboss-cli.sh -c --command=:reload
>>>>>>>
>>>>>>>
>>>>>>> ..so I wonder which guide is the correct?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Viggo
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Jul 23, 2017 at 9:31 PM Viggo Navarsete <
>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>
>>>>>>>> Update: I read another post where someone else also had issues
>>>>>>>> deploying the examples to a "vanilla Wildfly instance" and got the
>>>>>>>> recommendation to deploy them to the Keycloak server (which is a Wildfly
>>>>>>>> with Keycloak installed). I tried this, and the example worked, but then I
>>>>>>>> wonder: Isn't it normal to have Keycloack running on a separate instance?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Jul 23, 2017 at 9:17 PM Viggo Navarsete <
>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks Sebastian,
>>>>>>>>>
>>>>>>>>> indeed, the running Wildfly caused the tests to fail, so as soon
>>>>>>>>> as I stopped the server they (at least) ran further :)
>>>>>>>>>
>>>>>>>>> I then tried to deploy the service.war from the target directory
>>>>>>>>> into Wildfly from the console, but ended up with this error in the console:
>>>>>>>>> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
>>>>>>>>> {"jboss.undertow.deployment.default-server.default-host./service" =>
>>>>>>>>> "org.jboss.msc.service.StartException in service
>>>>>>>>> jboss.undertow.deployment.default-server.default-host./service:
>>>>>>>>> java.lang.RuntimeException: java.lang.RuntimeException: UT010039: Unknown
>>>>>>>>> authentication mechanism KEYCLOAK Caused by: java.lang.RuntimeException:
>>>>>>>>> java.lang.RuntimeException: UT010039: Unknown authentication mechanism
>>>>>>>>> KEYCLOAK Caused by: java.lang.RuntimeException: UT010039: Unknown
>>>>>>>>> authentication mechanism KEYCLOAK"},"WFLYCTL0412: Required services that
>>>>>>>>> are not installed:" =>
>>>>>>>>> ["jboss.undertow.deployment.default-server.default-host./service"],"WFLYCTL0180:
>>>>>>>>> Services with missing/unavailable dependencies" => undefined}
>>>>>>>>>
>>>>>>>>> Any clue here?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Viggo
>>>>>>>>>
>>>>>>>>> On Sun, Jul 23, 2017 at 12:28 PM Sebastien Blanc <
>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> On Sun, Jul 23, 2017 at 12:17 PM, Viggo Navarsete <
>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Are you able to run the same tutorials from your side?
>>>>>>>>>>>
>>>>>>>>>>> - I'm using Maven 3.2.5, JDK 1.8.0_131
>>>>>>>>>>> - I've started keycloack server (3.2.1.Final) with this command:
>>>>>>>>>>>  ./standalone.sh -Djboss.socket.binding.port-offset=100
>>>>>>>>>>> - I've started Wildfly server (10.1.0.Final) with this command:
>>>>>>>>>>> ./standalone.sh
>>>>>>>>>>> - I've installed the client adapter for Wildfly 10 for Linux:
>>>>>>>>>>> https://downloads.jboss.org/keycloak/3.2.1.Final/adapters/keycloak-oidc/keycloak-wildfly-adapter-dist-3.2.1.Final.zip
>>>>>>>>>>> - I've configured a Client in Keycloak, and the file I've
>>>>>>>>>>> downloaded and put into the config directory of the tutorial looks like
>>>>>>>>>>> this:
>>>>>>>>>>> {
>>>>>>>>>>>   "realm": "master",
>>>>>>>>>>>   "bearer-only": true,
>>>>>>>>>>>   "auth-server-url": "http://localhost:8180/auth",
>>>>>>>>>>>   "ssl-required": "external",
>>>>>>>>>>>   "resource": "service-jaxrs",
>>>>>>>>>>>   "enable-cors": true
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> - I've added an admin user, viggis75, to Keycloak
>>>>>>>>>>> - I've added a "user" role, and also assigned it to viggis75
>>>>>>>>>>> - The admin user, viggis75, is refered to in the test:
>>>>>>>>>>>     static {
>>>>>>>>>>>         try {
>>>>>>>>>>>             TestsHelper.appName = "test-demo";
>>>>>>>>>>>             TestsHelper.baseUrl = "
>>>>>>>>>>> http://localhost:8080/test-demo";
>>>>>>>>>>>             TestsHelper.keycloakBaseUrl  = "
>>>>>>>>>>> http://localhost:8180"; // The URL Keycloak runs at
>>>>>>>>>>>             importTestRealm("viggis75", "mypassword",
>>>>>>>>>>> "/quickstart-realm.json");
>>>>>>>>>>>             createDirectGrantClient();
>>>>>>>>>>>         } catch (Exception e) {
>>>>>>>>>>>             e.printStackTrace();
>>>>>>>>>>>         }
>>>>>>>>>>>     }
>>>>>>>>>>>
>>>>>>>>>>> If I run this command: mvn clean install -Pwildfly-managed
>>>>>>>>>>> -Denforcer.skip=true
>>>>>>>>>>> I get this:
>>>>>>>>>>> https://gist.github.com/anonymous/adb0d9699a5012b2e9f65e7ed22a7c91
>>>>>>>>>>>
>>>>>>>>>> This is failing because you have already manually started a
>>>>>>>>>> Wildfly and this is conflicting with the one that arquillian will start. If
>>>>>>>>>> you don't bother about the integration tests you can run :
>>>>>>>>>>
>>>>>>>>>>  mvn clean install -DskipTests -Denforcer.skip=true
>>>>>>>>>>
>>>>>>>>>> This will create the WARs that you can then deploy.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> if I run this command: mvn install wildfly:deploy
>>>>>>>>>>> I get this:
>>>>>>>>>>> https://gist.github.com/anonymous/c39610ee19b73e57daed542973bf0ed7
>>>>>>>>>>>
>>>>>>>>>>> I've tried to reinstall both Wildfly and Keycloak and do
>>>>>>>>>>> everything from scratch, but end up with the same result each time, so I
>>>>>>>>>>> wonder what I'm missing...
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Viggo
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jul 23, 2017 at 12:16 AM Viggo Navarsete <
>>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> mvn install wildfly:deploy
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jul 23, 2017 at 12:06 AM Sebastien Blanc <
>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> What is the command you issued ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le sam. 22 juil. 2017 ? 23:59, Viggo Navarsete <
>>>>>>>>>>>>> viggo.navarsete at gmail.com> a ?crit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> sorry for the missing attachment. Here is the gist:
>>>>>>>>>>>>>> https://gist.github.com/anonymous/0793c71c56246a7de520a849a35a2a93
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Viggo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Jul 22, 2017 at 8:56 PM Sebastien Blanc <
>>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looks like the attachments didn't make it, make can you
>>>>>>>>>>>>>>> paste it in a gist or something like that,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Seb
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Jul 22, 2017 at 6:02 PM, Viggo Navarsete <
>>>>>>>>>>>>>>> viggo.navarsete at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm new to Keycloak, and have just started to familiarize
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> tutorials. I've cloned the quickstarters and started with
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> service-jee-jarxrs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I *think* I've followed all the instructions there, but
>>>>>>>>>>>>>>>> still it fails
>>>>>>>>>>>>>>>> while trying to both run the tests and deploy it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've attached the output and hope someone are kind enough
>>>>>>>>>>>>>>>> to take a look at
>>>>>>>>>>>>>>>> it:) I think Keycloak looks great, but please help me over
>>>>>>>>>>>>>>>> the first bump
>>>>>>>>>>>>>>>> here :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> Viggo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

From viggo.navarsete at gmail.com  Sun Jul 23 16:58:30 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Sun, 23 Jul 2017 20:58:30 +0000
Subject: [keycloak-user] keycloak.json not found
Message-ID: <CADtfDAMb8iCd3T+hKZwBaydGASFjZw8GqKgZ2n=U2cw9BAguew@mail.gmail.com>

Hi,

I've tested the two following tutorials:
https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-jee-html5
https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-profile-jee-html5

When I look into the console output it seems that the keycloak.json aren't
found, get a 404 on both cases, even though it is bundled into the war
files under WEB-INF in both cases (placed in the config folder of the
project).

Please see screenshots here:
https://imagebin.ca/v/3UOsxvGZ5wUf
https://imagebin.ca/v/3UOtCb4NIrJE

Regards,
Viggo

From mevans at aconex.com  Sun Jul 23 18:58:13 2017
From: mevans at aconex.com (Matt Evans)
Date: Sun, 23 Jul 2017 22:58:13 +0000
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
Message-ID: <ME1PR01MB076963DFB160EE4DB64B8C7AA9BA0@ME1PR01MB0769.ausprd01.prod.outlook.com>

Hi Marek

Yeah what you say makes sense, however the behaviour I am seeing is that as soon as I re-auth with the SSO cookie, the authentication time seems to get fixed, and any subsequent re-auth with "prompt=login" doesn't update the auth_time.

Matt

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Saturday, 22 July 2017 12:45 AM
To: Matt Evans <mevans at aconex.com>; keycloak-user <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] When should auth_time claim be updated?

On 21/07/17 07:57, Matt Evans wrote:
> Hi
>
> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>
> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>
> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>
> Is this intended behaviour?
Yes. The claim "auth_time" points to the time of the active authentication. And the re-authentication with SSO cookie is not treated as "active" authentication, so this won't update auth_time. With "prompt=login" you need actively authenticate, so that will update auth_time.

Marek
>
> Thanks
>
> Matt
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




From sblanc at redhat.com  Mon Jul 24 02:08:46 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 24 Jul 2017 08:08:46 +0200
Subject: [keycloak-user] keycloak.json not found
In-Reply-To: <CADtfDAMb8iCd3T+hKZwBaydGASFjZw8GqKgZ2n=U2cw9BAguew@mail.gmail.com>
References: <CADtfDAMb8iCd3T+hKZwBaydGASFjZw8GqKgZ2n=U2cw9BAguew@mail.gmail.com>
Message-ID: <CAMZCGg9TFoh57aSz+_DPAjCcDY1gLcPCFwM-hDbZ9TAjV=OchA@mail.gmail.com>

This is indeed wrong, the keycloak.json should be placed at the root of
"webapp
" , I will update the instructions and the POM.


On Sun, Jul 23, 2017 at 10:58 PM, Viggo Navarsete <viggo.navarsete at gmail.com
> wrote:

> Hi,
>
> I've tested the two following tutorials:
> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-jee-html5
> https://github.com/keycloak/keycloak-quickstarts/tree/
> latest/app-profile-jee-html5
>
> When I look into the console output it seems that the keycloak.json aren't
> found, get a 404 on both cases, even though it is bundled into the war
> files under WEB-INF in both cases (placed in the config folder of the
> project).
>
> Please see screenshots here:
> https://imagebin.ca/v/3UOsxvGZ5wUf
> https://imagebin.ca/v/3UOtCb4NIrJE
>
> Regards,
> Viggo
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From mposolda at redhat.com  Mon Jul 24 03:14:16 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 24 Jul 2017 09:14:16 +0200
Subject: [keycloak-user] Multiple LDAP Providers
In-Reply-To: <c4c28561-3fe4-bcb1-5e05-aa4d7f887fd6@list.ru>
References: <09ac713b-010a-6874-2ad0-59d78ef9211f@list.ru>
	<cf218ac5-45d9-08e4-c7d3-85f08c78f032@redhat.com>
	<c4c28561-3fe4-bcb1-5e05-aa4d7f887fd6@list.ru>
Message-ID: <60b40881-bd14-8f46-c19c-b3e7cf6159b2@redhat.com>

I am not sure if this approach works. UserStorageManager.addUser sorts 
UserRegistrationProvider by priority and it registers to the first one, 
which returns not null. But LDAPStorageProvider doesn't have anything to 
specify that users without "social" attribute will be ignored (null will 
be returnws) to ensure the fallback to second provider. It may work 
though if you create subclass of LDAPStorageProvider and implement this 
particular part by yourself.

Marek

Dne 21.7.2017 v 17:06 Dmitry Repchevsky napsal(a):
> Hello Marek,
>
> Thank you for the prompt answer.
>
> My current idea is to make first LDAP expect a "social" attribute 
> which I hardcode for "google" provider.
> Other users (registered via cli or rest) will fail on it and move to 
> the second LDAP which is for the local users.
>
> Dmitry
>
> On 7/21/2017 4:42 PM, Marek Posolda wrote:
>> On 21/07/17 13:48, Dmitry Repchevsky wrote:
>>> Hello,
>>>
>>> Is there any way to define different user profiles to be stored in 
>>> LDAP?
>>> I would like to distinguish between local users and users that come 
>>> from
>>> Google.
>>> The user groups should be different (with different attributes). For
>>> instance local users have "homeDirectory" and "google" ones are treated
>>> as "guests".
>>>
>>> If I define two LDAP "WRITABLE" providers the attempt to write the new
>>> user to LDAP is done by priority order, right?
>> Yes, right. It all depends on priority right now.
>>
>> We have opened JIRA for the case when you want to add social users 
>> locally or to specified user Storage provider (not the default one 
>> with biggest priority). It's not yet available OOTB. However you can 
>> achieve something if you define firstBrokerLogin flow and replace 
>> IdpCreateUserIfUniqueAuthenticator with something else, which will 
>> register user either locally or to different LDAP provider that the 
>> one with biggest priority. But you would need to code that.
>>
>> Marek
>>> I mean if I define a mandatory "homeDirectory" attribute and "google"
>>> user has no this attribute, the user is stored in the second provider?
>>>
>>> Thank you in advance,
>>>
>>> Dmitry
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>


From mposolda at redhat.com  Mon Jul 24 03:19:49 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 24 Jul 2017 09:19:49 +0200
Subject: [keycloak-user] Make "hardcoded-ldap-attribute-mapper" both way.
In-Reply-To: <f8b0f39b-e95d-abca-f8e9-cca37e6d8b24@list.ru>
References: <f8b0f39b-e95d-abca-f8e9-cca37e6d8b24@list.ru>
Message-ID: <ca624d35-e12d-8f43-533f-d2ebba5ab930@redhat.com>

Users from LDAP have federationLink attribute corresponding to LDAP 
provider. IS that sufficient?

Marek

Dne 21.7.2017 v 20:30 Dmitry Repchevsky napsal(a):
> Hello,
>
> According the tooltip "hardcoded-ldap-attribute-mapper" is for putting
> the hardcoded attribute to the LDAP.
> How can I hardcode a user attribute when reading from LDAP? (I want to
> know whether the user comes from LDAP).
>
> Kind regards,
>
> Dmitry
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Mon Jul 24 03:26:26 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 24 Jul 2017 09:26:26 +0200
Subject: [keycloak-user] Keycloak standalone-ha cluster jgroups without
 multicast
In-Reply-To: <CAJv_xg-RFgco=gCJxOZ6AUdJ79fh=mEjk-vgyMt8jSnrSEwB8w@mail.gmail.com>
References: <CAJv_xg-RFgco=gCJxOZ6AUdJ79fh=mEjk-vgyMt8jSnrSEwB8w@mail.gmail.com>
Message-ID: <bdd9477a-1b84-4ab2-f838-2bb108c64acc@redhat.com>

 From the log, it seem that the servers don't see each other and hence 
don't form cluster. In your configuration, you have 
"10.62.168.51[7600],10.62.168.52[7600]", however in log later you have:

physical addresses are [
127.0.0.1:7600

It seems there is the issue with the binding address? It should be 
10.62.168.51 instead of 127.0.0.1. Did you use the "-b" option when 
starting the server?

I think that JGroups/Infinispan/EAP documentation should have more 
details as it's more related to that rather then to Keycloak.

Marek


Dne 23.7.2017 v 12:51 Christian Schneider napsal(a):
> Hi,
> I'm trying to setup a keycloak cluster.
>
> We copy binaries and configuration through our build pipeline to the
> servers, so we decided to for the "standalone clustered mode".
>
> Since our operations don't enable ip multicast, we wan't to work with ip
> static ip addresses.
>
> The only source for this I found is:
> https://kb.novaordis.com/index.php/WildFly_Clustering_without_Multicast
> <https://deref-gmx.net/mail/client/Wiot_0qYjM4/dereferrer/?redirectUrl=https%3A%2F%2Fkb.novaordis.com%2Findex.php%2FWildFly_Clustering_without_Multicast>
>
> I configured both servers like this:
>
>          <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>              <channels default="ee">
>                  <channel name="ee" stack="tcp"/>
>              </channels>
>              <stacks default="tcp">
>                  <stack name="tcp">
>                      <transfer type="TCP" socket-binding="jgroups-tcp"/>
>                      <protocol type="TCPPING">
>                          <property
> name="initial_hosts">10.62.168.51[7600],10.62.168.52[7600]</property>
>                          <property name="num_initial_members">2</property>
>                          <property name="port_range">0</property>
>                          <property name="timeout">2000</property>
>                      </protocol>
>                      <protocol type="MERGE3"/>
>                      <protocol type="FD_SOCK"
> socket-binding="jgroups-tcp-fd"/>
>                      <protocol type="FD"/>
>                      <protocol type="VERIFY_SUSPECT"/>
>                      <protocol type="pbcast.NAKACK2"/>
>                      <protocol type="UNICAST3"/>
>                      <protocol type="pbcast.STABLE"/>
>                      <protocol type="pbcast.GMS"/>
>                      <protocol type="MFC"/>
>                      <protocol type="FRAG2"/>
>                  </stack>
>              </stacks>
>          </subsystem>
>
> I can't figure out whether the two nodes paired each other. In the logfile
> I only find this:
>
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> Starting JGroups channel hibernate
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> Starting JGroups channel web
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> Starting JGroups channel keycloak
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> Starting JGroups channel ejb
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> Starting JGroups channel server
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> Received new cluster view for channel keycloak: [app02.2.xxx.net|0] (1) [
> app02.2.xxx.net]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> Received new cluster view for channel hibernate: [app02.2.xxx.net|0] (1) [
> app02.2.xxx.net]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> Received new cluster view for channel ejb: [app02.2.xxx.net|0] (1) [
> app02.2.xxx.net]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> Received new cluster view for channel server: [app02.2.xxx.net|0] (1) [
> app02.2.xxx.net]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> Received new cluster view for channel web: [app02.2.xxx.net|0] (1) [
> app02.2.xxx.net]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> Channel server local address is app02.2.xxx.net, physical addresses are [
> 127.0.0.1:7600]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> Channel ejb local address is app02.2.xxx.net, physical addresses are [
> 127.0.0.1:7600]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> Channel web local address is app02.2.xxx.net, physical addresses are [
> 127.0.0.1:7600]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> Channel keycloak local address is app02.2.xxx.net, physical addresses are [
> 127.0.0.1:7600]
> INFO  2017-07-21 20:35:43 []
> org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> Channel hibernate local address is app02.2.xxx.net, physical addresses are [
> 127.0.0.1:7600
>
> I checked that the ports 7060 are open.
> When I access just a single node, the setup works fine. With two nodes I
> get {"error":"invalid_grant","error_description":"Session not active"} on
> one of them.
> The goal is that all userSessions are synced between the cluster nodes, so
> that the loadbalancer can roundrobbin between all nodes.
> Since we have around 20k users only, it would be fine to store the users in
> our database. But keycloak doesn't provide this, right?
> Do you have any idea how to figure out whats wrong?
>
> Best Regards,
> Christian.
>
> P.S.: You can find the whole configuration here:
> https://pastebin.com/WC46pXGp
> <https://deref-gmx.net/mail/client/UIuwfhWwMZ0/dereferrer/?redirectUrl=https%3A%2F%2Fpastebin.com%2FWC46pXGp>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From viggo.navarsete at gmail.com  Mon Jul 24 03:45:21 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Mon, 24 Jul 2017 07:45:21 +0000
Subject: [keycloak-user] keycloak.json not found
In-Reply-To: <CAMZCGg9TFoh57aSz+_DPAjCcDY1gLcPCFwM-hDbZ9TAjV=OchA@mail.gmail.com>
References: <CADtfDAMb8iCd3T+hKZwBaydGASFjZw8GqKgZ2n=U2cw9BAguew@mail.gmail.com>
	<CAMZCGg9TFoh57aSz+_DPAjCcDY1gLcPCFwM-hDbZ9TAjV=OchA@mail.gmail.com>
Message-ID: <CADtfDAPhKpj3p5nioL+p5rEvca_12QrnkVH4_sOhgMM16OLXPw@mail.gmail.com>

Thx Sebastian, I will move it manually and see how it goes??

Den man. 24. jul. 2017, 08:08 skrev Sebastien Blanc <sblanc at redhat.com>:

> This is indeed wrong, the keycloak.json should be placed at the root of
> "webapp
> " , I will update the instructions and the POM.
>
>
> On Sun, Jul 23, 2017 at 10:58 PM, Viggo Navarsete <
> viggo.navarsete at gmail.com> wrote:
>
>> Hi,
>>
>> I've tested the two following tutorials:
>> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-jee-html5
>>
>> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-profile-jee-html5
>>
>> When I look into the console output it seems that the keycloak.json aren't
>> found, get a 404 on both cases, even though it is bundled into the war
>> files under WEB-INF in both cases (placed in the config folder of the
>> project).
>>
>> Please see screenshots here:
>> https://imagebin.ca/v/3UOsxvGZ5wUf
>> https://imagebin.ca/v/3UOtCb4NIrJE
>>
>> Regards,
>> Viggo
>>
> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From redmitry at list.ru  Mon Jul 24 04:02:14 2017
From: redmitry at list.ru (Dmitry Repchevsky)
Date: Mon, 24 Jul 2017 10:02:14 +0200
Subject: [keycloak-user] Make "hardcoded-ldap-attribute-mapper" both way.
In-Reply-To: <ca624d35-e12d-8f43-533f-d2ebba5ab930@redhat.com>
References: <f8b0f39b-e95d-abca-f8e9-cca37e6d8b24@list.ru>
	<ca624d35-e12d-8f43-533f-d2ebba5ab930@redhat.com>
Message-ID: <6b3ef4ba-d874-3af5-4870-c075d231121a@list.ru>

Yes indeed,

Thank you very much for the answer.

Dmitry


On 7/24/2017 9:19 AM, Marek Posolda wrote:
> Users from LDAP have federationLink attribute corresponding to LDAP 
> provider. IS that sufficient?
>
> Marek
>
> Dne 21.7.2017 v 20:30 Dmitry Repchevsky napsal(a):
>> Hello,
>>
>> According the tooltip "hardcoded-ldap-attribute-mapper" is for putting
>> the hardcoded attribute to the LDAP.
>> How can I hardcode a user attribute when reading from LDAP? (I want to
>> know whether the user comes from LDAP).
>>
>> Kind regards,
>>
>> Dmitry
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>


From msakho at redhat.com  Mon Jul 24 06:00:52 2017
From: msakho at redhat.com (Meissa M'baye Sakho)
Date: Mon, 24 Jul 2017 12:00:52 +0200
Subject: [keycloak-user] Keycloak standalone-ha cluster jgroups without
	multicast
In-Reply-To: <bdd9477a-1b84-4ab2-f838-2bb108c64acc@redhat.com>
References: <CAJv_xg-RFgco=gCJxOZ6AUdJ79fh=mEjk-vgyMt8jSnrSEwB8w@mail.gmail.com>
	<bdd9477a-1b84-4ab2-f838-2bb108c64acc@redhat.com>
Message-ID: <CAF83W6LLP6vmWFQxhgPZnqxaZAaL6i3Xs7enTy23eb7JR+9DUQ@mail.gmail.com>

Christian,
There is a problem with IP that you have (not) defined for the private
interface that is used by jgroup for intracluster communication.
By default, JGroups only binds to the private network interface, which
points to localhost in the default configuration (line 505 in your
configuration file). For security reasons, *JGroups will not bind to the
network interface defined by the -b argument specified during JBoss EAP
startup*, as clustering traffic should not be exposed on a public network
interface.

You can define this value either by setting the
property jboss.bind.address.private at startup or by hard coding it in the
line 505 in you configuration file:

   1. <interface name="private">
   2.             <inet-address value=
   "${jboss.bind.address.private:127.0.0.1}"/>
   3.             <inet-address value="your-private-ip"/>
   4.         </interface>
   5.


Doing so you should have an output like (instead of localhost in your case).

*11:18:25,954 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-7) ISPN000079: Channel hibernate local address is app02.2.xxx.net
<http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*

*11:18:25,954 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-4) ISPN000079: Channel ejb local address is app02.2.xxx.net
<http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*

*11:18:25,954 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-2) ISPN000079: Channel web local address is app02.2.xxx.net
<http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*

*11:18:25,955 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-8) ISPN000079: Channel server local address is app02.2.xxx.net
<http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*

*11:18:25,955 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-3) ISPN000079: Channel keycloak local address is app02.2.xxx.net
<http://app02.2.xxx.net>, physical addresses are [1your-private-ip:7600]*

*If your configuration jgroup configuration is ok and if you have defined
the jboss.node.name <http://jboss.node.name> property for each of your
cluster member, you should see in you log the output below that will
confirm you that you members will form a cluster:*

*11:18:45,074 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
server: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*

*11:18:45,076 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
keycloak: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*

*11:18:45,078 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
web: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*

*11:18:45,080 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
hibernate: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*

*11:18:45,080 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
ejb: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*

*ISPN000310: Starting cluster-wide rebalance for cache work, topology
CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns =
60, owners = (1)[tcpcluster2: 60]}, pendingCH=ReplicatedConsistentHash{ns =
60, owners = (2)[tcpcluster2: 30, tcpcluster1: 30]}, unionCH=null,
actualMembers=[tcpcluster2, tcpcluster1]}*

In my case, I've defined the jboss.node.name respectively with tcpcluster1
and tcpcluster2.


Meissa



On Mon, Jul 24, 2017 at 9:26 AM, Marek Posolda <mposolda at redhat.com> wrote:

>  From the log, it seem that the servers don't see each other and hence
> don't form cluster. In your configuration, you have
> "10.62.168.51[7600],10.62.168.52[7600]", however in log later you have:
>
> physical addresses are [
> 127.0.0.1:7600
>
> It seems there is the issue with the binding address? It should be
> 10.62.168.51 instead of 127.0.0.1. Did you use the "-b" option when
> starting the server?
>
> I think that JGroups/Infinispan/EAP documentation should have more
> details as it's more related to that rather then to Keycloak.
>
> Marek
>
>
> Dne 23.7.2017 v 12:51 Christian Schneider napsal(a):
> > Hi,
> > I'm trying to setup a keycloak cluster.
> >
> > We copy binaries and configuration through our build pipeline to the
> > servers, so we decided to for the "standalone clustered mode".
> >
> > Since our operations don't enable ip multicast, we wan't to work with ip
> > static ip addresses.
> >
> > The only source for this I found is:
> > https://kb.novaordis.com/index.php/WildFly_Clustering_without_Multicast
> > <https://deref-gmx.net/mail/client/Wiot_0qYjM4/dereferrer/
> ?redirectUrl=https%3A%2F%2Fkb.novaordis.com%2Findex.php%
> 2FWildFly_Clustering_without_Multicast>
> >
> > I configured both servers like this:
> >
> >          <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
> >              <channels default="ee">
> >                  <channel name="ee" stack="tcp"/>
> >              </channels>
> >              <stacks default="tcp">
> >                  <stack name="tcp">
> >                      <transfer type="TCP" socket-binding="jgroups-tcp"/>
> >                      <protocol type="TCPPING">
> >                          <property
> > name="initial_hosts">10.62.168.51[7600],10.62.168.52[7600]</property>
> >                          <property name="num_initial_members">2</
> property>
> >                          <property name="port_range">0</property>
> >                          <property name="timeout">2000</property>
> >                      </protocol>
> >                      <protocol type="MERGE3"/>
> >                      <protocol type="FD_SOCK"
> > socket-binding="jgroups-tcp-fd"/>
> >                      <protocol type="FD"/>
> >                      <protocol type="VERIFY_SUSPECT"/>
> >                      <protocol type="pbcast.NAKACK2"/>
> >                      <protocol type="UNICAST3"/>
> >                      <protocol type="pbcast.STABLE"/>
> >                      <protocol type="pbcast.GMS"/>
> >                      <protocol type="MFC"/>
> >                      <protocol type="FRAG2"/>
> >                  </stack>
> >              </stacks>
> >          </subsystem>
> >
> > I can't figure out whether the two nodes paired each other. In the
> logfile
> > I only find this:
> >
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> > Starting JGroups channel hibernate
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> > Starting JGroups channel web
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> > Starting JGroups channel keycloak
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> > Starting JGroups channel ejb
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
> > Starting JGroups channel server
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> > Received new cluster view for channel keycloak: [app02.2.xxx.net|0] (1)
> [
> > app02.2.xxx.net]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> > Received new cluster view for channel hibernate: [app02.2.xxx.net|0]
> (1) [
> > app02.2.xxx.net]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> > Received new cluster view for channel ejb: [app02.2.xxx.net|0] (1) [
> > app02.2.xxx.net]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> > Received new cluster view for channel server: [app02.2.xxx.net|0] (1) [
> > app02.2.xxx.net]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
> > Received new cluster view for channel web: [app02.2.xxx.net|0] (1) [
> > app02.2.xxx.net]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> > Channel server local address is app02.2.xxx.net, physical addresses are
> [
> > 127.0.0.1:7600]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> > Channel ejb local address is app02.2.xxx.net, physical addresses are [
> > 127.0.0.1:7600]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> > Channel web local address is app02.2.xxx.net, physical addresses are [
> > 127.0.0.1:7600]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> > Channel keycloak local address is app02.2.xxx.net, physical addresses
> are [
> > 127.0.0.1:7600]
> > INFO  2017-07-21 20:35:43 []
> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
> > Channel hibernate local address is app02.2.xxx.net, physical addresses
> are [
> > 127.0.0.1:7600
> >
> > I checked that the ports 7060 are open.
> > When I access just a single node, the setup works fine. With two nodes I
> > get {"error":"invalid_grant","error_description":"Session not active"}
> on
> > one of them.
> > The goal is that all userSessions are synced between the cluster nodes,
> so
> > that the loadbalancer can roundrobbin between all nodes.
> > Since we have around 20k users only, it would be fine to store the users
> in
> > our database. But keycloak doesn't provide this, right?
> > Do you have any idea how to figure out whats wrong?
> >
> > Best Regards,
> > Christian.
> >
> > P.S.: You can find the whole configuration here:
> > https://pastebin.com/WC46pXGp
> > <https://deref-gmx.net/mail/client/UIuwfhWwMZ0/dereferrer/
> ?redirectUrl=https%3A%2F%2Fpastebin.com%2FWC46pXGp>
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From cschneiderpublic at gmail.com  Mon Jul 24 06:42:23 2017
From: cschneiderpublic at gmail.com (Christian Schneider)
Date: Mon, 24 Jul 2017 10:42:23 +0000
Subject: [keycloak-user] Keycloak standalone-ha cluster jgroups without
	multicast
In-Reply-To: <CAF83W6LLP6vmWFQxhgPZnqxaZAaL6i3Xs7enTy23eb7JR+9DUQ@mail.gmail.com>
References: <CAJv_xg-RFgco=gCJxOZ6AUdJ79fh=mEjk-vgyMt8jSnrSEwB8w@mail.gmail.com>
	<bdd9477a-1b84-4ab2-f838-2bb108c64acc@redhat.com>
	<CAF83W6LLP6vmWFQxhgPZnqxaZAaL6i3Xs7enTy23eb7JR+9DUQ@mail.gmail.com>
Message-ID: <CAJv_xg8oQDdV85WFXZH_U38XT=D+ui+O3Xmr9WbCTc+1MW9QRQ@mail.gmail.com>

That was the mistake. Thank you very much.

I used -Djboss.bind.address.private=xxx and it works fine now.

Best Regards,
Christian.

Meissa M'baye Sakho <msakho at redhat.com> schrieb am Mo., 24. Juli 2017 um
12:00 Uhr:

> Christian,
> There is a problem with IP that you have (not) defined for the private
> interface that is used by jgroup for intracluster communication.
> By default, JGroups only binds to the private network interface, which
> points to localhost in the default configuration (line 505 in your
> configuration file). For security reasons, *JGroups will not bind to the
> network interface defined by the -b argument specified during JBoss EAP
> startup*, as clustering traffic should not be exposed on a public network
> interface.
>
> You can define this value either by setting the
> property jboss.bind.address.private at startup or by hard coding it in the
> line 505 in you configuration file:
>
>    1. <interface name="private">
>    2.             <inet-address value=
>    "${jboss.bind.address.private:127.0.0.1}"/>
>    3.             <inet-address value="your-private-ip"/>
>    4.         </interface>
>    5.
>
>
> Doing so you should have an output like (instead of localhost in your
> case).
>
> *11:18:25,954 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-7) ISPN000079: Channel hibernate local address is app02.2.xxx.net
> <http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*
>
> *11:18:25,954 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-4) ISPN000079: Channel ejb local address is app02.2.xxx.net
> <http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*
>
> *11:18:25,954 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-2) ISPN000079: Channel web local address is app02.2.xxx.net
> <http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*
>
> *11:18:25,955 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-8) ISPN000079: Channel server local address is app02.2.xxx.net
> <http://app02.2.xxx.net>, physical addresses are [your-private-ip:7600]*
>
> *11:18:25,955 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
> thread 1-3) ISPN000079: Channel keycloak local address is app02.2.xxx.net
> <http://app02.2.xxx.net>, physical addresses are [1your-private-ip:7600]*
>
> *If your configuration jgroup configuration is ok and if you have defined
> the jboss.node.name <http://jboss.node.name> property for each of your
> cluster member, you should see in you log the output below that will
> confirm you that you members will form a cluster:*
>
> *11:18:45,074 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
> server: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*
>
> *11:18:45,076 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
> keycloak: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*
>
> *11:18:45,078 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
> web: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*
>
> *11:18:45,080 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
> hibernate: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*
>
> *11:18:45,080 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (thread-2,ee,tcpcluster2) ISPN000094: Received new cluster view for channel
> ejb: [tcpcluster2|1] (2) [tcpcluster2, tcpcluster1]*
>
> *ISPN000310: Starting cluster-wide rebalance for cache work, topology
> CacheTopology{id=1, rebalanceId=1, currentCH=ReplicatedConsistentHash{ns =
> 60, owners = (1)[tcpcluster2: 60]}, pendingCH=ReplicatedConsistentHash{ns =
> 60, owners = (2)[tcpcluster2: 30, tcpcluster1: 30]}, unionCH=null,
> actualMembers=[tcpcluster2, tcpcluster1]}*
>
> In my case, I've defined the jboss.node.name respectively with
> tcpcluster1 and tcpcluster2.
>
>
> Meissa
>
>
>
> On Mon, Jul 24, 2017 at 9:26 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>>  From the log, it seem that the servers don't see each other and hence
>> don't form cluster. In your configuration, you have
>> "10.62.168.51[7600],10.62.168.52[7600]", however in log later you have:
>>
>> physical addresses are [
>> 127.0.0.1:7600
>>
>> It seems there is the issue with the binding address? It should be
>> 10.62.168.51 instead of 127.0.0.1. Did you use the "-b" option when
>> starting the server?
>>
>> I think that JGroups/Infinispan/EAP documentation should have more
>> details as it's more related to that rather then to Keycloak.
>>
>> Marek
>>
>>
>> Dne 23.7.2017 v 12:51 Christian Schneider napsal(a):
>> > Hi,
>> > I'm trying to setup a keycloak cluster.
>> >
>> > We copy binaries and configuration through our build pipeline to the
>> > servers, so we decided to for the "standalone clustered mode".
>> >
>> > Since our operations don't enable ip multicast, we wan't to work with ip
>> > static ip addresses.
>> >
>> > The only source for this I found is:
>> > https://kb.novaordis.com/index.php/WildFly_Clustering_without_Multicast
>> > <
>> https://deref-gmx.net/mail/client/Wiot_0qYjM4/dereferrer/?redirectUrl=https%3A%2F%2Fkb.novaordis.com%2Findex.php%2FWildFly_Clustering_without_Multicast
>> >
>> >
>> > I configured both servers like this:
>> >
>> >          <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>> >              <channels default="ee">
>> >                  <channel name="ee" stack="tcp"/>
>> >              </channels>
>> >              <stacks default="tcp">
>> >                  <stack name="tcp">
>> >                      <transfer type="TCP" socket-binding="jgroups-tcp"/>
>> >                      <protocol type="TCPPING">
>> >                          <property
>> > name="initial_hosts">10.62.168.51[7600],10.62.168.52[7600]</property>
>> >                          <property
>> name="num_initial_members">2</property>
>> >                          <property name="port_range">0</property>
>> >                          <property name="timeout">2000</property>
>> >                      </protocol>
>> >                      <protocol type="MERGE3"/>
>> >                      <protocol type="FD_SOCK"
>> > socket-binding="jgroups-tcp-fd"/>
>> >                      <protocol type="FD"/>
>> >                      <protocol type="VERIFY_SUSPECT"/>
>> >                      <protocol type="pbcast.NAKACK2"/>
>> >                      <protocol type="UNICAST3"/>
>> >                      <protocol type="pbcast.STABLE"/>
>> >                      <protocol type="pbcast.GMS"/>
>> >                      <protocol type="MFC"/>
>> >                      <protocol type="FRAG2"/>
>> >                  </stack>
>> >              </stacks>
>> >          </subsystem>
>> >
>> > I can't figure out whether the two nodes paired each other. In the
>> logfile
>> > I only find this:
>> >
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
>> > Starting JGroups channel hibernate
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
>> > Starting JGroups channel web
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
>> > Starting JGroups channel keycloak
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
>> > Starting JGroups channel ejb
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000078:
>> > Starting JGroups channel server
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
>> > Received new cluster view for channel keycloak: [app02.2.xxx.net|0]
>> (1) [
>> > app02.2.xxx.net]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
>> > Received new cluster view for channel hibernate: [app02.2.xxx.net|0]
>> (1) [
>> > app02.2.xxx.net]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
>> > Received new cluster view for channel ejb: [app02.2.xxx.net|0] (1) [
>> > app02.2.xxx.net]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
>> > Received new cluster view for channel server: [app02.2.xxx.net|0] (1) [
>> > app02.2.xxx.net]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000094:
>> > Received new cluster view for channel web: [app02.2.xxx.net|0] (1) [
>> > app02.2.xxx.net]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
>> > Channel server local address is app02.2.xxx.net, physical addresses
>> are [
>> > 127.0.0.1:7600]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
>> > Channel ejb local address is app02.2.xxx.net, physical addresses are [
>> > 127.0.0.1:7600]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
>> > Channel web local address is app02.2.xxx.net, physical addresses are [
>> > 127.0.0.1:7600]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
>> > Channel keycloak local address is app02.2.xxx.net, physical addresses
>> are [
>> > 127.0.0.1:7600]
>> > INFO  2017-07-21 20:35:43 []
>> > org.infinispan.remoting.transport.jgroups.JGroupsTransport ISPN000079:
>> > Channel hibernate local address is app02.2.xxx.net, physical addresses
>> are [
>> > 127.0.0.1:7600
>> >
>> > I checked that the ports 7060 are open.
>> > When I access just a single node, the setup works fine. With two nodes I
>> > get {"error":"invalid_grant","error_description":"Session not active"}
>> on
>> > one of them.
>> > The goal is that all userSessions are synced between the cluster nodes,
>> so
>> > that the loadbalancer can roundrobbin between all nodes.
>> > Since we have around 20k users only, it would be fine to store the
>> users in
>> > our database. But keycloak doesn't provide this, right?
>> > Do you have any idea how to figure out whats wrong?
>> >
>> > Best Regards,
>> > Christian.
>> >
>> > P.S.: You can find the whole configuration here:
>> > https://pastebin.com/WC46pXGp
>> > <
>> https://deref-gmx.net/mail/client/UIuwfhWwMZ0/dereferrer/?redirectUrl=https%3A%2F%2Fpastebin.com%2FWC46pXGp
>> >
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From horizn at wp.pl  Mon Jul 24 06:58:25 2017
From: horizn at wp.pl (Kamil Kapturkiewicz)
Date: Mon, 24 Jul 2017 11:58:25 +0100
Subject: [keycloak-user] Keycloak won't allow me to select my theme from
	drop-down list
Message-ID: <73c57e23-fe06-24b9-f3e6-6f46e300c1f8@wp.pl>

Hi,

I am trying to upgrade Keycloak step by step from very old 1.4.0 version 
to the latest one. However between version 1.8 and 1.9.8 default themes 
folder has been changed, and since that I can't see my theme on 
drop-down list in Realms Settings -> Themes -> Email / Login. What I can 
see in log is:

10:39:14,181 ERROR [org.keycloak.theme.ExtendingThemeManager] (default 
task-14) Failed to find LOGIN theme my_theme, using built-in themes
10:39:14,745 ERROR [org.keycloak.theme.ExtendingThemeManager] (default 
task-16) Failed to find LOGIN theme my_theme, using built-in themes

which means it can see it but won't allow me to use it for some reason. 
I also tried to clear cache, but with no luck. My theme.properties:

parent=base
import=common/keycloak

styles=css/login.css
meta=viewport==width=device-width,initial-scale=1

kcFormGroupClass=ck-form-group-class
kcFormOptionsWrapperClass=ck-form-options-wrapper-class

I went through Keycloak directory structure but found nothing related to 
themes.

brgds,


From viggo.navarsete at gmail.com  Mon Jul 24 07:36:18 2017
From: viggo.navarsete at gmail.com (Viggo Navarsete)
Date: Mon, 24 Jul 2017 11:36:18 +0000
Subject: [keycloak-user] keycloak.json not found
In-Reply-To: <CADtfDAPhKpj3p5nioL+p5rEvca_12QrnkVH4_sOhgMM16OLXPw@mail.gmail.com>
References: <CADtfDAMb8iCd3T+hKZwBaydGASFjZw8GqKgZ2n=U2cw9BAguew@mail.gmail.com>
	<CAMZCGg9TFoh57aSz+_DPAjCcDY1gLcPCFwM-hDbZ9TAjV=OchA@mail.gmail.com>
	<CADtfDAPhKpj3p5nioL+p5rEvca_12QrnkVH4_sOhgMM16OLXPw@mail.gmail.com>
Message-ID: <CADtfDAObNjoFa2oZFXWEdw1yVwe8KtWPwZrdTYqj0EvHzFJ0Ug@mail.gmail.com>

 I can confirm that the tutorials work once I move the keycloak.json to
root of the webapps :)

Thanks for excellent support Sebastian :)

Regards,
Viggo

On Mon, Jul 24, 2017 at 9:45 AM Viggo Navarsete <viggo.navarsete at gmail.com>
wrote:

> Thx Sebastian, I will move it manually and see how it goes??
>
> Den man. 24. jul. 2017, 08:08 skrev Sebastien Blanc <sblanc at redhat.com>:
>
>> This is indeed wrong, the keycloak.json should be placed at the root of
>> "webapp
>> " , I will update the instructions and the POM.
>>
>>
>> On Sun, Jul 23, 2017 at 10:58 PM, Viggo Navarsete <
>> viggo.navarsete at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I've tested the two following tutorials:
>>>
>>> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-jee-html5
>>>
>>> https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-profile-jee-html5
>>>
>>> When I look into the console output it seems that the keycloak.json
>>> aren't
>>> found, get a 404 on both cases, even though it is bundled into the war
>>> files under WEB-INF in both cases (placed in the config folder of the
>>> project).
>>>
>>> Please see screenshots here:
>>> https://imagebin.ca/v/3UOsxvGZ5wUf
>>> https://imagebin.ca/v/3UOtCb4NIrJE
>>>
>>> Regards,
>>> Viggo
>>>
>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>

From federico at info.nl  Mon Jul 24 07:46:23 2017
From: federico at info.nl (Federico Navarro Polo - Info.nl)
Date: Mon, 24 Jul 2017 11:46:23 +0000
Subject: [keycloak-user] Keycloak 3.2.1.Final released
In-Reply-To: <d27477dc-fac7-44d2-3341-61815ef6cebb@redhat.com>
References: <d27477dc-fac7-44d2-3341-61815ef6cebb@redhat.com>
Message-ID: <1FE6DE5D-A50E-463D-B9DE-0D7C1F3375A6@info.nl>

Hello Marek,

Seems like dependencies for 3.2.1.Final are not in maven, latest available dependencies are 3.2.0.Final

https://repo.maven.apache.org/maven2/org/keycloak/keycloak-core/


Regards,
Federico


On 21/07/17 16:36, "keycloak-user-bounces at lists.jboss.org on behalf of Marek Posolda" <keycloak-user-bounces at lists.jboss.org on behalf of mposolda at redhat.com> wrote:

    Keycloak 3.2.1.Final has just been released.
    
    This release doesn't contain any new features. However there are few 
    fixed bugs related to authorization services and new permissions for 
    admin REST API.
    
    To download the release go to the Keycloak homepage
    <http://www.keycloak.org/downloads>.
    
    The full list of resolved issues is available in JIRA
    <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.2.1.Final>
    .
    Upgrading
    
    Before you upgrade remember to backup your database and check the migration
    guide
    <https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
    .
    
    _______________________________________________
    keycloak-user mailing list
    keycloak-user at lists.jboss.org
    https://lists.jboss.org/mailman/listinfo/keycloak-user
    



From ghosh.rajesh at gmail.com  Mon Jul 24 09:15:28 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Mon, 24 Jul 2017 18:45:28 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
	specified kid"
Message-ID: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>

Hi,

I am trying to secure my REST services using the method described in the
document --


http://blog.keycloak.org/2015/10/getting-started-with-keycloak-securing.html


I am securing my war using JBoss subsystem , instead of per-war option. The
relevant sections from my standalone.xml  are posted below.

    <extensions>
         ......
        <extension module="org.keycloak.keycloak-adapter-subsystem"/>
    </extensions>

         <security-domains>
                .....
                <security-domain name="keycloak">
                    <authentication>
                        <login-module
code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/>
                    </authentication>
                </security-domain>
            </security-domains>

        <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
            <secure-deployment name="my war file.war">
                <realm>bkofc</realm>
                <resource>bkofc-svc</resource>

<use-resource-role-mappings>true</use-resource-role-mappings>
                <bearer-only>true</bearer-only>
                <auth-server-url>http://192.168.99.100/30001/auth
</auth-server-url>
                <ssl-required>none</ssl-required>
                <credential
name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
            </secure-deployment>
        </subsystem>

I am able to obtain the access token.

curl -i  curl --data
"grant_type=password&client_id=bkofc-web&username=user&password=password"
http://192.168.99.100:30001/auth/realms/bkofc/protocol/openid-connect/token

Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only, for
my REST services  ii) bkofc-web , a public client to simulate UI login

However when I try to use the access token to invoke a service, I am
getting the error -

Status: 401

WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
error_description="Didn't find publicKey for specified kid"

Please let me know if I am missing something here. I have been breaking my
head last few days without any luck !  I have also tried rotating the realm
keys.

Thanks,
Rajesh

From horizn at wp.pl  Mon Jul 24 10:11:14 2017
From: horizn at wp.pl (Kamil Kapturkiewicz)
Date: Mon, 24 Jul 2017 15:11:14 +0100
Subject: [keycloak-user] Keycloak won't allow me to select my theme from
 drop-down list
In-Reply-To: <73c57e23-fe06-24b9-f3e6-6f46e300c1f8@wp.pl>
References: <73c57e23-fe06-24b9-f3e6-6f46e300c1f8@wp.pl>
Message-ID: <e54c9ddb-1524-e955-52ae-cb4f0eb174d8@wp.pl>

In meantime I found that if I copy themes folder to the old place 
/standalone/configuration/themes, then it is working. So I started 
looking onto DB (Mongo), but found nothing regarding that. Any ideas?


On 24/07/17 11:58, Kamil Kapturkiewicz wrote:
> Hi,
>
> I am trying to upgrade Keycloak step by step from very old 1.4.0 version
> to the latest one. However between version 1.8 and 1.9.8 default themes
> folder has been changed, and since that I can't see my theme on
> drop-down list in Realms Settings -> Themes -> Email / Login. What I can
> see in log is:
>
> 10:39:14,181 ERROR [org.keycloak.theme.ExtendingThemeManager] (default
> task-14) Failed to find LOGIN theme my_theme, using built-in themes
> 10:39:14,745 ERROR [org.keycloak.theme.ExtendingThemeManager] (default
> task-16) Failed to find LOGIN theme my_theme, using built-in themes
>
> which means it can see it but won't allow me to use it for some reason.
> I also tried to clear cache, but with no luck. My theme.properties:
>
> parent=base
> import=common/keycloak
>
> styles=css/login.css
> meta=viewport==width=device-width,initial-scale=1
>
> kcFormGroupClass=ck-form-group-class
> kcFormOptionsWrapperClass=ck-form-options-wrapper-class
>
> I went through Keycloak directory structure but found nothing related to
> themes.
>
> brgds,
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
skype. kamil.kapturkiewicz
tel/signal. +44 758 306 8467


From Kevin.Cuijpers at mips.be  Mon Jul 24 10:18:35 2017
From: Kevin.Cuijpers at mips.be (Kevin Cuijpers)
Date: Mon, 24 Jul 2017 14:18:35 +0000
Subject: [keycloak-user]
 org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No
 login page was defined for FORM authentication in context
Message-ID: <6899ebc2bcf048feb207dbc9b24c18b3@srv-webmail.mips.be>

Hello,

I am trying to use the SAML 2.0 Client Adapter for Tomcat 8.5.8. I downloaded keycloak-saml-tomcat8-adapter-dist-3.2.1.Final and installed it in the lib folder of Tomcat.

I followed the instructions from app-profile-saml-jee-jsp quickstart to set up the Client.

I added following context.xml:
<Context path="app">
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
    <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>

    <!-- Required for KeyCloak -->
    <Valve className="org.keycloak.adapters.saml.tomcat.SamlAuthenticatorValve"/>
</Context>

I copied the files from app-profile-saml-jee-jsp quickstart into a separate project (see attached demo.zip) to make the war.

Tomcat starts up correctly and I see the Please login page when I go to http://localhost:8080/app/

When I click on LOGIN I get a 500 error page and following error:
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No login page was defined for FORM authentication in context [/app]

I found an old mailing with similar problem:
http://lists.jboss.org/pipermail/keycloak-user/2016-November/008380.html

pointing to an issue that should have been solved:
https://issues.jboss.org/browse/KEYCLOAK-3669?attachmentViewMode=list

It is unclear what I need to do to make this simple example work or what needs to be changed to the adapter.

Please help.

Kevin Cuijpers


From mposolda at redhat.com  Mon Jul 24 10:21:47 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 24 Jul 2017 16:21:47 +0200
Subject: [keycloak-user] Keycloak 3.2.1.Final released
In-Reply-To: <1FE6DE5D-A50E-463D-B9DE-0D7C1F3375A6@info.nl>
References: <d27477dc-fac7-44d2-3341-61815ef6cebb@redhat.com>
	<1FE6DE5D-A50E-463D-B9DE-0D7C1F3375A6@info.nl>
Message-ID: <187ebc41-ec5a-bdd2-6d8d-c83a852e2935@redhat.com>

Thanks for the info! I missed one step during the release process though :)

It is available now in jboss repository 
https://repository.jboss.org/nexus/content/groups/public/org/keycloak/keycloak-core/ 
. AFAIK in public maven repository on repo1.maven.org, it will be in 
next 1-2 days.

Sorry for trouble,
Marek

Dne 24.7.2017 v 13:46 Federico Navarro Polo - Info.nl napsal(a):
> Hello Marek,
>
> Seems like dependencies for 3.2.1.Final are not in maven, latest available dependencies are 3.2.0.Final
>
> https://repo.maven.apache.org/maven2/org/keycloak/keycloak-core/
>
>
> Regards,
> Federico
>
>
> On 21/07/17 16:36, "keycloak-user-bounces at lists.jboss.org on behalf of Marek Posolda" <keycloak-user-bounces at lists.jboss.org on behalf of mposolda at redhat.com> wrote:
>
>      Keycloak 3.2.1.Final has just been released.
>      
>      This release doesn't contain any new features. However there are few
>      fixed bugs related to authorization services and new permissions for
>      admin REST API.
>      
>      To download the release go to the Keycloak homepage
>      <http://www.keycloak.org/downloads>.
>      
>      The full list of resolved issues is available in JIRA
>      <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.2.1.Final>
>      .
>      Upgrading
>      
>      Before you upgrade remember to backup your database and check the migration
>      guide
>      <https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
>      .
>      
>      _______________________________________________
>      keycloak-user mailing list
>      keycloak-user at lists.jboss.org
>      https://lists.jboss.org/mailman/listinfo/keycloak-user
>      
>


From sblanc at redhat.com  Mon Jul 24 10:26:48 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 24 Jul 2017 16:26:48 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
Message-ID: <CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>

Which version of Keycloak are you using ?

On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Hi,
>
> I am trying to secure my REST services using the method described in the
> document --
>
>
> http://blog.keycloak.org/2015/10/getting-started-with-
> keycloak-securing.html
>
>
> I am securing my war using JBoss subsystem , instead of per-war option. The
> relevant sections from my standalone.xml  are posted below.
>
>     <extensions>
>          ......
>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
>     </extensions>
>
>          <security-domains>
>                 .....
>                 <security-domain name="keycloak">
>                     <authentication>
>                         <login-module
> code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/>
>                     </authentication>
>                 </security-domain>
>             </security-domains>
>
>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>             <secure-deployment name="my war file.war">
>                 <realm>bkofc</realm>
>                 <resource>bkofc-svc</resource>
>
> <use-resource-role-mappings>true</use-resource-role-mappings>
>                 <bearer-only>true</bearer-only>
>                 <auth-server-url>http://192.168.99.100/30001/auth
> </auth-server-url>
>                 <ssl-required>none</ssl-required>
>                 <credential
> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>             </secure-deployment>
>         </subsystem>
>
> I am able to obtain the access token.
>
> curl -i  curl --data
> "grant_type=password&client_id=bkofc-web&username=user&password=password"
> http://192.168.99.100:30001/auth/realms/bkofc/protocol/
> openid-connect/token
>
> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only, for
> my REST services  ii) bkofc-web , a public client to simulate UI login
>
> However when I try to use the access token to invoke a service, I am
> getting the error -
>
> Status: 401
>
> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
> error_description="Didn't find publicKey for specified kid"
>
> Please let me know if I am missing something here. I have been breaking my
> head last few days without any luck !  I have also tried rotating the realm
> keys.
>
> Thanks,
> Rajesh
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From ghosh.rajesh at gmail.com  Mon Jul 24 10:35:59 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Mon, 24 Jul 2017 20:05:59 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
Message-ID: <CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>

Hello Sebastien,

I am using 3.1.0.Final build.

Thanks,
Rajesh

On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Which version of Keycloak are you using ?
>
> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Hi,
>>
>> I am trying to secure my REST services using the method described in the
>> document --
>>
>>
>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>> ak-securing.html
>>
>>
>> I am securing my war using JBoss subsystem , instead of per-war option.
>> The
>> relevant sections from my standalone.xml  are posted below.
>>
>>     <extensions>
>>          ......
>>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
>>     </extensions>
>>
>>          <security-domains>
>>                 .....
>>                 <security-domain name="keycloak">
>>                     <authentication>
>>                         <login-module
>> code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/>
>>                     </authentication>
>>                 </security-domain>
>>             </security-domains>
>>
>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>             <secure-deployment name="my war file.war">
>>                 <realm>bkofc</realm>
>>                 <resource>bkofc-svc</resource>
>>
>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>                 <bearer-only>true</bearer-only>
>>                 <auth-server-url>http://192.168.99.100/30001/auth
>> </auth-server-url>
>>                 <ssl-required>none</ssl-required>
>>                 <credential
>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>             </secure-deployment>
>>         </subsystem>
>>
>> I am able to obtain the access token.
>>
>> curl -i  curl --data
>> "grant_type=password&client_id=bkofc-web&username=user&password=password"
>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>> d-connect/token
>>
>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only, for
>> my REST services  ii) bkofc-web , a public client to simulate UI login
>>
>> However when I try to use the access token to invoke a service, I am
>> getting the error -
>>
>> Status: 401
>>
>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>> error_description="Didn't find publicKey for specified kid"
>>
>> Please let me know if I am missing something here. I have been breaking my
>> head last few days without any luck !  I have also tried rotating the
>> realm
>> keys.
>>
>> Thanks,
>> Rajesh
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From sblanc at redhat.com  Mon Jul 24 10:42:54 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 24 Jul 2017 16:42:54 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
Message-ID: <CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>

Ok and for :
<secure-deployment name="my war file.war">

Did you replace that with the actual name of your war file ?

On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Hello Sebastien,
>
> I am using 3.1.0.Final build.
>
> Thanks,
> Rajesh
>
> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> Which version of Keycloak are you using ?
>>
>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I am trying to secure my REST services using the method described in the
>>> document --
>>>
>>>
>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>> ak-securing.html
>>>
>>>
>>> I am securing my war using JBoss subsystem , instead of per-war option.
>>> The
>>> relevant sections from my standalone.xml  are posted below.
>>>
>>>     <extensions>
>>>          ......
>>>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
>>>     </extensions>
>>>
>>>          <security-domains>
>>>                 .....
>>>                 <security-domain name="keycloak">
>>>                     <authentication>
>>>                         <login-module
>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/>
>>>                     </authentication>
>>>                 </security-domain>
>>>             </security-domains>
>>>
>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>             <secure-deployment name="my war file.war">
>>>                 <realm>bkofc</realm>
>>>                 <resource>bkofc-svc</resource>
>>>
>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>                 <bearer-only>true</bearer-only>
>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>> </auth-server-url>
>>>                 <ssl-required>none</ssl-required>
>>>                 <credential
>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>             </secure-deployment>
>>>         </subsystem>
>>>
>>> I am able to obtain the access token.
>>>
>>> curl -i  curl --data
>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>> ord=password"
>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>> d-connect/token
>>>
>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only,
>>> for
>>> my REST services  ii) bkofc-web , a public client to simulate UI login
>>>
>>> However when I try to use the access token to invoke a service, I am
>>> getting the error -
>>>
>>> Status: 401
>>>
>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>> error_description="Didn't find publicKey for specified kid"
>>>
>>> Please let me know if I am missing something here. I have been breaking
>>> my
>>> head last few days without any luck !  I have also tried rotating the
>>> realm
>>> keys.
>>>
>>> Thanks,
>>> Rajesh
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>

From ghosh.rajesh at gmail.com  Mon Jul 24 10:54:38 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Mon, 24 Jul 2017 20:24:38 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
Message-ID: <CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>

Yes definitely. I did replace it with the actual war name. Let me know if
you would like me to paste screen shots of realm configurations, client
configurations.

Thanks,
Rajesh

On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Ok and for :
> <secure-deployment name="my war file.war">
>
> Did you replace that with the actual name of your war file ?
>
> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Hello Sebastien,
>>
>> I am using 3.1.0.Final build.
>>
>> Thanks,
>> Rajesh
>>
>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Which version of Keycloak are you using ?
>>>
>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am trying to secure my REST services using the method described in the
>>>> document --
>>>>
>>>>
>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>> ak-securing.html
>>>>
>>>>
>>>> I am securing my war using JBoss subsystem , instead of per-war option.
>>>> The
>>>> relevant sections from my standalone.xml  are posted below.
>>>>
>>>>     <extensions>
>>>>          ......
>>>>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
>>>>     </extensions>
>>>>
>>>>          <security-domains>
>>>>                 .....
>>>>                 <security-domain name="keycloak">
>>>>                     <authentication>
>>>>                         <login-module
>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>> flag="required"/>
>>>>                     </authentication>
>>>>                 </security-domain>
>>>>             </security-domains>
>>>>
>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>             <secure-deployment name="my war file.war">
>>>>                 <realm>bkofc</realm>
>>>>                 <resource>bkofc-svc</resource>
>>>>
>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>                 <bearer-only>true</bearer-only>
>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>> </auth-server-url>
>>>>                 <ssl-required>none</ssl-required>
>>>>                 <credential
>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>             </secure-deployment>
>>>>         </subsystem>
>>>>
>>>> I am able to obtain the access token.
>>>>
>>>> curl -i  curl --data
>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>> ord=password"
>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>> d-connect/token
>>>>
>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only,
>>>> for
>>>> my REST services  ii) bkofc-web , a public client to simulate UI login
>>>>
>>>> However when I try to use the access token to invoke a service, I am
>>>> getting the error -
>>>>
>>>> Status: 401
>>>>
>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>> error_description="Didn't find publicKey for specified kid"
>>>>
>>>> Please let me know if I am missing something here. I have been breaking
>>>> my
>>>> head last few days without any luck !  I have also tried rotating the
>>>> realm
>>>> keys.
>>>>
>>>> Thanks,
>>>> Rajesh
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>

From sblanc at redhat.com  Mon Jul 24 11:43:08 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 24 Jul 2017 17:43:08 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
Message-ID: <CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>

yes please

On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Yes definitely. I did replace it with the actual war name. Let me know if
> you would like me to paste screen shots of realm configurations, client
> configurations.
>
> Thanks,
> Rajesh
>
> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> Ok and for :
>> <secure-deployment name="my war file.war">
>>
>> Did you replace that with the actual name of your war file ?
>>
>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Hello Sebastien,
>>>
>>> I am using 3.1.0.Final build.
>>>
>>> Thanks,
>>> Rajesh
>>>
>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Which version of Keycloak are you using ?
>>>>
>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to secure my REST services using the method described in
>>>>> the
>>>>> document --
>>>>>
>>>>>
>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>> ak-securing.html
>>>>>
>>>>>
>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>> option. The
>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>
>>>>>     <extensions>
>>>>>          ......
>>>>>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
>>>>>     </extensions>
>>>>>
>>>>>          <security-domains>
>>>>>                 .....
>>>>>                 <security-domain name="keycloak">
>>>>>                     <authentication>
>>>>>                         <login-module
>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>> flag="required"/>
>>>>>                     </authentication>
>>>>>                 </security-domain>
>>>>>             </security-domains>
>>>>>
>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>             <secure-deployment name="my war file.war">
>>>>>                 <realm>bkofc</realm>
>>>>>                 <resource>bkofc-svc</resource>
>>>>>
>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>                 <bearer-only>true</bearer-only>
>>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>>> </auth-server-url>
>>>>>                 <ssl-required>none</ssl-required>
>>>>>                 <credential
>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>             </secure-deployment>
>>>>>         </subsystem>
>>>>>
>>>>> I am able to obtain the access token.
>>>>>
>>>>> curl -i  curl --data
>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>> ord=password"
>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>> d-connect/token
>>>>>
>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only,
>>>>> for
>>>>> my REST services  ii) bkofc-web , a public client to simulate UI login
>>>>>
>>>>> However when I try to use the access token to invoke a service, I am
>>>>> getting the error -
>>>>>
>>>>> Status: 401
>>>>>
>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>
>>>>> Please let me know if I am missing something here. I have been
>>>>> breaking my
>>>>> head last few days without any luck !  I have also tried rotating the
>>>>> realm
>>>>> keys.
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>
>>
>

From thomas at recloux.fr  Mon Jul 24 15:20:28 2017
From: thomas at recloux.fr (Thomas Recloux)
Date: Mon, 24 Jul 2017 21:20:28 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
Message-ID: <1500924028.3496047.1051122152.56992C4E@webmail.messagingengine.com>

I already had this issue when the application was not able to reach
keycloak to retrieve the keys.

Is there an exception earlier in the log file ?


On Mon, Jul 24, 2017, at 17:43, Sebastien Blanc wrote:
> yes please
> 
> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
> 
> > Yes definitely. I did replace it with the actual war name. Let me know if
> > you would like me to paste screen shots of realm configurations, client
> > configurations.
> >
> > Thanks,
> > Rajesh
> >
> > On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
> > wrote:
> >
> >> Ok and for :
> >> <secure-deployment name="my war file.war">
> >>
> >> Did you replace that with the actual name of your war file ?
> >>
> >> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> >> wrote:
> >>
> >>> Hello Sebastien,
> >>>
> >>> I am using 3.1.0.Final build.
> >>>
> >>> Thanks,
> >>> Rajesh
> >>>
> >>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
> >>> wrote:
> >>>
> >>>> Which version of Keycloak are you using ?
> >>>>
> >>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I am trying to secure my REST services using the method described in
> >>>>> the
> >>>>> document --
> >>>>>
> >>>>>
> >>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
> >>>>> ak-securing.html
> >>>>>
> >>>>>
> >>>>> I am securing my war using JBoss subsystem , instead of per-war
> >>>>> option. The
> >>>>> relevant sections from my standalone.xml  are posted below.
> >>>>>
> >>>>>     <extensions>
> >>>>>          ......
> >>>>>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
> >>>>>     </extensions>
> >>>>>
> >>>>>          <security-domains>
> >>>>>                 .....
> >>>>>                 <security-domain name="keycloak">
> >>>>>                     <authentication>
> >>>>>                         <login-module
> >>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
> >>>>> flag="required"/>
> >>>>>                     </authentication>
> >>>>>                 </security-domain>
> >>>>>             </security-domains>
> >>>>>
> >>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>>>>             <secure-deployment name="my war file.war">
> >>>>>                 <realm>bkofc</realm>
> >>>>>                 <resource>bkofc-svc</resource>
> >>>>>
> >>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
> >>>>>                 <bearer-only>true</bearer-only>
> >>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
> >>>>> </auth-server-url>
> >>>>>                 <ssl-required>none</ssl-required>
> >>>>>                 <credential
> >>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
> >>>>>             </secure-deployment>
> >>>>>         </subsystem>
> >>>>>
> >>>>> I am able to obtain the access token.
> >>>>>
> >>>>> curl -i  curl --data
> >>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
> >>>>> ord=password"
> >>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
> >>>>> d-connect/token
> >>>>>
> >>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer only,
> >>>>> for
> >>>>> my REST services  ii) bkofc-web , a public client to simulate UI login
> >>>>>
> >>>>> However when I try to use the access token to invoke a service, I am
> >>>>> getting the error -
> >>>>>
> >>>>> Status: 401
> >>>>>
> >>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
> >>>>> error_description="Didn't find publicKey for specified kid"
> >>>>>
> >>>>> Please let me know if I am missing something here. I have been
> >>>>> breaking my
> >>>>> head last few days without any luck !  I have also tried rotating the
> >>>>> realm
> >>>>> keys.
> >>>>>
> >>>>> Thanks,
> >>>>> Rajesh
> >>>>> _______________________________________________
> >>>>> keycloak-user mailing list
> >>>>> keycloak-user at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From dirk.franssen at gmail.com  Mon Jul 24 17:12:08 2017
From: dirk.franssen at gmail.com (Dirk Franssen)
Date: Mon, 24 Jul 2017 23:12:08 +0200
Subject: [keycloak-user] Force token refresh with the Spring Security
	adapter
In-Reply-To: <3e910e72-34fd-7ff2-d57a-5a682aa55def@tesicnor.com>
References: <3e910e72-34fd-7ff2-d57a-5a682aa55def@tesicnor.com>
Message-ID: <CALT3Sxg1Atg+3DiRfeQD=BSn6iugnoQE20GorERfonjAUaQ7Fw@mail.gmail.com>

Hi,

any news on this? I would like to initiate programmatically a refresh of
the token once the profile of the user is updated in the app itself (via
rest api) in order to e.g. display in the header the changed firstname of
the logged-in user (which is retrieved from ((KeycloakAuthenticationToken)
principal).getAccount().getKeycloakSecurityContext().getToken())) without
the need to logout/login again in order to get the updated token.

Kind regards,
Dirk

On Thu, Jan 12, 2017 at 12:48 PM, Aritz Maeztu <amaeztu at tesicnor.com> wrote:

> I'm using keycloak in a java client, configured with the Spring Security
> adapter.
>
> I've got a custom mapper in my keycloak configuration, so when the
> access token is refreshed, keycloak accesses an endpoint to retrieve
> some user permissions and they're stored in the token itself. Later on,
> my client application checks the token without having to perform the
> access to the permission endpoint itself (increased performance).
> However, when an admin user changes his own permissions, I would like
> the keycloak adapter to refresh the token after the permissions are
> stored, this way the admin user is not required to have its token
> refreshed or to re-login to load his new permissions.
>
> Is there a way to achieve it? Some kind of operation to refresh current
> session's token?
>
>
>
> --
> Aritz Maeztu Ota?o
> Departamento Desarrollo de Software
> <https://www.linkedin.com/in/aritz-maeztu-ota%C3%B1o-65891942>
> <http://www.tesicnor.com>
>
> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra)
> Telf. Aritz Maeztu: 948 68 03 06
> Telf. Secretar?a: 948 21 40 40
>
> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
> medioambiente es cosa de todos.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From Nicolas.Geadah at vec.virginia.gov  Mon Jul 24 21:25:46 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Tue, 25 Jul 2017 01:25:46 +0000
Subject: [keycloak-user] Custom FormAction - NoClassDefFoundError
 org/keycloak/services/validation/Validation
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230B5673@COVMSGCES-MBX13>

I built a custom FormAction/FormActionFactory to provide additional behavior in the registration flow.  I'm able to build the JAR, deployment to JBoss works, and the action shows up in the "add execution" in the admin console.

Now when going through the registration process, the FormAction is definitely triggered but an immediate error is thrown:

org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: org/keycloak/services/validation/Validation


Seems like something missing in my jboss-deployment-structure.xml file?  Here is the file as it stands currently - what do I need to add for the necessary module to be loaded?  This is in RHSSO 7.1.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <deployment>
         <dependencies>
              <module name="org.keycloak.keycloak-server-spi-private" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

From sblanc at redhat.com  Tue Jul 25 01:42:15 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 25 Jul 2017 07:42:15 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
Message-ID: <CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>

This looks all correct. Could you try paste your access token or even check
it your self on jwt.io to see if the kid is present ?


On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Sebastien,
>
> I am attaching a pdf containing the screen shots.  Few more points I
> wanted to mention.
>
> i)  I didn't install the public client  -- "bkofc-web"  in the wildfly
> container which hosts my REST services. I did it for  "bkofc-svc"  client
> which is bearer only. I hope that is the correct approach.
> ii)  Both keycloak and my application are running on docker containers
> locally in my laptop.
>
> Let me know if you need anything else to analyze.
>
> Thanks,
> Rajesh
>
>
> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> yes please
>>
>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Yes definitely. I did replace it with the actual war name. Let me know
>>> if you would like me to paste screen shots of realm configurations, client
>>> configurations.
>>>
>>> Thanks,
>>> Rajesh
>>>
>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Ok and for :
>>>> <secure-deployment name="my war file.war">
>>>>
>>>> Did you replace that with the actual name of your war file ?
>>>>
>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Sebastien,
>>>>>
>>>>> I am using 3.1.0.Final build.
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Which version of Keycloak are you using ?
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to secure my REST services using the method described in
>>>>>>> the
>>>>>>> document --
>>>>>>>
>>>>>>>
>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>> ak-securing.html
>>>>>>>
>>>>>>>
>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>> option. The
>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>
>>>>>>>     <extensions>
>>>>>>>          ......
>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>> adapter-subsystem"/>
>>>>>>>     </extensions>
>>>>>>>
>>>>>>>          <security-domains>
>>>>>>>                 .....
>>>>>>>                 <security-domain name="keycloak">
>>>>>>>                     <authentication>
>>>>>>>                         <login-module
>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>> flag="required"/>
>>>>>>>                     </authentication>
>>>>>>>                 </security-domain>
>>>>>>>             </security-domains>
>>>>>>>
>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>                 <realm>bkofc</realm>
>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>
>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>>>>> </auth-server-url>
>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>                 <credential
>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>             </secure-deployment>
>>>>>>>         </subsystem>
>>>>>>>
>>>>>>> I am able to obtain the access token.
>>>>>>>
>>>>>>> curl -i  curl --data
>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>> ord=password"
>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>> d-connect/token
>>>>>>>
>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer
>>>>>>> only, for
>>>>>>> my REST services  ii) bkofc-web , a public client to simulate UI
>>>>>>> login
>>>>>>>
>>>>>>> However when I try to use the access token to invoke a service, I am
>>>>>>> getting the error -
>>>>>>>
>>>>>>> Status: 401
>>>>>>>
>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>
>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>> breaking my
>>>>>>> head last few days without any luck !  I have also tried rotating
>>>>>>> the realm
>>>>>>> keys.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rajesh
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From hmlnarik at redhat.com  Tue Jul 25 02:44:57 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 25 Jul 2017 08:44:57 +0200
Subject: [keycloak-user] Custom FormAction - NoClassDefFoundError
	org/keycloak/services/validation/Validation
In-Reply-To: <AA9A1979BCCB3F4998617B9D33FA3900230B5673@COVMSGCES-MBX13>
References: <AA9A1979BCCB3F4998617B9D33FA3900230B5673@COVMSGCES-MBX13>
Message-ID: <CAMvXD=HhauV4Zq7FuxtEuGnCi1V2Y+xCZ-pDH7TDn7Nw2NrGzA@mail.gmail.com>

org.keycloak.services.validation.Validation is in the module named
"org.keycloak.keycloak-services". Note that the classes in services
module might change in the future.

On Tue, Jul 25, 2017 at 3:25 AM, Geadah, Nicolas (VEC)
<Nicolas.Geadah at vec.virginia.gov> wrote:
> I built a custom FormAction/FormActionFactory to provide additional behavior in the registration flow.  I'm able to build the JAR, deployment to JBoss works, and the action shows up in the "add execution" in the admin console.
>
> Now when going through the registration process, the FormAction is definitely triggered but an immediate error is thrown:
>
> org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: org/keycloak/services/validation/Validation
>
>
> Seems like something missing in my jboss-deployment-structure.xml file?  Here is the file as it stands currently - what do I need to add for the necessary module to be loaded?  This is in RHSSO 7.1.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
>     <deployment>
>          <dependencies>
>               <module name="org.keycloak.keycloak-server-spi-private" />
>         </dependencies>
>     </deployment>
> </jboss-deployment-structure>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From hmlnarik at redhat.com  Tue Jul 25 09:30:51 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 25 Jul 2017 15:30:51 +0200
Subject: [keycloak-user] Dutch translation
Message-ID: <CAMvXD=FwQNNF+d4x=uNLCiuMsQ6BJ+qrui7sZs4WOinrAkhpkg@mail.gmail.com>

Can someone please review Dutch translation in PR
https://github.com/keycloak/keycloak/pull/4340?

--Hynek

From ghosh.rajesh at gmail.com  Tue Jul 25 09:50:08 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 19:20:08 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
Message-ID: <CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>

Sebastien,

Here is a token response -

{
  "access_token":
"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhbG0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
  "expires_in": 300,
  "refresh_expires_in": 1800,
  "refresh_token":
"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItYTE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0eXAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5YTIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtIiwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktcHJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlYXRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvbiIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50cyIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9yaXphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKIhIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvaiucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv_rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdGgDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
  "token_type": "bearer",
  "id_token":
"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtOTJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0eXAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5NmU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lIjoic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tIn0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuihxXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVBn_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYOp4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
  "not-before-policy": 0,
  "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
}


I checked it in jwt.io . The kid is same as the "rsa-generated" one, shown
in the screen shot I shared yesterday. Although jwt complained as "Invalid
Signature" .


Thomas, the connectivity should not be an issue as I am able to get the
access token from  my app wildfly server using curl. So keycloak is
reachable from my wildfly server. Anything specific you did to resolve your
issue ?

Regards,
Rajesh

On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com> wrote:

> This looks all correct. Could you try paste your access token or even
> check it your self on jwt.io to see if the kid is present ?
>
>
> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Sebastien,
>>
>> I am attaching a pdf containing the screen shots.  Few more points I
>> wanted to mention.
>>
>> i)  I didn't install the public client  -- "bkofc-web"  in the wildfly
>> container which hosts my REST services. I did it for  "bkofc-svc"  client
>> which is bearer only. I hope that is the correct approach.
>> ii)  Both keycloak and my application are running on docker containers
>> locally in my laptop.
>>
>> Let me know if you need anything else to analyze.
>>
>> Thanks,
>> Rajesh
>>
>>
>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> yes please
>>>
>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Yes definitely. I did replace it with the actual war name. Let me know
>>>> if you would like me to paste screen shots of realm configurations, client
>>>> configurations.
>>>>
>>>> Thanks,
>>>> Rajesh
>>>>
>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> Ok and for :
>>>>> <secure-deployment name="my war file.war">
>>>>>
>>>>> Did you replace that with the actual name of your war file ?
>>>>>
>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello Sebastien,
>>>>>>
>>>>>> I am using 3.1.0.Final build.
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Which version of Keycloak are you using ?
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am trying to secure my REST services using the method described
>>>>>>>> in the
>>>>>>>> document --
>>>>>>>>
>>>>>>>>
>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>> ak-securing.html
>>>>>>>>
>>>>>>>>
>>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>>> option. The
>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>
>>>>>>>>     <extensions>
>>>>>>>>          ......
>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>> adapter-subsystem"/>
>>>>>>>>     </extensions>
>>>>>>>>
>>>>>>>>          <security-domains>
>>>>>>>>                 .....
>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>                     <authentication>
>>>>>>>>                         <login-module
>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>> flag="required"/>
>>>>>>>>                     </authentication>
>>>>>>>>                 </security-domain>
>>>>>>>>             </security-domains>
>>>>>>>>
>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>
>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>>>>>> </auth-server-url>
>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>                 <credential
>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>>             </secure-deployment>
>>>>>>>>         </subsystem>
>>>>>>>>
>>>>>>>> I am able to obtain the access token.
>>>>>>>>
>>>>>>>> curl -i  curl --data
>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>> ord=password"
>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>> d-connect/token
>>>>>>>>
>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer
>>>>>>>> only, for
>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate UI
>>>>>>>> login
>>>>>>>>
>>>>>>>> However when I try to use the access token to invoke a service, I am
>>>>>>>> getting the error -
>>>>>>>>
>>>>>>>> Status: 401
>>>>>>>>
>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>
>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>> breaking my
>>>>>>>> head last few days without any luck !  I have also tried rotating
>>>>>>>> the realm
>>>>>>>> keys.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rajesh
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sblanc at redhat.com  Tue Jul 25 09:54:04 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 25 Jul 2017 15:54:04 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
Message-ID: <CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>

Okay, to have the complete picture could paste the command you issue to
call your REST service ?


On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Sebastien,
>
> Here is a token response -
>
> {
>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeX
> VUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLT
> Q4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZi
> I6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS
> 4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZW
> IiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOT
> giLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbW
> UiOjAsInNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS
> 0wODlhMjEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5Mj
> FjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW
> 9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYW
> xtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZX
> IiXX0sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7In
> JvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycy
> IsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIi
> wicmVhbG0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIi
> widmlldy1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS
> 1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW
> 50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX
> 0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2
> UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLC
> JwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cm
> lsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL
> -mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7
> cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_
> Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzUg9JY2Dkvg_
> tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_
> uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>   "expires_in": 300,
>   "refresh_expires_in": 1800,
>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeX
> VUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLT
> QwY2ItYTE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZi
> I6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS
> 4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZW
> IiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOT
> giLCJ0eXAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW
> 1lIjowLCJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MT
> ktMDg5YTIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZT
> kyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm
> 9sZXMiOlsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV
> 9hY2Nlc3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LX
> JlYWxtIiwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbn
> RpdHktcHJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIi
> wiY3JlYXRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaX
> phdGlvbiIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LW
> V2ZW50cyIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYX
> V0aG9yaXphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7In
> JvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3
> MiLCJ2aWV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKIhIF6
> Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-EXGJQkqH4NNqZ1W_
> 1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvaiucFCa8H599Ox6QRE
> 3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv_
> rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdGgDnL5jCCRLTVF
> nPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>   "token_type": "bearer",
>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeX
> VUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LT
> RhNTgtOTJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZi
> I6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS
> 4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZW
> IiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOT
> giLCJ0eXAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MC
> wic2Vzc2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OW
> EyMTM5NmU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZX
> JuYW1lIjoic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tIn0.
> eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_
> XOXUmHAuihxXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVBn_
> kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6bG8cyJHQ4_
> FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYOp4lJpU5JqeaVm
> Yp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>   "not-before-policy": 0,
>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
> }
>
>
> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
> shown in the screen shot I shared yesterday. Although jwt complained as
> "Invalid Signature" .
>
>
> Thomas, the connectivity should not be an issue as I am able to get the
> access token from  my app wildfly server using curl. So keycloak is
> reachable from my wildfly server. Anything specific you did to resolve your
> issue ?
>
> Regards,
> Rajesh
>
> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> This looks all correct. Could you try paste your access token or even
>> check it your self on jwt.io to see if the kid is present ?
>>
>>
>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Sebastien,
>>>
>>> I am attaching a pdf containing the screen shots.  Few more points I
>>> wanted to mention.
>>>
>>> i)  I didn't install the public client  -- "bkofc-web"  in the wildfly
>>> container which hosts my REST services. I did it for  "bkofc-svc"  client
>>> which is bearer only. I hope that is the correct approach.
>>> ii)  Both keycloak and my application are running on docker containers
>>> locally in my laptop.
>>>
>>> Let me know if you need anything else to analyze.
>>>
>>> Thanks,
>>> Rajesh
>>>
>>>
>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> yes please
>>>>
>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Yes definitely. I did replace it with the actual war name. Let me know
>>>>> if you would like me to paste screen shots of realm configurations, client
>>>>> configurations.
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Ok and for :
>>>>>> <secure-deployment name="my war file.war">
>>>>>>
>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hello Sebastien,
>>>>>>>
>>>>>>> I am using 3.1.0.Final build.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rajesh
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am trying to secure my REST services using the method described
>>>>>>>>> in the
>>>>>>>>> document --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>> ak-securing.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>>>> option. The
>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>
>>>>>>>>>     <extensions>
>>>>>>>>>          ......
>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>     </extensions>
>>>>>>>>>
>>>>>>>>>          <security-domains>
>>>>>>>>>                 .....
>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>                     <authentication>
>>>>>>>>>                         <login-module
>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>> flag="required"/>
>>>>>>>>>                     </authentication>
>>>>>>>>>                 </security-domain>
>>>>>>>>>             </security-domains>
>>>>>>>>>
>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>
>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>>>>>>> </auth-server-url>
>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>                 <credential
>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>>>             </secure-deployment>
>>>>>>>>>         </subsystem>
>>>>>>>>>
>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>
>>>>>>>>> curl -i  curl --data
>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>> ord=password"
>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>> d-connect/token
>>>>>>>>>
>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer
>>>>>>>>> only, for
>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate UI
>>>>>>>>> login
>>>>>>>>>
>>>>>>>>> However when I try to use the access token to invoke a service, I
>>>>>>>>> am
>>>>>>>>> getting the error -
>>>>>>>>>
>>>>>>>>> Status: 401
>>>>>>>>>
>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>
>>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>>> breaking my
>>>>>>>>> head last few days without any luck !  I have also tried rotating
>>>>>>>>> the realm
>>>>>>>>> keys.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rajesh
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From ghosh.rajesh at gmail.com  Tue Jul 25 10:00:38 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 19:30:38 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
Message-ID: <CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>

Sure. I was using postman to invoke the service. This is the command used
by postman --

------------------------------------------------------------------------

GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
Host: 192.168.99.100:8080
Authorization: Bearer
 eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhbG0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
Cache-Control: no-cache
Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97


---------------------------------------------------------------------------

The "userservice" is my own service for other attributes of users. I also
made sure that the service executes without the security.

Thanks,
Rajesh


On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Okay, to have the complete picture could paste the command you issue to
> call your REST service ?
>
>
> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Sebastien,
>>
>> Here is a token response -
>>
>> {
>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL-
>> mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6z
>> Lk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3
>> f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIK
>> iYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmG
>> yMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>   "expires_in": 300,
>>   "refresh_expires_in": 1800,
>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHR
>> dCv_rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqn
>> AdGgDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>   "token_type": "bearer",
>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>   "not-before-policy": 0,
>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>> }
>>
>>
>> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
>> shown in the screen shot I shared yesterday. Although jwt complained as
>> "Invalid Signature" .
>>
>>
>> Thomas, the connectivity should not be an issue as I am able to get the
>> access token from  my app wildfly server using curl. So keycloak is
>> reachable from my wildfly server. Anything specific you did to resolve your
>> issue ?
>>
>> Regards,
>> Rajesh
>>
>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> This looks all correct. Could you try paste your access token or even
>>> check it your self on jwt.io to see if the kid is present ?
>>>
>>>
>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Sebastien,
>>>>
>>>> I am attaching a pdf containing the screen shots.  Few more points I
>>>> wanted to mention.
>>>>
>>>> i)  I didn't install the public client  -- "bkofc-web"  in the wildfly
>>>> container which hosts my REST services. I did it for  "bkofc-svc"  client
>>>> which is bearer only. I hope that is the correct approach.
>>>> ii)  Both keycloak and my application are running on docker containers
>>>> locally in my laptop.
>>>>
>>>> Let me know if you need anything else to analyze.
>>>>
>>>> Thanks,
>>>> Rajesh
>>>>
>>>>
>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> yes please
>>>>>
>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Yes definitely. I did replace it with the actual war name. Let me
>>>>>> know if you would like me to paste screen shots of realm configurations,
>>>>>> client configurations.
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok and for :
>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>
>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello Sebastien,
>>>>>>>>
>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rajesh
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I am trying to secure my REST services using the method described
>>>>>>>>>> in the
>>>>>>>>>> document --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>> ak-securing.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>>>>> option. The
>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>
>>>>>>>>>>     <extensions>
>>>>>>>>>>          ......
>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>     </extensions>
>>>>>>>>>>
>>>>>>>>>>          <security-domains>
>>>>>>>>>>                 .....
>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>                     <authentication>
>>>>>>>>>>                         <login-module
>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>> flag="required"/>
>>>>>>>>>>                     </authentication>
>>>>>>>>>>                 </security-domain>
>>>>>>>>>>             </security-domains>
>>>>>>>>>>
>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>
>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>>>>>>>> </auth-server-url>
>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>                 <credential
>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>         </subsystem>
>>>>>>>>>>
>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>
>>>>>>>>>> curl -i  curl --data
>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>> ord=password"
>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>> d-connect/token
>>>>>>>>>>
>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer
>>>>>>>>>> only, for
>>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate UI
>>>>>>>>>> login
>>>>>>>>>>
>>>>>>>>>> However when I try to use the access token to invoke a service, I
>>>>>>>>>> am
>>>>>>>>>> getting the error -
>>>>>>>>>>
>>>>>>>>>> Status: 401
>>>>>>>>>>
>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>
>>>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>>>> breaking my
>>>>>>>>>> head last few days without any luck !  I have also tried rotating
>>>>>>>>>> the realm
>>>>>>>>>> keys.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rajesh
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From ghosh.rajesh at gmail.com  Tue Jul 25 10:06:33 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 19:36:33 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
Message-ID: <CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>

Here is the response from curl ---

$ curl -v
http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/us
erservice/users  -H "Authorization:  Bearer $KEY"
*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
> Host: 192.168.99.100:8080
> User-Agent: curl/7.50.1
> Accept: */*
> Authorization:  Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJSSEV
TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1
hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwiaWF0Ijo
xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmt
vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1Zjg
zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsInNlc3N
pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZlNjciLCJhY3IiOiIxIiw
iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGx
vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY2VzcyI
6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJ
yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3Z
pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhbG0tYWR
taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXRob3JpemF0aW9uIiwibWF
uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXc
tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY291bnQ
iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJ
vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWw
iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NU
L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7cy0UKig5ghHX1-g
Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82
NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_uR
rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>
< HTTP/1.1 401 Unauthorized
< Expires: 0
< Cache-Control: no-cache, no-store, must-revalidate
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Pragma: no-cache
< Date: Tue, 25 Jul 2017 14:04:31 GMT
< Connection: keep-alive
< WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
error_description="Didn't find publicKey for specified kid"
< Content-Type: text/html;charset=UTF-8
< Content-Length: 71
<
* Connection #0 to host 192.168.99.100 left intact
<html><head><title>Error</title></head><body>Unauthorized</body></html>$
$

Thanks,
Rajesh

On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Sure. I was using postman to invoke the service. This is the command used
> by postman --
>
> ------------------------------------------------------------------------
>
> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
> Host: 192.168.99.100:8080
> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeX
> VUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLT
> Q4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZi
> I6MCwiaWF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS
> 4xMDA6MzAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZW
> IiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOT
> giLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbW
> UiOjAsInNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS
> 0wODlhMjEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5Mj
> FjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW
> 9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYW
> xtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZX
> IiXX0sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7In
> JvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycy
> IsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIi
> wicmVhbG0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIi
> widmlldy1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS
> 1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW
> 50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX
> 0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2
> UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLC
> JwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cm
> lsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL
> -mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7
> cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_
> Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzUg9JY2Dkvg_
> tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_
> uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
> Cache-Control: no-cache
> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>
>
> ------------------------------------------------------------
> ---------------
>
> The "userservice" is my own service for other attributes of users. I also
> made sure that the service executes without the security.
>
> Thanks,
> Rajesh
>
>
> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> Okay, to have the complete picture could paste the command you issue to
>> call your REST service ?
>>
>>
>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Sebastien,
>>>
>>> Here is a token response -
>>>
>>> {
>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7
>>> cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8b
>>> qyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzUg9JY2Dkvg
>>> _tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_
>>> uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>>   "expires_in": 300,
>>>   "refresh_expires_in": 1800,
>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>   "token_type": "bearer",
>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>   "not-before-policy": 0,
>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>> }
>>>
>>>
>>> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
>>> shown in the screen shot I shared yesterday. Although jwt complained as
>>> "Invalid Signature" .
>>>
>>>
>>> Thomas, the connectivity should not be an issue as I am able to get the
>>> access token from  my app wildfly server using curl. So keycloak is
>>> reachable from my wildfly server. Anything specific you did to resolve your
>>> issue ?
>>>
>>> Regards,
>>> Rajesh
>>>
>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> This looks all correct. Could you try paste your access token or even
>>>> check it your self on jwt.io to see if the kid is present ?
>>>>
>>>>
>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Sebastien,
>>>>>
>>>>> I am attaching a pdf containing the screen shots.  Few more points I
>>>>> wanted to mention.
>>>>>
>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the wildfly
>>>>> container which hosts my REST services. I did it for  "bkofc-svc"  client
>>>>> which is bearer only. I hope that is the correct approach.
>>>>> ii)  Both keycloak and my application are running on docker containers
>>>>> locally in my laptop.
>>>>>
>>>>> Let me know if you need anything else to analyze.
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>>
>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> yes please
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Yes definitely. I did replace it with the actual war name. Let me
>>>>>>> know if you would like me to paste screen shots of realm configurations,
>>>>>>> client configurations.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rajesh
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ok and for :
>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>
>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello Sebastien,
>>>>>>>>>
>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rajesh
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>> described in the
>>>>>>>>>>> document --
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>>> ak-securing.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>>>>>> option. The
>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>
>>>>>>>>>>>     <extensions>
>>>>>>>>>>>          ......
>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>     </extensions>
>>>>>>>>>>>
>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>                 .....
>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>                         <login-module
>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>
>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>
>>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>                 <credential
>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>
>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>
>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>>> ord=password"
>>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>>> d-connect/token
>>>>>>>>>>>
>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer
>>>>>>>>>>> only, for
>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate UI
>>>>>>>>>>> login
>>>>>>>>>>>
>>>>>>>>>>> However when I try to use the access token to invoke a service,
>>>>>>>>>>> I am
>>>>>>>>>>> getting the error -
>>>>>>>>>>>
>>>>>>>>>>> Status: 401
>>>>>>>>>>>
>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>
>>>>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>>>>> breaking my
>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>> rotating the realm
>>>>>>>>>>> keys.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rajesh
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From ghosh.rajesh at gmail.com  Tue Jul 25 10:12:31 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 19:42:31 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
Message-ID: <CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>

Hello Sebastien,

I was looking at the logs of my app wildfly server ,  as suggested by
another user Thomas . Here is a relevant exception stack which I see.

13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
(default task-12) Error when sending request to retrieve realm keys:
org.keycloak.adapters.HttpClientAdapterException: IO error
at
org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(HttpAdapterUtils.java:58)
at
org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendRequest(JWKPublicKeyLocator.java:99)
at
org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublicKey(JWKPublicKeyLocator.java:63)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(AdapterRSATokenVerifier.java:44)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:55)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82)
at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68)
at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.ConnectException: Connection refused (Connection
refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:117)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at
org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(HttpAdapterUtils.java:37)
... 52 more
2017-07-25T13:56:29.452564496Z
13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
(default task-12) Didn't find publicKey for kid:
RHESicBPoNCwhBnBLEk_8X4ufj5WyuTo20zbzOo4HfQ
13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
(default task-12) Failed to verify token:
org.keycloak.common.VerificationException: Didn't find publicKey for
specified kid
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(AdapterRSATokenVerifier.java:47)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:55)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:87)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:82)
at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68)
at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

Is there a way to enhance the log level at the client ( i mean keycloak
adapter ) ,  to see if it is a http connection issue or something else ??

Thanks,
Rajesh

On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Here is the response from curl ---
>
> $ curl -v http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/
> services/sec/rest/us
> erservice/users  -H "Authorization:  Bearer $KEY"
> *   Trying 192.168.99.100...
> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
> > Host: 192.168.99.100:8080
> > User-Agent: curl/7.50.1
> > Accept: */*
> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJSSEV
> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.
> eyJqdGkiOiJkNmY2MmM5YS1
> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
> sIm5iZiI6MCwiaWF0Ijo
> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
> vYXV0aC9yZWFsbXMvYmt
> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
> 2YmMtOWU4MS05MjE1Zjg
> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
> oX3RpbWUiOjAsInNlc3N
> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
> lNjciLCJhY3IiOiIxIiw
> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
> kYTY2NmE4Y2EiLCJhbGx
> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
> sInJlYWxtX2FjY2VzcyI
> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
> 1cmNlX2FjY2VzcyI6eyJ
> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
> 3LWlkZW50aXR5LXByb3Z
> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
> 0aW9uIiwicmVhbG0tYWR
> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
> ob3JpemF0aW9uIiwibWF
> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
> ldy11c2VycyIsInZpZXc
> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
> udHMiXX0sImFjY291bnQ
> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
> saW5rcyIsInZpZXctcHJ
> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
> lcmFkbWluIiwiZW1haWw
> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_
> DfHvNa5HvG3x5WBI3ZcC4WEcBA3NU
> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7
> cy0UKig5ghHX1-g
> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_
> Gz67Wt1iUXAaCZ5fIdXs3epdG82
> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-
> cF0rOqx82pohW6RQMAZmGyMVofsxH_uR
> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
> >
> < HTTP/1.1 401 Unauthorized
> < Expires: 0
> < Cache-Control: no-cache, no-store, must-revalidate
> < X-Powered-By: Undertow/1
> < Server: WildFly/10
> < Pragma: no-cache
> < Date: Tue, 25 Jul 2017 14:04:31 GMT
> < Connection: keep-alive
> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
> error_description="Didn't find publicKey for specified kid"
> < Content-Type: text/html;charset=UTF-8
> < Content-Length: 71
> <
> * Connection #0 to host 192.168.99.100 left intact
> <html><head><title>Error</title></head><body>Unauthorized</body></html>$
> $
>
> Thanks,
> Rajesh
>
> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Sure. I was using postman to invoke the service. This is the command used
>> by postman --
>>
>> ------------------------------------------------------------------------
>>
>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
>> Host: 192.168.99.100:8080
>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL-
>> mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6z
>> Lk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3
>> f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIK
>> iYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmG
>> yMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>> Cache-Control: no-cache
>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>
>>
>> ------------------------------------------------------------
>> ---------------
>>
>> The "userservice" is my own service for other attributes of users. I also
>> made sure that the service executes without the security.
>>
>> Thanks,
>> Rajesh
>>
>>
>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Okay, to have the complete picture could paste the command you issue to
>>> call your REST service ?
>>>
>>>
>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Sebastien,
>>>>
>>>> Here is a token response -
>>>>
>>>> {
>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3
>>>> f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJ
>>>> rjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOq
>>>> x82pohW6RQMAZmGyMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-
>>>> EOWxHgnSEDXc6SF2aAegmCpw",
>>>>   "expires_in": 300,
>>>>   "refresh_expires_in": 1800,
>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>   "token_type": "bearer",
>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>   "not-before-policy": 0,
>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>> }
>>>>
>>>>
>>>> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
>>>> shown in the screen shot I shared yesterday. Although jwt complained as
>>>> "Invalid Signature" .
>>>>
>>>>
>>>> Thomas, the connectivity should not be an issue as I am able to get the
>>>> access token from  my app wildfly server using curl. So keycloak is
>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>> issue ?
>>>>
>>>> Regards,
>>>> Rajesh
>>>>
>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> This looks all correct. Could you try paste your access token or even
>>>>> check it your self on jwt.io to see if the kid is present ?
>>>>>
>>>>>
>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sebastien,
>>>>>>
>>>>>> I am attaching a pdf containing the screen shots.  Few more points I
>>>>>> wanted to mention.
>>>>>>
>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>> containers locally in my laptop.
>>>>>>
>>>>>> Let me know if you need anything else to analyze.
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> yes please
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Yes definitely. I did replace it with the actual war name. Let me
>>>>>>>> know if you would like me to paste screen shots of realm configurations,
>>>>>>>> client configurations.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rajesh
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Ok and for :
>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>
>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>
>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rajesh
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>> described in the
>>>>>>>>>>>> document --
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>>>> ak-securing.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>>>>>>> option. The
>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>
>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>          ......
>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>
>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>                 .....
>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>
>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>
>>>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>                 <credential
>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>
>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>
>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>>>> ord=password"
>>>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>>>> d-connect/token
>>>>>>>>>>>>
>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate
>>>>>>>>>>>> UI login
>>>>>>>>>>>>
>>>>>>>>>>>> However when I try to use the access token to invoke a service,
>>>>>>>>>>>> I am
>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>
>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>
>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>>>>>> breaking my
>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>> keys.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rajesh
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sblanc at redhat.com  Tue Jul 25 10:13:54 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 25 Jul 2017 16:13:54 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
Message-ID: <CAMZCGg_iAg2uqs9dsW4rZsgDhybwmw5w=6ZyR-cGFh+CU4mmYw@mail.gmail.com>

In the WildFly logs you should have also the error : Didn't find publicKey
for specified kid : <your kid> , can you double check it's printing the kid
?

On Tue, Jul 25, 2017 at 4:06 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Here is the response from curl ---
>
> $ curl -v http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/
> services/sec/rest/us
> erservice/users  -H "Authorization:  Bearer $KEY"
> *   Trying 192.168.99.100...
> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
> > Host: 192.168.99.100:8080
> > User-Agent: curl/7.50.1
> > Accept: */*
> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
> AiSldUIiwia2lkIiA6ICJSSEV
> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.
> eyJqdGkiOiJkNmY2MmM5YS1
> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
> sIm5iZiI6MCwiaWF0Ijo
> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
> vYXV0aC9yZWFsbXMvYmt
> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
> 2YmMtOWU4MS05MjE1Zjg
> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
> oX3RpbWUiOjAsInNlc3N
> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
> lNjciLCJhY3IiOiIxIiw
> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
> kYTY2NmE4Y2EiLCJhbGx
> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
> sInJlYWxtX2FjY2VzcyI
> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
> 1cmNlX2FjY2VzcyI6eyJ
> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
> 3LWlkZW50aXR5LXByb3Z
> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
> 0aW9uIiwicmVhbG0tYWR
> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
> ob3JpemF0aW9uIiwibWF
> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
> ldy11c2VycyIsInZpZXc
> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
> udHMiXX0sImFjY291bnQ
> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
> saW5rcyIsInZpZXctcHJ
> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
> lcmFkbWluIiwiZW1haWw
> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_
> DfHvNa5HvG3x5WBI3ZcC4WEcBA3NU
> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7
> cy0UKig5ghHX1-g
> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_
> Gz67Wt1iUXAaCZ5fIdXs3epdG82
> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-
> cF0rOqx82pohW6RQMAZmGyMVofsxH_uR
> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
> >
> < HTTP/1.1 401 Unauthorized
> < Expires: 0
> < Cache-Control: no-cache, no-store, must-revalidate
> < X-Powered-By: Undertow/1
> < Server: WildFly/10
> < Pragma: no-cache
> < Date: Tue, 25 Jul 2017 14:04:31 GMT
> < Connection: keep-alive
> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
> error_description="Didn't find publicKey for specified kid"
> < Content-Type: text/html;charset=UTF-8
> < Content-Length: 71
> <
> * Connection #0 to host 192.168.99.100 left intact
> <html><head><title>Error</title></head><body>Unauthorized</body></html>$
> $
>
> Thanks,
> Rajesh
>
> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Sure. I was using postman to invoke the service. This is the command used
>> by postman --
>>
>> ------------------------------------------------------------------------
>>
>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
>> Host: 192.168.99.100:8080
>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WEcBA3NUL-
>> mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6z
>> Lk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3
>> f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIK
>> iYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmG
>> yMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>> Cache-Control: no-cache
>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>
>>
>> ------------------------------------------------------------
>> ---------------
>>
>> The "userservice" is my own service for other attributes of users. I also
>> made sure that the service executes without the security.
>>
>> Thanks,
>> Rajesh
>>
>>
>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Okay, to have the complete picture could paste the command you issue to
>>> call your REST service ?
>>>
>>>
>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Sebastien,
>>>>
>>>> Here is a token response -
>>>>
>>>> {
>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3
>>>> f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJ
>>>> rjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOq
>>>> x82pohW6RQMAZmGyMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-
>>>> EOWxHgnSEDXc6SF2aAegmCpw",
>>>>   "expires_in": 300,
>>>>   "refresh_expires_in": 1800,
>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>   "token_type": "bearer",
>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>   "not-before-policy": 0,
>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>> }
>>>>
>>>>
>>>> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
>>>> shown in the screen shot I shared yesterday. Although jwt complained as
>>>> "Invalid Signature" .
>>>>
>>>>
>>>> Thomas, the connectivity should not be an issue as I am able to get the
>>>> access token from  my app wildfly server using curl. So keycloak is
>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>> issue ?
>>>>
>>>> Regards,
>>>> Rajesh
>>>>
>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> This looks all correct. Could you try paste your access token or even
>>>>> check it your self on jwt.io to see if the kid is present ?
>>>>>
>>>>>
>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sebastien,
>>>>>>
>>>>>> I am attaching a pdf containing the screen shots.  Few more points I
>>>>>> wanted to mention.
>>>>>>
>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>> containers locally in my laptop.
>>>>>>
>>>>>> Let me know if you need anything else to analyze.
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> yes please
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Yes definitely. I did replace it with the actual war name. Let me
>>>>>>>> know if you would like me to paste screen shots of realm configurations,
>>>>>>>> client configurations.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rajesh
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Ok and for :
>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>
>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>
>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rajesh
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>> described in the
>>>>>>>>>>>> document --
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>>>> ak-securing.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>>>>>>>> option. The
>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>
>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>          ......
>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>
>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>                 .....
>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>
>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>
>>>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>                 <credential
>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>
>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>
>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>>>> ord=password"
>>>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>>>> d-connect/token
>>>>>>>>>>>>
>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate
>>>>>>>>>>>> UI login
>>>>>>>>>>>>
>>>>>>>>>>>> However when I try to use the access token to invoke a service,
>>>>>>>>>>>> I am
>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>
>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>
>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>>>>>> breaking my
>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>> keys.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rajesh
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sblanc at redhat.com  Tue Jul 25 10:14:58 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 25 Jul 2017 16:14:58 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
	<CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
Message-ID: <CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>

Oh you were faster than me on this one ;) , well you can change the log
level of you app in the standalone.xml

On Tue, Jul 25, 2017 at 4:12 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Hello Sebastien,
>
> I was looking at the logs of my app wildfly server ,  as suggested by
> another user Thomas . Here is a relevant exception stack which I see.
>
> 13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
> (default task-12) Error when sending request to retrieve realm keys:
> org.keycloak.adapters.HttpClientAdapterException: IO error
> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(
> HttpAdapterUtils.java:58)
> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendRequest(
> JWKPublicKeyLocator.java:99)
> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublicKey(
> JWKPublicKeyLocator.java:63)
> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(
> AdapterRSATokenVerifier.java:44)
> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(
> AdapterRSATokenVerifier.java:55)
> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(
> AdapterRSATokenVerifier.java:37)
> at org.keycloak.adapters.BearerTokenRequestAuthenticato
> r.authenticateToken(BearerTokenRequestAuthenticator.java:87)
> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(
> BearerTokenRequestAuthenticator.java:82)
> at org.keycloak.adapters.RequestAuthenticator.authenticate(
> RequestAuthenticator.java:68)
> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMe
> ch.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(
> ServletKeycloakAuthMech.java:92)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(
> SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(
> SecurityContextImpl.java:263)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(
> SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(
> SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(
> SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(
> SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandl
> er.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(
> DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandle
> r.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler
> .handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstrai
> ntHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandl
> er.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandle
> r.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand
> ler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.
> handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssocia
> tionHandler.handleRequest(AbstractSecurityContextAssocia
> tionHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.
> handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
> handleRequest(ServletPreAuthActionsHandler.java:69)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(
> ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$
> 100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(
> ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(
> ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(
> ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(
> ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(
> ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$
> 000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(
> ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(
> HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.ConnectException: Connection refused (Connection
> refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(
> AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(
> AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:
> 188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(
> PlainSocketFactory.java:117)
> at org.apache.http.impl.conn.DefaultClientConnectionOperato
> r.openConnection(DefaultClientConnectionOperator.java:177)
> at org.apache.http.impl.conn.AbstractPoolEntry.open(
> AbstractPoolEntry.java:144)
> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(
> AbstractPooledConnAdapter.java:131)
> at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(
> DefaultRequestDirector.java:611)
> at org.apache.http.impl.client.DefaultRequestDirector.execute(
> DefaultRequestDirector.java:446)
> at org.apache.http.impl.client.AbstractHttpClient.doExecute(
> AbstractHttpClient.java:882)
> at org.apache.http.impl.client.CloseableHttpClient.execute(
> CloseableHttpClient.java:82)
> at org.apache.http.impl.client.CloseableHttpClient.execute(
> CloseableHttpClient.java:107)
> at org.apache.http.impl.client.CloseableHttpClient.execute(
> CloseableHttpClient.java:55)
> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(
> HttpAdapterUtils.java:37)
> ... 52 more
> 2017-07-25T13:56:29.452564496Z
> 13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
> (default task-12) Didn't find publicKey for kid: RHESicBPoNCwhBnBLEk_
> 8X4ufj5WyuTo20zbzOo4HfQ
> 13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
> (default task-12) Failed to verify token: org.keycloak.common.VerificationException:
> Didn't find publicKey for specified kid
> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(
> AdapterRSATokenVerifier.java:47)
> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(
> AdapterRSATokenVerifier.java:55)
> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(
> AdapterRSATokenVerifier.java:37)
> at org.keycloak.adapters.BearerTokenRequestAuthenticato
> r.authenticateToken(BearerTokenRequestAuthenticator.java:87)
> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(
> BearerTokenRequestAuthenticator.java:82)
> at org.keycloak.adapters.RequestAuthenticator.authenticate(
> RequestAuthenticator.java:68)
> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMe
> ch.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(
> ServletKeycloakAuthMech.java:92)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(
> SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(
> SecurityContextImpl.java:263)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(
> SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(
> SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(
> SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(
> SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandl
> er.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(
> DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandle
> r.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler
> .handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstrai
> ntHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandl
> er.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandle
> r.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand
> ler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.
> handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssocia
> tionHandler.handleRequest(AbstractSecurityContextAssocia
> tionHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.
> handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
> handleRequest(ServletPreAuthActionsHandler.java:69)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(
> PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(
> ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$
> 100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(
> ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(
> ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(
> ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(
> ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(
> LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(
> ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$
> 000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(
> ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(
> HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
>
> Is there a way to enhance the log level at the client ( i mean keycloak
> adapter ) ,  to see if it is a http connection issue or something else ??
>
> Thanks,
> Rajesh
>
> On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Here is the response from curl ---
>>
>> $ curl -v http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/services/
>> sec/rest/us
>> erservice/users  -H "Authorization:  Bearer $KEY"
>> *   Trying 192.168.99.100...
>> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
>> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>> HTTP/1.1
>> > Host: 192.168.99.100:8080
>> > User-Agent: curl/7.50.1
>> > Accept: */*
>> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
>> AiSldUIiwia2lkIiA6ICJSSEV
>> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJ
>> qdGkiOiJkNmY2MmM5YS1
>> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
>> sIm5iZiI6MCwiaWF0Ijo
>> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
>> vYXV0aC9yZWFsbXMvYmt
>> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
>> 2YmMtOWU4MS05MjE1Zjg
>> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
>> oX3RpbWUiOjAsInNlc3N
>> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
>> lNjciLCJhY3IiOiIxIiw
>> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
>> kYTY2NmE4Y2EiLCJhbGx
>> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
>> sInJlYWxtX2FjY2VzcyI
>> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
>> 1cmNlX2FjY2VzcyI6eyJ
>> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
>> 3LWlkZW50aXR5LXByb3Z
>> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
>> 0aW9uIiwicmVhbG0tYWR
>> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
>> ob3JpemF0aW9uIiwibWF
>> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
>> ldy11c2VycyIsInZpZXc
>> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
>> udHMiXX0sImFjY291bnQ
>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>> saW5rcyIsInZpZXctcHJ
>> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
>> lcmFkbWluIiwiZW1haWw
>> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5Hv
>> G3x5WBI3ZcC4WEcBA3NU
>> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM
>> 6zLk7cy0UKig5ghHX1-g
>> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1
>> iUXAaCZ5fIdXs3epdG82
>> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82poh
>> W6RQMAZmGyMVofsxH_uR
>> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>> >
>> < HTTP/1.1 401 Unauthorized
>> < Expires: 0
>> < Cache-Control: no-cache, no-store, must-revalidate
>> < X-Powered-By: Undertow/1
>> < Server: WildFly/10
>> < Pragma: no-cache
>> < Date: Tue, 25 Jul 2017 14:04:31 GMT
>> < Connection: keep-alive
>> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
>> error_description="Didn't find publicKey for specified kid"
>> < Content-Type: text/html;charset=UTF-8
>> < Content-Length: 71
>> <
>> * Connection #0 to host 192.168.99.100 left intact
>> <html><head><title>Error</title></head><body>Unauthorized</body></html>$
>> $
>>
>> Thanks,
>> Rajesh
>>
>> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Sure. I was using postman to invoke the service. This is the command
>>> used by postman --
>>>
>>> ------------------------------------------------------------------------
>>>
>>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users HTTP/1.1
>>> Host: 192.168.99.100:8080
>>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM6zLk7
>>> cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8b
>>> qyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzUg9JY2Dkvg
>>> _tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVofsxH_
>>> uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>> Cache-Control: no-cache
>>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>>
>>>
>>> ------------------------------------------------------------
>>> ---------------
>>>
>>> The "userservice" is my own service for other attributes of users. I
>>> also made sure that the service executes without the security.
>>>
>>> Thanks,
>>> Rajesh
>>>
>>>
>>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Okay, to have the complete picture could paste the command you issue to
>>>> call your REST service ?
>>>>
>>>>
>>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Sebastien,
>>>>>
>>>>> Here is a token response -
>>>>>
>>>>> {
>>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>>>>   "expires_in": 300,
>>>>>   "refresh_expires_in": 1800,
>>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>>   "token_type": "bearer",
>>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>>   "not-before-policy": 0,
>>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>>> }
>>>>>
>>>>>
>>>>> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
>>>>> shown in the screen shot I shared yesterday. Although jwt complained as
>>>>> "Invalid Signature" .
>>>>>
>>>>>
>>>>> Thomas, the connectivity should not be an issue as I am able to get
>>>>> the access token from  my app wildfly server using curl. So keycloak is
>>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>>> issue ?
>>>>>
>>>>> Regards,
>>>>> Rajesh
>>>>>
>>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> This looks all correct. Could you try paste your access token or even
>>>>>> check it your self on jwt.io to see if the kid is present ?
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Sebastien,
>>>>>>>
>>>>>>> I am attaching a pdf containing the screen shots.  Few more points I
>>>>>>> wanted to mention.
>>>>>>>
>>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>>> containers locally in my laptop.
>>>>>>>
>>>>>>> Let me know if you need anything else to analyze.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rajesh
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> yes please
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Yes definitely. I did replace it with the actual war name. Let me
>>>>>>>>> know if you would like me to paste screen shots of realm configurations,
>>>>>>>>> client configurations.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rajesh
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <
>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Ok and for :
>>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>>
>>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>>
>>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rajesh
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>>> described in the
>>>>>>>>>>>>> document --
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>>>>> ak-securing.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of
>>>>>>>>>>>>> per-war option. The
>>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>>          ......
>>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>>
>>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>>                 .....
>>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>>                 <credential
>>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credenti
>>>>>>>>>>>>> al>
>>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>>
>>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>>>>> ord=password"
>>>>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>>>>> d-connect/token
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate
>>>>>>>>>>>>> UI login
>>>>>>>>>>>>>
>>>>>>>>>>>>> However when I try to use the access token to invoke a
>>>>>>>>>>>>> service, I am
>>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>>
>>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>>
>>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know if I am missing something here. I have been
>>>>>>>>>>>>> breaking my
>>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sblanc at redhat.com  Tue Jul 25 10:17:03 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 25 Jul 2017 16:17:03 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
	<CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
	<CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>
Message-ID: <CAMZCGg_SrVKaftNYw_k_0krDsCKtFvmBJU9WY0vpUhOfCOpmkQ@mail.gmail.com>

Oh I think I found it : <auth-server-url>http://192.168.99.100/30001/auth
</auth-server-url>
You have a typo there , shouldn't it be http://192.168.99.100:30001/auth
<http://192.168.99.100:30001/auth/realms/bkofc/protocol/openid-connect/token>
, notice the ":" instead of "/"

On Tue, Jul 25, 2017 at 4:14 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Oh you were faster than me on this one ;) , well you can change the log
> level of you app in the standalone.xml
>
> On Tue, Jul 25, 2017 at 4:12 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Hello Sebastien,
>>
>> I was looking at the logs of my app wildfly server ,  as suggested by
>> another user Thomas . Here is a relevant exception stack which I see.
>>
>> 13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
>> (default task-12) Error when sending request to retrieve realm keys:
>> org.keycloak.adapters.HttpClientAdapterException: IO error
>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>> ttpAdapterUtils.java:58)
>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendReque
>> st(JWKPublicKeyLocator.java:99)
>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublic
>> Key(JWKPublicKeyLocator.java:63)
>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>> blicKey(AdapterRSATokenVerifier.java:44)
>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>> yToken(AdapterRSATokenVerifier.java:55)
>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>> yToken(AdapterRSATokenVerifier.java:37)
>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.
>> authenticateToken(BearerTokenRequestAuthenticator.java:87)
>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.
>> authenticate(BearerTokenRequestAuthenticator.java:82)
>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>> estAuthenticator.java:68)
>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>> nticate(ServletKeycloakAuthMech.java:92)
>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>> transition(SecurityContextImpl.java:245)
>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>> transition(SecurityContextImpl.java:263)
>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>> access$100(SecurityContextImpl.java:231)
>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>> ication(SecurityContextImpl.java:125)
>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>> (SecurityContextImpl.java:99)
>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>> ecurityContextImpl.java:92)
>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>> t(DisableCacheHandler.java:33)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>> .handleRequest(AbstractConfidentialityHandler.java:46)
>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>> ConstraintHandler.handleRequest(ServletConfident
>> ialityConstraintHandler.java:64)
>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>> ndleRequest(NotificationReceiverHandler.java:50)
>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>> Handler.java:43)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>> ndler.handleRequest(JACCContextIdHandler.java:61)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>> handleRequest(ServletPreAuthActionsHandler.java:69)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>> stRequest(ServletInitialHandler.java:292)
>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>> 0(ServletInitialHandler.java:81)
>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>> rvletInitialHandler.java:138)
>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>> rvletInitialHandler.java:135)
>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.
>> call(ContextClassLoaderSetupAction.java:43)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>> equest(ServletInitialHandler.java:272)
>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>> 0(ServletInitialHandler.java:81)
>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>> equest(ServletInitialHandler.java:104)
>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>> ge.java:805)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by: java.net.ConnectException: Connection refused (Connection
>> refused)
>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>> etImpl.java:350)
>> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>> ainSocketImpl.java:206)
>> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>> Impl.java:188)
>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>> at java.net.Socket.connect(Socket.java:589)
>> at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket
>> (PlainSocketFactory.java:117)
>> at org.apache.http.impl.conn.DefaultClientConnectionOperator.
>> openConnection(DefaultClientConnectionOperator.java:177)
>> at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoo
>> lEntry.java:144)
>> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(Abs
>> tractPooledConnAdapter.java:131)
>> at org.apache.http.impl.client.DefaultRequestDirector.tryConnec
>> t(DefaultRequestDirector.java:611)
>> at org.apache.http.impl.client.DefaultRequestDirector.execute(D
>> efaultRequestDirector.java:446)
>> at org.apache.http.impl.client.AbstractHttpClient.doExecute(Abs
>> tractHttpClient.java:882)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>> eableHttpClient.java:82)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>> eableHttpClient.java:107)
>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>> eableHttpClient.java:55)
>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>> ttpAdapterUtils.java:37)
>> ... 52 more
>> 2017-07-25T13:56:29.452564496Z
>> 13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
>> (default task-12) Didn't find publicKey for kid:
>> RHESicBPoNCwhBnBLEk_8X4ufj5WyuTo20zbzOo4HfQ
>> 13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
>> (default task-12) Failed to verify token: org.keycloak.common.VerificationException:
>> Didn't find publicKey for specified kid
>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>> blicKey(AdapterRSATokenVerifier.java:47)
>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>> yToken(AdapterRSATokenVerifier.java:55)
>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>> yToken(AdapterRSATokenVerifier.java:37)
>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.
>> authenticateToken(BearerTokenRequestAuthenticator.java:87)
>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.
>> authenticate(BearerTokenRequestAuthenticator.java:82)
>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>> estAuthenticator.java:68)
>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>> nticate(ServletKeycloakAuthMech.java:92)
>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>> transition(SecurityContextImpl.java:245)
>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>> transition(SecurityContextImpl.java:263)
>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>> access$100(SecurityContextImpl.java:231)
>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>> ication(SecurityContextImpl.java:125)
>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>> (SecurityContextImpl.java:99)
>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>> ecurityContextImpl.java:92)
>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>> t(DisableCacheHandler.java:33)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>> .handleRequest(AbstractConfidentialityHandler.java:46)
>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>> ConstraintHandler.handleRequest(ServletConfident
>> ialityConstraintHandler.java:64)
>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>> ndleRequest(NotificationReceiverHandler.java:50)
>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>> Handler.java:43)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>> ndler.handleRequest(JACCContextIdHandler.java:61)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>> handleRequest(ServletPreAuthActionsHandler.java:69)
>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>> redicateHandler.java:43)
>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>> stRequest(ServletInitialHandler.java:292)
>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>> 0(ServletInitialHandler.java:81)
>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>> rvletInitialHandler.java:138)
>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>> rvletInitialHandler.java:135)
>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.
>> call(ContextClassLoaderSetupAction.java:43)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.
>> call(LegacyThreadSetupActionWrapper.java:44)
>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>> equest(ServletInitialHandler.java:272)
>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>> 0(ServletInitialHandler.java:81)
>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>> equest(ServletInitialHandler.java:104)
>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>> ge.java:805)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:748)
>>
>> Is there a way to enhance the log level at the client ( i mean keycloak
>> adapter ) ,  to see if it is a http connection issue or something else ??
>>
>> Thanks,
>> Rajesh
>>
>> On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Here is the response from curl ---
>>>
>>> $ curl -v http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/services/s
>>> ec/rest/us
>>> erservice/users  -H "Authorization:  Bearer $KEY"
>>> *   Trying 192.168.99.100...
>>> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
>>> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>> HTTP/1.1
>>> > Host: 192.168.99.100:8080
>>> > User-Agent: curl/7.50.1
>>> > Accept: */*
>>> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
>>> AiSldUIiwia2lkIiA6ICJSSEV
>>> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJ
>>> qdGkiOiJkNmY2MmM5YS1
>>> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
>>> sIm5iZiI6MCwiaWF0Ijo
>>> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
>>> vYXV0aC9yZWFsbXMvYmt
>>> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
>>> 2YmMtOWU4MS05MjE1Zjg
>>> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
>>> oX3RpbWUiOjAsInNlc3N
>>> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
>>> lNjciLCJhY3IiOiIxIiw
>>> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
>>> kYTY2NmE4Y2EiLCJhbGx
>>> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
>>> sInJlYWxtX2FjY2VzcyI
>>> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
>>> 1cmNlX2FjY2VzcyI6eyJ
>>> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
>>> 3LWlkZW50aXR5LXByb3Z
>>> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
>>> 0aW9uIiwicmVhbG0tYWR
>>> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
>>> ob3JpemF0aW9uIiwibWF
>>> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
>>> ldy11c2VycyIsInZpZXc
>>> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
>>> udHMiXX0sImFjY291bnQ
>>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>>> saW5rcyIsInZpZXctcHJ
>>> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
>>> lcmFkbWluIiwiZW1haWw
>>> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5Hv
>>> G3x5WBI3ZcC4WEcBA3NU
>>> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM
>>> 6zLk7cy0UKig5ghHX1-g
>>> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1
>>> iUXAaCZ5fIdXs3epdG82
>>> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82poh
>>> W6RQMAZmGyMVofsxH_uR
>>> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>> >
>>> < HTTP/1.1 401 Unauthorized
>>> < Expires: 0
>>> < Cache-Control: no-cache, no-store, must-revalidate
>>> < X-Powered-By: Undertow/1
>>> < Server: WildFly/10
>>> < Pragma: no-cache
>>> < Date: Tue, 25 Jul 2017 14:04:31 GMT
>>> < Connection: keep-alive
>>> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
>>> error_description="Didn't find publicKey for specified kid"
>>> < Content-Type: text/html;charset=UTF-8
>>> < Content-Length: 71
>>> <
>>> * Connection #0 to host 192.168.99.100 left intact
>>> <html><head><title>Error</title></head><body>Unauthorized</body></html>$
>>> $
>>>
>>> Thanks,
>>> Rajesh
>>>
>>> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Sure. I was using postman to invoke the service. This is the command
>>>> used by postman --
>>>>
>>>> ------------------------------------------------------------
>>>> ------------
>>>>
>>>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>> HTTP/1.1
>>>> Host: 192.168.99.100:8080
>>>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3
>>>> f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJ
>>>> rjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOq
>>>> x82pohW6RQMAZmGyMVofsxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-
>>>> EOWxHgnSEDXc6SF2aAegmCpw
>>>> Cache-Control: no-cache
>>>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ---------------
>>>>
>>>> The "userservice" is my own service for other attributes of users. I
>>>> also made sure that the service executes without the security.
>>>>
>>>> Thanks,
>>>> Rajesh
>>>>
>>>>
>>>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> Okay, to have the complete picture could paste the command you issue
>>>>> to call your REST service ?
>>>>>
>>>>>
>>>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sebastien,
>>>>>>
>>>>>> Here is a token response -
>>>>>>
>>>>>> {
>>>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>>>>>   "expires_in": 300,
>>>>>>   "refresh_expires_in": 1800,
>>>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>>>   "token_type": "bearer",
>>>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>>>   "not-before-policy": 0,
>>>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>>>> }
>>>>>>
>>>>>>
>>>>>> I checked it in jwt.io . The kid is same as the "rsa-generated" one,
>>>>>> shown in the screen shot I shared yesterday. Although jwt complained as
>>>>>> "Invalid Signature" .
>>>>>>
>>>>>>
>>>>>> Thomas, the connectivity should not be an issue as I am able to get
>>>>>> the access token from  my app wildfly server using curl. So keycloak is
>>>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>>>> issue ?
>>>>>>
>>>>>> Regards,
>>>>>> Rajesh
>>>>>>
>>>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This looks all correct. Could you try paste your access token or
>>>>>>> even check it your self on jwt.io to see if the kid is present ?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Sebastien,
>>>>>>>>
>>>>>>>> I am attaching a pdf containing the screen shots.  Few more points
>>>>>>>> I wanted to mention.
>>>>>>>>
>>>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>>>> containers locally in my laptop.
>>>>>>>>
>>>>>>>> Let me know if you need anything else to analyze.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rajesh
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> yes please
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Yes definitely. I did replace it with the actual war name. Let me
>>>>>>>>>> know if you would like me to paste screen shots of realm configurations,
>>>>>>>>>> client configurations.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rajesh
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ok and for :
>>>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>>>
>>>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>>>
>>>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>>>> described in the
>>>>>>>>>>>>>> document --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>>>>>> ak-securing.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of
>>>>>>>>>>>>>> per-war option. The
>>>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>>>          ......
>>>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>>>                 .....
>>>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>>>                 <credential
>>>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credenti
>>>>>>>>>>>>>> al>
>>>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>>>>>> ord=password"
>>>>>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>>>>>> d-connect/token
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to simulate
>>>>>>>>>>>>>> UI login
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However when I try to use the access token to invoke a
>>>>>>>>>>>>>> service, I am
>>>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let me know if I am missing something here. I have
>>>>>>>>>>>>>> been breaking my
>>>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From ghosh.rajesh at gmail.com  Tue Jul 25 10:18:12 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 19:48:12 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg_SrVKaftNYw_k_0krDsCKtFvmBJU9WY0vpUhOfCOpmkQ@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
	<CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
	<CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>
	<CAMZCGg_SrVKaftNYw_k_0krDsCKtFvmBJU9WY0vpUhOfCOpmkQ@mail.gmail.com>
Message-ID: <CAOKDOx+eJ8ZH6+8PUe0w9cbyD0u9ZHPBNiOEvocWXXKE7OE+jA@mail.gmail.com>

OMG ! That was stupid ! Let me rectify that and try again.

Thanks so much for pointing out.

Regards,
Rajesh

On Tue, Jul 25, 2017 at 7:47 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Oh I think I found it : <auth-server-url>http://192.168.99.100/30001/auth
> </auth-server-url>
> You have a typo there , shouldn't it be http://192.168.99.100:30001/auth
> <http://192.168.99.100:30001/auth/realms/bkofc/protocol/openid-connect/token>
> , notice the ":" instead of "/"
>
> On Tue, Jul 25, 2017 at 4:14 PM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> Oh you were faster than me on this one ;) , well you can change the log
>> level of you app in the standalone.xml
>>
>> On Tue, Jul 25, 2017 at 4:12 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> Hello Sebastien,
>>>
>>> I was looking at the logs of my app wildfly server ,  as suggested by
>>> another user Thomas . Here is a relevant exception stack which I see.
>>>
>>> 13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
>>> (default task-12) Error when sending request to retrieve realm keys:
>>> org.keycloak.adapters.HttpClientAdapterException: IO error
>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>> ttpAdapterUtils.java:58)
>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendReque
>>> st(JWKPublicKeyLocator.java:99)
>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublic
>>> Key(JWKPublicKeyLocator.java:63)
>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>> blicKey(AdapterRSATokenVerifier.java:44)
>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>> yToken(AdapterRSATokenVerifier.java:55)
>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>> yToken(AdapterRSATokenVerifier.java:37)
>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>> estAuthenticator.java:68)
>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>> nticate(ServletKeycloakAuthMech.java:92)
>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>> transition(SecurityContextImpl.java:245)
>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>> transition(SecurityContextImpl.java:263)
>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>> access$100(SecurityContextImpl.java:231)
>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>> ication(SecurityContextImpl.java:125)
>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>> (SecurityContextImpl.java:99)
>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>> ecurityContextImpl.java:92)
>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>> t(DisableCacheHandler.java:33)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>> aintHandler.java:64)
>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>> ndleRequest(NotificationReceiverHandler.java:50)
>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>> Handler.java:43)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>> stRequest(ServletInitialHandler.java:292)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>> 0(ServletInitialHandler.java:81)
>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>> rvletInitialHandler.java:138)
>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>> rvletInitialHandler.java:135)
>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>> l(ContextClassLoaderSetupAction.java:43)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>> equest(ServletInitialHandler.java:272)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>> 0(ServletInitialHandler.java:81)
>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>> equest(ServletInitialHandler.java:104)
>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>> ge.java:805)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1142)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:748)
>>> Caused by: java.net.ConnectException: Connection refused (Connection
>>> refused)
>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>>> etImpl.java:350)
>>> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>>> ainSocketImpl.java:206)
>>> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>>> Impl.java:188)
>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>> at java.net.Socket.connect(Socket.java:589)
>>> at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket
>>> (PlainSocketFactory.java:117)
>>> at org.apache.http.impl.conn.DefaultClientConnectionOperator.op
>>> enConnection(DefaultClientConnectionOperator.java:177)
>>> at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoo
>>> lEntry.java:144)
>>> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(Abs
>>> tractPooledConnAdapter.java:131)
>>> at org.apache.http.impl.client.DefaultRequestDirector.tryConnec
>>> t(DefaultRequestDirector.java:611)
>>> at org.apache.http.impl.client.DefaultRequestDirector.execute(D
>>> efaultRequestDirector.java:446)
>>> at org.apache.http.impl.client.AbstractHttpClient.doExecute(Abs
>>> tractHttpClient.java:882)
>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>> eableHttpClient.java:82)
>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>> eableHttpClient.java:107)
>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>> eableHttpClient.java:55)
>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>> ttpAdapterUtils.java:37)
>>> ... 52 more
>>> 2017-07-25T13:56:29.452564496Z
>>> 13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
>>> (default task-12) Didn't find publicKey for kid:
>>> RHESicBPoNCwhBnBLEk_8X4ufj5WyuTo20zbzOo4HfQ
>>> 13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
>>> (default task-12) Failed to verify token: org.keycloak.common.VerificationException:
>>> Didn't find publicKey for specified kid
>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>> blicKey(AdapterRSATokenVerifier.java:47)
>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>> yToken(AdapterRSATokenVerifier.java:55)
>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>> yToken(AdapterRSATokenVerifier.java:37)
>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>> estAuthenticator.java:68)
>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>> nticate(ServletKeycloakAuthMech.java:92)
>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>> transition(SecurityContextImpl.java:245)
>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>> transition(SecurityContextImpl.java:263)
>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>> access$100(SecurityContextImpl.java:231)
>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>> ication(SecurityContextImpl.java:125)
>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>> (SecurityContextImpl.java:99)
>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>> ecurityContextImpl.java:92)
>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>> t(DisableCacheHandler.java:33)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>> aintHandler.java:64)
>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>> ndleRequest(NotificationReceiverHandler.java:50)
>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>> Handler.java:43)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>> redicateHandler.java:43)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>> stRequest(ServletInitialHandler.java:292)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>> 0(ServletInitialHandler.java:81)
>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>> rvletInitialHandler.java:138)
>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>> rvletInitialHandler.java:135)
>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>> l(ContextClassLoaderSetupAction.java:43)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>> l(LegacyThreadSetupActionWrapper.java:44)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>> equest(ServletInitialHandler.java:272)
>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>> 0(ServletInitialHandler.java:81)
>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>> equest(ServletInitialHandler.java:104)
>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>> ge.java:805)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>> Executor.java:1142)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>> lExecutor.java:617)
>>> at java.lang.Thread.run(Thread.java:748)
>>>
>>> Is there a way to enhance the log level at the client ( i mean keycloak
>>> adapter ) ,  to see if it is a http connection issue or something else ??
>>>
>>> Thanks,
>>> Rajesh
>>>
>>> On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Here is the response from curl ---
>>>>
>>>> $ curl -v http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/services/s
>>>> ec/rest/us
>>>> erservice/users  -H "Authorization:  Bearer $KEY"
>>>> *   Trying 192.168.99.100...
>>>> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
>>>> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>> HTTP/1.1
>>>> > Host: 192.168.99.100:8080
>>>> > User-Agent: curl/7.50.1
>>>> > Accept: */*
>>>> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
>>>> AiSldUIiwia2lkIiA6ICJSSEV
>>>> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJ
>>>> qdGkiOiJkNmY2MmM5YS1
>>>> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
>>>> sIm5iZiI6MCwiaWF0Ijo
>>>> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
>>>> vYXV0aC9yZWFsbXMvYmt
>>>> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
>>>> 2YmMtOWU4MS05MjE1Zjg
>>>> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
>>>> oX3RpbWUiOjAsInNlc3N
>>>> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
>>>> lNjciLCJhY3IiOiIxIiw
>>>> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
>>>> kYTY2NmE4Y2EiLCJhbGx
>>>> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
>>>> sInJlYWxtX2FjY2VzcyI
>>>> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
>>>> 1cmNlX2FjY2VzcyI6eyJ
>>>> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
>>>> 3LWlkZW50aXR5LXByb3Z
>>>> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
>>>> 0aW9uIiwicmVhbG0tYWR
>>>> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
>>>> ob3JpemF0aW9uIiwibWF
>>>> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
>>>> ldy11c2VycyIsInZpZXc
>>>> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
>>>> udHMiXX0sImFjY291bnQ
>>>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>>>> saW5rcyIsInZpZXctcHJ
>>>> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
>>>> lcmFkbWluIiwiZW1haWw
>>>> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5Hv
>>>> G3x5WBI3ZcC4WEcBA3NU
>>>> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM
>>>> 6zLk7cy0UKig5ghHX1-g
>>>> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1
>>>> iUXAaCZ5fIdXs3epdG82
>>>> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82poh
>>>> W6RQMAZmGyMVofsxH_uR
>>>> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>> >
>>>> < HTTP/1.1 401 Unauthorized
>>>> < Expires: 0
>>>> < Cache-Control: no-cache, no-store, must-revalidate
>>>> < X-Powered-By: Undertow/1
>>>> < Server: WildFly/10
>>>> < Pragma: no-cache
>>>> < Date: Tue, 25 Jul 2017 14:04:31 GMT
>>>> < Connection: keep-alive
>>>> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
>>>> error_description="Didn't find publicKey for specified kid"
>>>> < Content-Type: text/html;charset=UTF-8
>>>> < Content-Length: 71
>>>> <
>>>> * Connection #0 to host 192.168.99.100 left intact
>>>> <html><head><title>Error</title></head><body>Unauthorized</b
>>>> ody></html>$
>>>> $
>>>>
>>>> Thanks,
>>>> Rajesh
>>>>
>>>> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Sure. I was using postman to invoke the service. This is the command
>>>>> used by postman --
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------
>>>>>
>>>>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>> HTTP/1.1
>>>>> Host: 192.168.99.100:8080
>>>>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>> Cache-Control: no-cache
>>>>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ---------------
>>>>>
>>>>> The "userservice" is my own service for other attributes of users. I
>>>>> also made sure that the service executes without the security.
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>>
>>>>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Okay, to have the complete picture could paste the command you issue
>>>>>> to call your REST service ?
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Sebastien,
>>>>>>>
>>>>>>> Here is a token response -
>>>>>>>
>>>>>>> {
>>>>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>>>>>>   "expires_in": 300,
>>>>>>>   "refresh_expires_in": 1800,
>>>>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>>>>   "token_type": "bearer",
>>>>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>>>>   "not-before-policy": 0,
>>>>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> I checked it in jwt.io . The kid is same as the "rsa-generated"
>>>>>>> one, shown in the screen shot I shared yesterday. Although jwt complained
>>>>>>> as "Invalid Signature" .
>>>>>>>
>>>>>>>
>>>>>>> Thomas, the connectivity should not be an issue as I am able to get
>>>>>>> the access token from  my app wildfly server using curl. So keycloak is
>>>>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>>>>> issue ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Rajesh
>>>>>>>
>>>>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <sblanc at redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> This looks all correct. Could you try paste your access token or
>>>>>>>> even check it your self on jwt.io to see if the kid is present ?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <
>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Sebastien,
>>>>>>>>>
>>>>>>>>> I am attaching a pdf containing the screen shots.  Few more points
>>>>>>>>> I wanted to mention.
>>>>>>>>>
>>>>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>>>>> containers locally in my laptop.
>>>>>>>>>
>>>>>>>>> Let me know if you need anything else to analyze.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Rajesh
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <
>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> yes please
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Yes definitely. I did replace it with the actual war name. Let
>>>>>>>>>>> me know if you would like me to paste screen shots of realm configurations,
>>>>>>>>>>> client configurations.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rajesh
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <
>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ok and for :
>>>>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>>>>
>>>>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>>>>> described in the
>>>>>>>>>>>>>>> document --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>>>>>>>>>>> ak-securing.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of
>>>>>>>>>>>>>>> per-war option. The
>>>>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>>>>          ......
>>>>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>>>>                 .....
>>>>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>>>>                 <credential
>>>>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credenti
>>>>>>>>>>>>>>> al>
>>>>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>>>>>>>>>>> ord=password"
>>>>>>>>>>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>>>>>>>>>>> d-connect/token
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to
>>>>>>>>>>>>>>> simulate UI login
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However when I try to use the access token to invoke a
>>>>>>>>>>>>>>> service, I am
>>>>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please let me know if I am missing something here. I have
>>>>>>>>>>>>>>> been breaking my
>>>>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From ghosh.rajesh at gmail.com  Tue Jul 25 11:09:14 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 20:39:14 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOx+eJ8ZH6+8PUe0w9cbyD0u9ZHPBNiOEvocWXXKE7OE+jA@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
	<CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
	<CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>
	<CAMZCGg_SrVKaftNYw_k_0krDsCKtFvmBJU9WY0vpUhOfCOpmkQ@mail.gmail.com>
	<CAOKDOx+eJ8ZH6+8PUe0w9cbyD0u9ZHPBNiOEvocWXXKE7OE+jA@mail.gmail.com>
Message-ID: <CAOKDOx+ZEr-FQ_Nmz8FEbX39CvHzsnaAWwQuveBm6Ynewfrr9Q@mail.gmail.com>

Sebastien,

I could get past the 401 error after rectifying the url issue. However I am
hitting 403 - Unauthorized exception now and there is no exception in log.
Still investigating. But thanks for your support on the original issue.

@Thomas Recloux ,  thank you for the tips as well.

Regards,
Rajesh

On Tue, Jul 25, 2017 at 7:48 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> OMG ! That was stupid ! Let me rectify that and try again.
>
> Thanks so much for pointing out.
>
> Regards,
> Rajesh
>
> On Tue, Jul 25, 2017 at 7:47 PM, Sebastien Blanc <sblanc at redhat.com>
> wrote:
>
>> Oh I think I found it : <auth-server-url>http://192.168.99.100/30001/auth
>> </auth-server-url>
>> You have a typo there , shouldn't it be http://192.168.99.100:30001/auth
>> <http://192.168.99.100:30001/auth/realms/bkofc/protocol/openid-connect/token>
>> , notice the ":" instead of "/"
>>
>> On Tue, Jul 25, 2017 at 4:14 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Oh you were faster than me on this one ;) , well you can change the log
>>> level of you app in the standalone.xml
>>>
>>> On Tue, Jul 25, 2017 at 4:12 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Hello Sebastien,
>>>>
>>>> I was looking at the logs of my app wildfly server ,  as suggested by
>>>> another user Thomas . Here is a relevant exception stack which I see.
>>>>
>>>> 13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
>>>> (default task-12) Error when sending request to retrieve realm keys:
>>>> org.keycloak.adapters.HttpClientAdapterException: IO error
>>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>>> ttpAdapterUtils.java:58)
>>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendReque
>>>> st(JWKPublicKeyLocator.java:99)
>>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublic
>>>> Key(JWKPublicKeyLocator.java:63)
>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>>> blicKey(AdapterRSATokenVerifier.java:44)
>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>> yToken(AdapterRSATokenVerifier.java:55)
>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>> yToken(AdapterRSATokenVerifier.java:37)
>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>>> estAuthenticator.java:68)
>>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>>> nticate(ServletKeycloakAuthMech.java:92)
>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>> transition(SecurityContextImpl.java:245)
>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>> transition(SecurityContextImpl.java:263)
>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>> access$100(SecurityContextImpl.java:231)
>>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>>> ication(SecurityContextImpl.java:125)
>>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>>> (SecurityContextImpl.java:99)
>>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>>> ecurityContextImpl.java:92)
>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>>> t(DisableCacheHandler.java:33)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>> aintHandler.java:64)
>>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>> Handler.java:43)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>> stRequest(ServletInitialHandler.java:292)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>>> 0(ServletInitialHandler.java:81)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>> rvletInitialHandler.java:138)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>> rvletInitialHandler.java:135)
>>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>>> l(ContextClassLoaderSetupAction.java:43)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>> equest(ServletInitialHandler.java:272)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>> 0(ServletInitialHandler.java:81)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>> equest(ServletInitialHandler.java:104)
>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>> java:202)
>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>> ge.java:805)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>> Caused by: java.net.ConnectException: Connection refused (Connection
>>>> refused)
>>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>>> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>>>> etImpl.java:350)
>>>> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>>>> ainSocketImpl.java:206)
>>>> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>>>> Impl.java:188)
>>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>>> at java.net.Socket.connect(Socket.java:589)
>>>> at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket
>>>> (PlainSocketFactory.java:117)
>>>> at org.apache.http.impl.conn.DefaultClientConnectionOperator.op
>>>> enConnection(DefaultClientConnectionOperator.java:177)
>>>> at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoo
>>>> lEntry.java:144)
>>>> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(Abs
>>>> tractPooledConnAdapter.java:131)
>>>> at org.apache.http.impl.client.DefaultRequestDirector.tryConnec
>>>> t(DefaultRequestDirector.java:611)
>>>> at org.apache.http.impl.client.DefaultRequestDirector.execute(D
>>>> efaultRequestDirector.java:446)
>>>> at org.apache.http.impl.client.AbstractHttpClient.doExecute(Abs
>>>> tractHttpClient.java:882)
>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>> eableHttpClient.java:82)
>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>> eableHttpClient.java:107)
>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>> eableHttpClient.java:55)
>>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>>> ttpAdapterUtils.java:37)
>>>> ... 52 more
>>>> 2017-07-25T13:56:29.452564496Z
>>>> 13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
>>>> (default task-12) Didn't find publicKey for kid:
>>>> RHESicBPoNCwhBnBLEk_8X4ufj5WyuTo20zbzOo4HfQ
>>>> 13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
>>>> (default task-12) Failed to verify token: org.keycloak.common.VerificationException:
>>>> Didn't find publicKey for specified kid
>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>>> blicKey(AdapterRSATokenVerifier.java:47)
>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>> yToken(AdapterRSATokenVerifier.java:55)
>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>> yToken(AdapterRSATokenVerifier.java:37)
>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>>> estAuthenticator.java:68)
>>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>>> nticate(ServletKeycloakAuthMech.java:92)
>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>> transition(SecurityContextImpl.java:245)
>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>> transition(SecurityContextImpl.java:263)
>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>> access$100(SecurityContextImpl.java:231)
>>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>>> ication(SecurityContextImpl.java:125)
>>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>>> (SecurityContextImpl.java:99)
>>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>>> ecurityContextImpl.java:92)
>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>>> t(DisableCacheHandler.java:33)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>> aintHandler.java:64)
>>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>> Handler.java:43)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>> redicateHandler.java:43)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>> stRequest(ServletInitialHandler.java:292)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>>> 0(ServletInitialHandler.java:81)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>> rvletInitialHandler.java:138)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>> rvletInitialHandler.java:135)
>>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>>> l(ContextClassLoaderSetupAction.java:43)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>> equest(ServletInitialHandler.java:272)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>> 0(ServletInitialHandler.java:81)
>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>> equest(ServletInitialHandler.java:104)
>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>> java:202)
>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>> ge.java:805)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>> Executor.java:1142)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>> lExecutor.java:617)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>>
>>>> Is there a way to enhance the log level at the client ( i mean keycloak
>>>> adapter ) ,  to see if it is a http connection issue or something else ??
>>>>
>>>> Thanks,
>>>> Rajesh
>>>>
>>>> On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Here is the response from curl ---
>>>>>
>>>>> $ curl -v http://192.168.99.100:8080/OlpUIFwk2-1.0-SNAPSHOT/services/s
>>>>> ec/rest/us
>>>>> erservice/users  -H "Authorization:  Bearer $KEY"
>>>>> *   Trying 192.168.99.100...
>>>>> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
>>>>> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>> HTTP/1.1
>>>>> > Host: 192.168.99.100:8080
>>>>> > User-Agent: curl/7.50.1
>>>>> > Accept: */*
>>>>> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
>>>>> AiSldUIiwia2lkIiA6ICJSSEV
>>>>> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJ
>>>>> qdGkiOiJkNmY2MmM5YS1
>>>>> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
>>>>> sIm5iZiI6MCwiaWF0Ijo
>>>>> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
>>>>> vYXV0aC9yZWFsbXMvYmt
>>>>> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
>>>>> 2YmMtOWU4MS05MjE1Zjg
>>>>> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
>>>>> oX3RpbWUiOjAsInNlc3N
>>>>> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
>>>>> lNjciLCJhY3IiOiIxIiw
>>>>> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
>>>>> kYTY2NmE4Y2EiLCJhbGx
>>>>> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
>>>>> sInJlYWxtX2FjY2VzcyI
>>>>> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
>>>>> 1cmNlX2FjY2VzcyI6eyJ
>>>>> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
>>>>> 3LWlkZW50aXR5LXByb3Z
>>>>> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
>>>>> 0aW9uIiwicmVhbG0tYWR
>>>>> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
>>>>> ob3JpemF0aW9uIiwibWF
>>>>> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
>>>>> ldy11c2VycyIsInZpZXc
>>>>> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
>>>>> udHMiXX0sImFjY291bnQ
>>>>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>>>>> saW5rcyIsInZpZXctcHJ
>>>>> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
>>>>> lcmFkbWluIiwiZW1haWw
>>>>> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5Hv
>>>>> G3x5WBI3ZcC4WEcBA3NU
>>>>> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM
>>>>> 6zLk7cy0UKig5ghHX1-g
>>>>> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1
>>>>> iUXAaCZ5fIdXs3epdG82
>>>>> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82poh
>>>>> W6RQMAZmGyMVofsxH_uR
>>>>> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>> >
>>>>> < HTTP/1.1 401 Unauthorized
>>>>> < Expires: 0
>>>>> < Cache-Control: no-cache, no-store, must-revalidate
>>>>> < X-Powered-By: Undertow/1
>>>>> < Server: WildFly/10
>>>>> < Pragma: no-cache
>>>>> < Date: Tue, 25 Jul 2017 14:04:31 GMT
>>>>> < Connection: keep-alive
>>>>> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
>>>>> error_description="Didn't find publicKey for specified kid"
>>>>> < Content-Type: text/html;charset=UTF-8
>>>>> < Content-Length: 71
>>>>> <
>>>>> * Connection #0 to host 192.168.99.100 left intact
>>>>> <html><head><title>Error</title></head><body>Unauthorized</b
>>>>> ody></html>$
>>>>> $
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sure. I was using postman to invoke the service. This is the command
>>>>>> used by postman --
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ------------
>>>>>>
>>>>>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>>> HTTP/1.1
>>>>>> Host: 192.168.99.100:8080
>>>>>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>>> Cache-Control: no-cache
>>>>>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ---------------
>>>>>>
>>>>>> The "userservice" is my own service for other attributes of users. I
>>>>>> also made sure that the service executes without the security.
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Okay, to have the complete picture could paste the command you issue
>>>>>>> to call your REST service ?
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Sebastien,
>>>>>>>>
>>>>>>>> Here is a token response -
>>>>>>>>
>>>>>>>> {
>>>>>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>>>>>>>   "expires_in": 300,
>>>>>>>>   "refresh_expires_in": 1800,
>>>>>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>>>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>>>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>>>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>>>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>>>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>>>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>>>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>>>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>>>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>>>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>>>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>>>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>>>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>>>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>>>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>>>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>>>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>>>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>>>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>>>>>   "token_type": "bearer",
>>>>>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>>>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>>>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>>>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>>>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>>>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>>>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>>>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>>>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>>>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>>>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>>>>>   "not-before-policy": 0,
>>>>>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> I checked it in jwt.io . The kid is same as the "rsa-generated"
>>>>>>>> one, shown in the screen shot I shared yesterday. Although jwt complained
>>>>>>>> as "Invalid Signature" .
>>>>>>>>
>>>>>>>>
>>>>>>>> Thomas, the connectivity should not be an issue as I am able to get
>>>>>>>> the access token from  my app wildfly server using curl. So keycloak is
>>>>>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>>>>>> issue ?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Rajesh
>>>>>>>>
>>>>>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <
>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> This looks all correct. Could you try paste your access token or
>>>>>>>>> even check it your self on jwt.io to see if the kid is present ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <
>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Sebastien,
>>>>>>>>>>
>>>>>>>>>> I am attaching a pdf containing the screen shots.  Few more
>>>>>>>>>> points I wanted to mention.
>>>>>>>>>>
>>>>>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>>>>>> containers locally in my laptop.
>>>>>>>>>>
>>>>>>>>>> Let me know if you need anything else to analyze.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rajesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> yes please
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes definitely. I did replace it with the actual war name. Let
>>>>>>>>>>>> me know if you would like me to paste screen shots of realm configurations,
>>>>>>>>>>>> client configurations.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <
>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ok and for :
>>>>>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>>>>>> described in the
>>>>>>>>>>>>>>>> document --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://blog.keycloak.org/2015/
>>>>>>>>>>>>>>>> 10/getting-started-with-keycloak-securing.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of
>>>>>>>>>>>>>>>> per-war option. The
>>>>>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>>>>>          ......
>>>>>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>>>>>                 .....
>>>>>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <use-resource-role-mappings>tr
>>>>>>>>>>>>>>>> ue</use-resource-role-mappings>
>>>>>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>>>>>                 <credential
>>>>>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b
>>>>>>>>>>>>>>>> 58-b297-79f0f207d9e1</credential>
>>>>>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>>>>>> "grant_type=password&client_id
>>>>>>>>>>>>>>>> =bkofc-web&username=user&password=password"
>>>>>>>>>>>>>>>> http://192.168.99.100:30001/au
>>>>>>>>>>>>>>>> th/realms/bkofc/protocol/openid-connect/token
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to
>>>>>>>>>>>>>>>> simulate UI login
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> However when I try to use the access token to invoke a
>>>>>>>>>>>>>>>> service, I am
>>>>>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc",
>>>>>>>>>>>>>>>> error="invalid_token",
>>>>>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please let me know if I am missing something here. I have
>>>>>>>>>>>>>>>> been breaking my
>>>>>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sblanc at redhat.com  Tue Jul 25 11:15:33 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 25 Jul 2017 17:15:33 +0200
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAOKDOx+ZEr-FQ_Nmz8FEbX39CvHzsnaAWwQuveBm6Ynewfrr9Q@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
	<CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
	<CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>
	<CAMZCGg_SrVKaftNYw_k_0krDsCKtFvmBJU9WY0vpUhOfCOpmkQ@mail.gmail.com>
	<CAOKDOx+eJ8ZH6+8PUe0w9cbyD0u9ZHPBNiOEvocWXXKE7OE+jA@mail.gmail.com>
	<CAOKDOx+ZEr-FQ_Nmz8FEbX39CvHzsnaAWwQuveBm6Ynewfrr9Q@mail.gmail.com>
Message-ID: <CAMZCGg8wBO4-5hz_+RbOK69s6FcBa67o7Ju5GxmYpRq6jZq=Zw@mail.gmail.com>

403, you have probably something not setup correctly with your user's role.

On Tue, Jul 25, 2017 at 5:09 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
wrote:

> Sebastien,
>
> I could get past the 401 error after rectifying the url issue. However I
> am hitting 403 - Unauthorized exception now and there is no exception in
> log. Still investigating. But thanks for your support on the original
> issue.
>
> @Thomas Recloux ,  thank you for the tips as well.
>
> Regards,
> Rajesh
>
> On Tue, Jul 25, 2017 at 7:48 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> OMG ! That was stupid ! Let me rectify that and try again.
>>
>> Thanks so much for pointing out.
>>
>> Regards,
>> Rajesh
>>
>> On Tue, Jul 25, 2017 at 7:47 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Oh I think I found it : <auth-server-url>http://192.16
>>> 8.99.100/30001/auth
>>> </auth-server-url>
>>> You have a typo there , shouldn't it be http://192.168.99.100:30001/auth
>>> <http://192.168.99.100:30001/auth/realms/bkofc/protocol/openid-connect/token>
>>> , notice the ":" instead of "/"
>>>
>>> On Tue, Jul 25, 2017 at 4:14 PM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Oh you were faster than me on this one ;) , well you can change the log
>>>> level of you app in the standalone.xml
>>>>
>>>> On Tue, Jul 25, 2017 at 4:12 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Sebastien,
>>>>>
>>>>> I was looking at the logs of my app wildfly server ,  as suggested by
>>>>> another user Thomas . Here is a relevant exception stack which I see.
>>>>>
>>>>> 13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
>>>>> (default task-12) Error when sending request to retrieve realm keys:
>>>>> org.keycloak.adapters.HttpClientAdapterException: IO error
>>>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>>>> ttpAdapterUtils.java:58)
>>>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendReque
>>>>> st(JWKPublicKeyLocator.java:99)
>>>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublic
>>>>> Key(JWKPublicKeyLocator.java:63)
>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>>>> blicKey(AdapterRSATokenVerifier.java:44)
>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>> yToken(AdapterRSATokenVerifier.java:55)
>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>> yToken(AdapterRSATokenVerifier.java:37)
>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>>>> estAuthenticator.java:68)
>>>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>>>> nticate(ServletKeycloakAuthMech.java:92)
>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>> transition(SecurityContextImpl.java:245)
>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>> transition(SecurityContextImpl.java:263)
>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>> access$100(SecurityContextImpl.java:231)
>>>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>>>> ication(SecurityContextImpl.java:125)
>>>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>>>> (SecurityContextImpl.java:99)
>>>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>>>> ecurityContextImpl.java:92)
>>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>>>> t(DisableCacheHandler.java:33)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>>> aintHandler.java:64)
>>>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>>> Handler.java:43)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>>> stRequest(ServletInitialHandler.java:292)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>>>> 0(ServletInitialHandler.java:81)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>> rvletInitialHandler.java:138)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>> rvletInitialHandler.java:135)
>>>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>>>> l(ContextClassLoaderSetupAction.java:43)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>>> equest(ServletInitialHandler.java:272)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>>> 0(ServletInitialHandler.java:81)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>>> equest(ServletInitialHandler.java:104)
>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>>> java:202)
>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>>> ge.java:805)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>>> Executor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>>> lExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>> Caused by: java.net.ConnectException: Connection refused (Connection
>>>>> refused)
>>>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>>>> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>>>>> etImpl.java:350)
>>>>> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>>>>> ainSocketImpl.java:206)
>>>>> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>>>>> Impl.java:188)
>>>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>>>> at java.net.Socket.connect(Socket.java:589)
>>>>> at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket
>>>>> (PlainSocketFactory.java:117)
>>>>> at org.apache.http.impl.conn.DefaultClientConnectionOperator.op
>>>>> enConnection(DefaultClientConnectionOperator.java:177)
>>>>> at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoo
>>>>> lEntry.java:144)
>>>>> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(Abs
>>>>> tractPooledConnAdapter.java:131)
>>>>> at org.apache.http.impl.client.DefaultRequestDirector.tryConnec
>>>>> t(DefaultRequestDirector.java:611)
>>>>> at org.apache.http.impl.client.DefaultRequestDirector.execute(D
>>>>> efaultRequestDirector.java:446)
>>>>> at org.apache.http.impl.client.AbstractHttpClient.doExecute(Abs
>>>>> tractHttpClient.java:882)
>>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>>> eableHttpClient.java:82)
>>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>>> eableHttpClient.java:107)
>>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>>> eableHttpClient.java:55)
>>>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>>>> ttpAdapterUtils.java:37)
>>>>> ... 52 more
>>>>> 2017-07-25T13:56:29.452564496Z
>>>>> 13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
>>>>> (default task-12) Didn't find publicKey for kid:
>>>>> RHESicBPoNCwhBnBLEk_8X4ufj5WyuTo20zbzOo4HfQ
>>>>> 13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
>>>>> (default task-12) Failed to verify token: org.keycloak.common.VerificationException:
>>>>> Didn't find publicKey for specified kid
>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>>>> blicKey(AdapterRSATokenVerifier.java:47)
>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>> yToken(AdapterRSATokenVerifier.java:55)
>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>> yToken(AdapterRSATokenVerifier.java:37)
>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>>>> estAuthenticator.java:68)
>>>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>>>> nticate(ServletKeycloakAuthMech.java:92)
>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>> transition(SecurityContextImpl.java:245)
>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>> transition(SecurityContextImpl.java:263)
>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>> access$100(SecurityContextImpl.java:231)
>>>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>>>> ication(SecurityContextImpl.java:125)
>>>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>>>> (SecurityContextImpl.java:99)
>>>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>>>> ecurityContextImpl.java:92)
>>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>>>> t(DisableCacheHandler.java:33)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>>> aintHandler.java:64)
>>>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>>> Handler.java:43)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>> redicateHandler.java:43)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>>> stRequest(ServletInitialHandler.java:292)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>>>> 0(ServletInitialHandler.java:81)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>> rvletInitialHandler.java:138)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>> rvletInitialHandler.java:135)
>>>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>>>> l(ContextClassLoaderSetupAction.java:43)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>>> equest(ServletInitialHandler.java:272)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>>> 0(ServletInitialHandler.java:81)
>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>>> equest(ServletInitialHandler.java:104)
>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>>> java:202)
>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>>> ge.java:805)
>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>>> Executor.java:1142)
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>>> lExecutor.java:617)
>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>
>>>>> Is there a way to enhance the log level at the client ( i mean
>>>>> keycloak adapter ) ,  to see if it is a http connection issue or something
>>>>> else ??
>>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>> On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Here is the response from curl ---
>>>>>>
>>>>>> $ curl -v http://192.168.99.100:8080/Olp
>>>>>> UIFwk2-1.0-SNAPSHOT/services/sec/rest/us
>>>>>> erservice/users  -H "Authorization:  Bearer $KEY"
>>>>>> *   Trying 192.168.99.100...
>>>>>> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
>>>>>> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>>> HTTP/1.1
>>>>>> > Host: 192.168.99.100:8080
>>>>>> > User-Agent: curl/7.50.1
>>>>>> > Accept: */*
>>>>>> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
>>>>>> AiSldUIiwia2lkIiA6ICJSSEV
>>>>>> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJ
>>>>>> qdGkiOiJkNmY2MmM5YS1
>>>>>> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
>>>>>> sIm5iZiI6MCwiaWF0Ijo
>>>>>> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
>>>>>> vYXV0aC9yZWFsbXMvYmt
>>>>>> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
>>>>>> 2YmMtOWU4MS05MjE1Zjg
>>>>>> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
>>>>>> oX3RpbWUiOjAsInNlc3N
>>>>>> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
>>>>>> lNjciLCJhY3IiOiIxIiw
>>>>>> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
>>>>>> kYTY2NmE4Y2EiLCJhbGx
>>>>>> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
>>>>>> sInJlYWxtX2FjY2VzcyI
>>>>>> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
>>>>>> 1cmNlX2FjY2VzcyI6eyJ
>>>>>> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
>>>>>> 3LWlkZW50aXR5LXByb3Z
>>>>>> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
>>>>>> 0aW9uIiwicmVhbG0tYWR
>>>>>> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
>>>>>> ob3JpemF0aW9uIiwibWF
>>>>>> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
>>>>>> ldy11c2VycyIsInZpZXc
>>>>>> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
>>>>>> udHMiXX0sImFjY291bnQ
>>>>>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>>>>>> saW5rcyIsInZpZXctcHJ
>>>>>> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
>>>>>> lcmFkbWluIiwiZW1haWw
>>>>>> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5Hv
>>>>>> G3x5WBI3ZcC4WEcBA3NU
>>>>>> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM
>>>>>> 6zLk7cy0UKig5ghHX1-g
>>>>>> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1
>>>>>> iUXAaCZ5fIdXs3epdG82
>>>>>> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82poh
>>>>>> W6RQMAZmGyMVofsxH_uR
>>>>>> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>>> >
>>>>>> < HTTP/1.1 401 Unauthorized
>>>>>> < Expires: 0
>>>>>> < Cache-Control: no-cache, no-store, must-revalidate
>>>>>> < X-Powered-By: Undertow/1
>>>>>> < Server: WildFly/10
>>>>>> < Pragma: no-cache
>>>>>> < Date: Tue, 25 Jul 2017 14:04:31 GMT
>>>>>> < Connection: keep-alive
>>>>>> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>> < Content-Type: text/html;charset=UTF-8
>>>>>> < Content-Length: 71
>>>>>> <
>>>>>> * Connection #0 to host 192.168.99.100 left intact
>>>>>> <html><head><title>Error</title></head><body>Unauthorized</b
>>>>>> ody></html>$
>>>>>> $
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Sure. I was using postman to invoke the service. This is the command
>>>>>>> used by postman --
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------
>>>>>>>
>>>>>>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>>>> HTTP/1.1
>>>>>>> Host: 192.168.99.100:8080
>>>>>>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>>>> Cache-Control: no-cache
>>>>>>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------------
>>>>>>>
>>>>>>> The "userservice" is my own service for other attributes of users. I
>>>>>>> also made sure that the service executes without the security.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rajesh
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Okay, to have the complete picture could paste the command you
>>>>>>>> issue to call your REST service ?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <
>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Sebastien,
>>>>>>>>>
>>>>>>>>> Here is a token response -
>>>>>>>>>
>>>>>>>>> {
>>>>>>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw",
>>>>>>>>>   "expires_in": 300,
>>>>>>>>>   "refresh_expires_in": 1800,
>>>>>>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>>>>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>>>>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>>>>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>>>>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>>>>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>>>>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>>>>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>>>>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>>>>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>>>>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>>>>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>>>>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>>>>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>>>>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>>>>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>>>>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>>>>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>>>>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>>>>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sampLww",
>>>>>>>>>   "token_type": "bearer",
>>>>>>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>>>>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>>>>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>>>>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>>>>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>>>>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>>>>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>>>>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>>>>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>>>>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>>>>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>>>>>>   "not-before-policy": 0,
>>>>>>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I checked it in jwt.io . The kid is same as the "rsa-generated"
>>>>>>>>> one, shown in the screen shot I shared yesterday. Although jwt complained
>>>>>>>>> as "Invalid Signature" .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thomas, the connectivity should not be an issue as I am able to
>>>>>>>>> get the access token from  my app wildfly server using curl. So keycloak is
>>>>>>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>>>>>>> issue ?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Rajesh
>>>>>>>>>
>>>>>>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <
>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> This looks all correct. Could you try paste your access token or
>>>>>>>>>> even check it your self on jwt.io to see if the kid is present ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <
>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Sebastien,
>>>>>>>>>>>
>>>>>>>>>>> I am attaching a pdf containing the screen shots.  Few more
>>>>>>>>>>> points I wanted to mention.
>>>>>>>>>>>
>>>>>>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>>>>>>> containers locally in my laptop.
>>>>>>>>>>>
>>>>>>>>>>> Let me know if you need anything else to analyze.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Rajesh
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <
>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> yes please
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes definitely. I did replace it with the actual war name. Let
>>>>>>>>>>>>> me know if you would like me to paste screen shots of realm configurations,
>>>>>>>>>>>>> client configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <
>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok and for :
>>>>>>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>>>>>>> described in the
>>>>>>>>>>>>>>>>> document --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://blog.keycloak.org/2015/
>>>>>>>>>>>>>>>>> 10/getting-started-with-keycloak-securing.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of
>>>>>>>>>>>>>>>>> per-war option. The
>>>>>>>>>>>>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>>>>>>          ......
>>>>>>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>>>>>>                 .....
>>>>>>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <use-resource-role-mappings>tr
>>>>>>>>>>>>>>>>> ue</use-resource-role-mappings>
>>>>>>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>>>>>>                 <credential
>>>>>>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b
>>>>>>>>>>>>>>>>> 58-b297-79f0f207d9e1</credential>
>>>>>>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>>>>>>> "grant_type=password&client_id
>>>>>>>>>>>>>>>>> =bkofc-web&username=user&password=password"
>>>>>>>>>>>>>>>>> http://192.168.99.100:30001/au
>>>>>>>>>>>>>>>>> th/realms/bkofc/protocol/openid-connect/token
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to
>>>>>>>>>>>>>>>>> simulate UI login
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However when I try to use the access token to invoke a
>>>>>>>>>>>>>>>>> service, I am
>>>>>>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc",
>>>>>>>>>>>>>>>>> error="invalid_token",
>>>>>>>>>>>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please let me know if I am missing something here. I have
>>>>>>>>>>>>>>>>> been breaking my
>>>>>>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From adrianmatei at gmail.com  Tue Jul 25 11:33:32 2017
From: adrianmatei at gmail.com (Adrian Matei)
Date: Tue, 25 Jul 2017 17:33:32 +0200
Subject: [keycloak-user] RH SSO 7.1.1 derived from Keycloak x.y.z?
Message-ID: <CAG=THF3jTSzJ0=wGS7zXiWCc1EKftbGx2Oapj4ANhx9D=vVydA@mail.gmail.com>

Hello guys,

Does anyone know from which Keycloak Version is the RH SSO 7.1.1 patch
derived from?

Thanks,
Adrian

From ghosh.rajesh at gmail.com  Tue Jul 25 13:37:12 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Tue, 25 Jul 2017 23:07:12 +0530
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg8wBO4-5hz_+RbOK69s6FcBa67o7Ju5GxmYpRq6jZq=Zw@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
	<CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>
	<CAMZCGg-2Vj3RNzz3PY+U4U0SAwSujM5=i2ga6BJZWbu-vpv8Pg@mail.gmail.com>
	<CAOKDOx+QXj7SP_6skeHmRE=VzCArPVXi_Ru_uJ8fAB+Gf7UPJw@mail.gmail.com>
	<CAMZCGg_upzLV_SDo6-bX4MQ0C+peo+zNrBEChDzUQKx5UiP7RQ@mail.gmail.com>
	<CAOKDOxJ9c-cWkh=4SrmSM19xUbVg4z0RpkBxNQYiznJd9+uMDQ@mail.gmail.com>
	<CAOKDOxKDu3S6Mi4fZnjvQmfHnv1LoWvygJWnDXi1fNhz2=nQ-w@mail.gmail.com>
	<CAOKDOxLQOZM_=NzaXGQc_+SP06=Y0vjNuu4D-9yDR3=fMXQ3aw@mail.gmail.com>
	<CAMZCGg8Gf+gqktDEowvLtrUifz9TrTvGgQ4iTdx39+Rzr5Y7AQ@mail.gmail.com>
	<CAMZCGg_SrVKaftNYw_k_0krDsCKtFvmBJU9WY0vpUhOfCOpmkQ@mail.gmail.com>
	<CAOKDOx+eJ8ZH6+8PUe0w9cbyD0u9ZHPBNiOEvocWXXKE7OE+jA@mail.gmail.com>
	<CAOKDOx+ZEr-FQ_Nmz8FEbX39CvHzsnaAWwQuveBm6Ynewfrr9Q@mail.gmail.com>
	<CAMZCGg8wBO4-5hz_+RbOK69s6FcBa67o7Ju5GxmYpRq6jZq=Zw@mail.gmail.com>
Message-ID: <CAOKDOxKKR5VHR1xGdOwXO-8Qjwu0kbbSs1g2bQZJ9_-t+qRoQw@mail.gmail.com>

Well, first I allowed all roles in my web.xml  as in --

        <auth-constraint>
            <role-name>*</role-name>
        </auth-constraint>

Even then I was hitting the issue. Then while I was going through the
client installation for wildfly subsystem, I read about the
use-resource-role-mapping --

<secure-deployment name="WAR MODULE NAME.war">
    <realm>bkofc</realm>
    <auth-server-url>http://192.168.99.100:30001/auth</auth-server-url>
    <bearer-only>true</bearer-only>
    <ssl-required>NONE</ssl-required>
    <resource>bkofc-svc</resource>
    <credential
name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
    <use-resource-role-mappings>true</use-resource-role-mappings>
</secure-deployment>

It was set to true,  as provided in keycloak console. When I turned it to
the default value "false" ,  everything started working.  Do we know which
client configuration parameter , controls this element ? By default it
should have the default value "false",  isn't it ??

Thanks for all your help into this.

Regards,
Rajesh

On Tue, Jul 25, 2017 at 8:45 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> 403, you have probably something not setup correctly with your user's
> role.
>
> On Tue, Jul 25, 2017 at 5:09 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Sebastien,
>>
>> I could get past the 401 error after rectifying the url issue. However I
>> am hitting 403 - Unauthorized exception now and there is no exception in
>> log. Still investigating. But thanks for your support on the original
>> issue.
>>
>> @Thomas Recloux ,  thank you for the tips as well.
>>
>> Regards,
>> Rajesh
>>
>> On Tue, Jul 25, 2017 at 7:48 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>> wrote:
>>
>>> OMG ! That was stupid ! Let me rectify that and try again.
>>>
>>> Thanks so much for pointing out.
>>>
>>> Regards,
>>> Rajesh
>>>
>>> On Tue, Jul 25, 2017 at 7:47 PM, Sebastien Blanc <sblanc at redhat.com>
>>> wrote:
>>>
>>>> Oh I think I found it : <auth-server-url>http://192.16
>>>> 8.99.100/30001/auth
>>>> </auth-server-url>
>>>> You have a typo there , shouldn't it be http://192.168.99.100:30001/au
>>>> th
>>>> <http://192.168.99.100:30001/auth/realms/bkofc/protocol/openid-connect/token>
>>>> , notice the ":" instead of "/"
>>>>
>>>> On Tue, Jul 25, 2017 at 4:14 PM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> Oh you were faster than me on this one ;) , well you can change the
>>>>> log level of you app in the standalone.xml
>>>>>
>>>>> On Tue, Jul 25, 2017 at 4:12 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello Sebastien,
>>>>>>
>>>>>> I was looking at the logs of my app wildfly server ,  as suggested by
>>>>>> another user Thomas . Here is a relevant exception stack which I see.
>>>>>>
>>>>>> 13:56:29,450 ERROR [org.keycloak.adapters.rotation.JWKPublicKeyLocator]
>>>>>> (default task-12) Error when sending request to retrieve realm keys:
>>>>>> org.keycloak.adapters.HttpClientAdapterException: IO error
>>>>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>>>>> ttpAdapterUtils.java:58)
>>>>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.sendReque
>>>>>> st(JWKPublicKeyLocator.java:99)
>>>>>> at org.keycloak.adapters.rotation.JWKPublicKeyLocator.getPublic
>>>>>> Key(JWKPublicKeyLocator.java:63)
>>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>>>>> blicKey(AdapterRSATokenVerifier.java:44)
>>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>>> yToken(AdapterRSATokenVerifier.java:55)
>>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>>> yToken(AdapterRSATokenVerifier.java:37)
>>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>>>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>>>>> estAuthenticator.java:68)
>>>>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>>>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>>>>> nticate(ServletKeycloakAuthMech.java:92)
>>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>>> transition(SecurityContextImpl.java:245)
>>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>>> transition(SecurityContextImpl.java:263)
>>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>>> access$100(SecurityContextImpl.java:231)
>>>>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>>>>> ication(SecurityContextImpl.java:125)
>>>>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>>>>> (SecurityContextImpl.java:99)
>>>>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>>>>> ecurityContextImpl.java:92)
>>>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>>>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>>>>> t(DisableCacheHandler.java:33)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>>>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>>>> aintHandler.java:64)
>>>>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>>>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>>>> Handler.java:43)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>>>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>>>> stRequest(ServletInitialHandler.java:292)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>>>>> 0(ServletInitialHandler.java:81)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>>> rvletInitialHandler.java:138)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>>> rvletInitialHandler.java:135)
>>>>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>>>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>>>>> l(ContextClassLoaderSetupAction.java:43)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>>>> equest(ServletInitialHandler.java:272)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>>>> 0(ServletInitialHandler.java:81)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>>>> equest(ServletInitialHandler.java:104)
>>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>>>> java:202)
>>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>>>> ge.java:805)
>>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>>>> Executor.java:1142)
>>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>>>> lExecutor.java:617)
>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>> Caused by: java.net.ConnectException: Connection refused (Connection
>>>>>> refused)
>>>>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>>>>> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>>>>>> etImpl.java:350)
>>>>>> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>>>>>> ainSocketImpl.java:206)
>>>>>> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>>>>>> Impl.java:188)
>>>>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>>>>> at java.net.Socket.connect(Socket.java:589)
>>>>>> at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket
>>>>>> (PlainSocketFactory.java:117)
>>>>>> at org.apache.http.impl.conn.DefaultClientConnectionOperator.op
>>>>>> enConnection(DefaultClientConnectionOperator.java:177)
>>>>>> at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoo
>>>>>> lEntry.java:144)
>>>>>> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(Abs
>>>>>> tractPooledConnAdapter.java:131)
>>>>>> at org.apache.http.impl.client.DefaultRequestDirector.tryConnec
>>>>>> t(DefaultRequestDirector.java:611)
>>>>>> at org.apache.http.impl.client.DefaultRequestDirector.execute(D
>>>>>> efaultRequestDirector.java:446)
>>>>>> at org.apache.http.impl.client.AbstractHttpClient.doExecute(Abs
>>>>>> tractHttpClient.java:882)
>>>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>>>> eableHttpClient.java:82)
>>>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>>>> eableHttpClient.java:107)
>>>>>> at org.apache.http.impl.client.CloseableHttpClient.execute(Clos
>>>>>> eableHttpClient.java:55)
>>>>>> at org.keycloak.adapters.HttpAdapterUtils.sendJsonHttpRequest(H
>>>>>> ttpAdapterUtils.java:37)
>>>>>> ... 52 more
>>>>>> 2017-07-25T13:56:29.452564496Z
>>>>>> 13:56:29,454 ERROR [org.keycloak.adapters.rotation.AdapterRSATokenVerifier]
>>>>>> (default task-12) Didn't find publicKey for kid:
>>>>>> RHESicBPoNCwhBnBLEk_8X4ufj5WyuTo20zbzOo4HfQ
>>>>>> 13:56:29,454 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
>>>>>> (default task-12) Failed to verify token: org.keycloak.common.VerificationException:
>>>>>> Didn't find publicKey for specified kid
>>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPu
>>>>>> blicKey(AdapterRSATokenVerifier.java:47)
>>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>>> yToken(AdapterRSATokenVerifier.java:55)
>>>>>> at org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verif
>>>>>> yToken(AdapterRSATokenVerifier.java:37)
>>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>>> ticateToken(BearerTokenRequestAuthenticator.java:87)
>>>>>> at org.keycloak.adapters.BearerTokenRequestAuthenticator.authen
>>>>>> ticate(BearerTokenRequestAuthenticator.java:82)
>>>>>> at org.keycloak.adapters.RequestAuthenticator.authenticate(Requ
>>>>>> estAuthenticator.java:68)
>>>>>> at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthM
>>>>>> ech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>> at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authe
>>>>>> nticate(ServletKeycloakAuthMech.java:92)
>>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>>> transition(SecurityContextImpl.java:245)
>>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>>> transition(SecurityContextImpl.java:263)
>>>>>> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.
>>>>>> access$100(SecurityContextImpl.java:231)
>>>>>> at io.undertow.security.impl.SecurityContextImpl.attemptAuthent
>>>>>> ication(SecurityContextImpl.java:125)
>>>>>> at io.undertow.security.impl.SecurityContextImpl.authTransition
>>>>>> (SecurityContextImpl.java:99)
>>>>>> at io.undertow.security.impl.SecurityContextImpl.authenticate(S
>>>>>> ecurityContextImpl.java:92)
>>>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationC
>>>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
>>>>>> at io.undertow.server.handlers.DisableCacheHandler.handleReques
>>>>>> t(DisableCacheHandler.java:33)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at io.undertow.security.handlers.AuthenticationConstraintHandle
>>>>>> r.handleRequest(AuthenticationConstraintHandler.java:53)
>>>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler
>>>>>> .handleRequest(AbstractConfidentialityHandler.java:46)
>>>>>> at io.undertow.servlet.handlers.security.ServletConfidentiality
>>>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr
>>>>>> aintHandler.java:64)
>>>>>> at io.undertow.servlet.handlers.security.ServletSecurityConstra
>>>>>> intHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
>>>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandle
>>>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60)
>>>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSes
>>>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>>>>> at io.undertow.security.handlers.NotificationReceiverHandler.ha
>>>>>> ndleRequest(NotificationReceiverHandler.java:50)
>>>>>> at io.undertow.security.handlers.AbstractSecurityContextAssocia
>>>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation
>>>>>> Handler.java:43)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHa
>>>>>> ndler.handleRequest(JACCContextIdHandler.java:61)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.
>>>>>> handleRequest(ServletPreAuthActionsHandler.java:69)
>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(P
>>>>>> redicateHandler.java:43)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFir
>>>>>> stRequest(ServletInitialHandler.java:292)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$10
>>>>>> 0(ServletInitialHandler.java:81)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>>> rvletInitialHandler.java:138)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(Se
>>>>>> rvletInitialHandler.java:135)
>>>>>> at io.undertow.servlet.core.ServletRequestContextThreadSetupAct
>>>>>> ion$1.call(ServletRequestContextThreadSetupAction.java:48)
>>>>>> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.cal
>>>>>> l(ContextClassLoaderSetupAction.java:43)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.cal
>>>>>> l(LegacyThreadSetupActionWrapper.java:44)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
>>>>>> equest(ServletInitialHandler.java:272)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$00
>>>>>> 0(ServletInitialHandler.java:81)
>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
>>>>>> equest(ServletInitialHandler.java:104)
>>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.
>>>>>> java:202)
>>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan
>>>>>> ge.java:805)
>>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>>>>>> Executor.java:1142)
>>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>>>>>> lExecutor.java:617)
>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>
>>>>>> Is there a way to enhance the log level at the client ( i mean
>>>>>> keycloak adapter ) ,  to see if it is a http connection issue or something
>>>>>> else ??
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>>
>>>>>> On Tue, Jul 25, 2017 at 7:36 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Here is the response from curl ---
>>>>>>>
>>>>>>> $ curl -v http://192.168.99.100:8080/Olp
>>>>>>> UIFwk2-1.0-SNAPSHOT/services/sec/rest/us
>>>>>>> erservice/users  -H "Authorization:  Bearer $KEY"
>>>>>>> *   Trying 192.168.99.100...
>>>>>>> * Connected to 192.168.99.100 (192.168.99.100) port 8080 (#0)
>>>>>>> > GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>>>> HTTP/1.1
>>>>>>> > Host: 192.168.99.100:8080
>>>>>>> > User-Agent: curl/7.50.1
>>>>>>> > Accept: */*
>>>>>>> > Authorization:  Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOi
>>>>>>> AiSldUIiwia2lkIiA6ICJSSEV
>>>>>>> TaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXeXVUbzIwemJ6T280SGZRIn0.eyJ
>>>>>>> qdGkiOiJkNmY2MmM5YS1
>>>>>>> hNjAwLTQ4ZmQtYmI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDg
>>>>>>> sIm5iZiI6MCwiaWF0Ijo
>>>>>>> xNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6MzAwMDE
>>>>>>> vYXV0aC9yZWFsbXMvYmt
>>>>>>> vZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzdWIiOiIwYTA5MTQ0OC0wNjAyLTQ
>>>>>>> 2YmMtOWU4MS05MjE1Zjg
>>>>>>> zYjVjOTgiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXR
>>>>>>> oX3RpbWUiOjAsInNlc3N
>>>>>>> pb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhMjEzOTZ
>>>>>>> lNjciLCJhY3IiOiIxIiw
>>>>>>> iY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1ZDQtYjdmNy0xNWF
>>>>>>> kYTY2NmE4Y2EiLCJhbGx
>>>>>>> vd2VkLW9yaWdpbnMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0
>>>>>>> sInJlYWxtX2FjY2VzcyI
>>>>>>> 6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sInJlc29
>>>>>>> 1cmNlX2FjY2VzcyI6eyJ
>>>>>>> yZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctcmVhbG0iLCJ2aWV
>>>>>>> 3LWlkZW50aXR5LXByb3Z
>>>>>>> pZGVycyIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF
>>>>>>> 0aW9uIiwicmVhbG0tYWR
>>>>>>> taW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlldy1hdXR
>>>>>>> ob3JpemF0aW9uIiwibWF
>>>>>>> uYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidml
>>>>>>> ldy11c2VycyIsInZpZXc
>>>>>>> tY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWV
>>>>>>> udHMiXX0sImFjY291bnQ
>>>>>>> iOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1
>>>>>>> saW5rcyIsInZpZXctcHJ
>>>>>>> vZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzdXB
>>>>>>> lcmFkbWluIiwiZW1haWw
>>>>>>> iOiJ0cmlsaWEudGVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5Hv
>>>>>>> G3x5WBI3ZcC4WEcBA3NU
>>>>>>> L-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI09JAjM
>>>>>>> 6zLk7cy0UKig5ghHX1-g
>>>>>>> Xb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFwDmCMyWj8bqyoFMDTIp_Gz67Wt1
>>>>>>> iUXAaCZ5fIdXs3epdG82
>>>>>>> NhJrjQsIKiYGzUg9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82poh
>>>>>>> W6RQMAZmGyMVofsxH_uR
>>>>>>> rEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>>>> >
>>>>>>> < HTTP/1.1 401 Unauthorized
>>>>>>> < Expires: 0
>>>>>>> < Cache-Control: no-cache, no-store, must-revalidate
>>>>>>> < X-Powered-By: Undertow/1
>>>>>>> < Server: WildFly/10
>>>>>>> < Pragma: no-cache
>>>>>>> < Date: Tue, 25 Jul 2017 14:04:31 GMT
>>>>>>> < Connection: keep-alive
>>>>>>> < WWW-Authenticate: Bearer realm="bkofc", error="invalid_token",
>>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>> < Content-Type: text/html;charset=UTF-8
>>>>>>> < Content-Length: 71
>>>>>>> <
>>>>>>> * Connection #0 to host 192.168.99.100 left intact
>>>>>>> <html><head><title>Error</title></head><body>Unauthorized</b
>>>>>>> ody></html>$
>>>>>>> $
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rajesh
>>>>>>>
>>>>>>> On Tue, Jul 25, 2017 at 7:30 PM, Rajesh Ghosh <
>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Sure. I was using postman to invoke the service. This is the
>>>>>>>> command used by postman --
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ------------
>>>>>>>>
>>>>>>>> GET /OlpUIFwk2-1.0-SNAPSHOT/services/sec/rest/userservice/users
>>>>>>>> HTTP/1.1
>>>>>>>> Host: 192.168.99.100:8080
>>>>>>>> Authorization: Bearer  eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAegmCpw
>>>>>>>> Cache-Control: no-cache
>>>>>>>> Postman-Token: d378eefe-82c8-9c3d-0140-ef56c62f9b97
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------------
>>>>>>>>
>>>>>>>> The "userservice" is my own service for other attributes of users.
>>>>>>>> I also made sure that the service executes without the security.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rajesh
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 25, 2017 at 7:24 PM, Sebastien Blanc <sblanc at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Okay, to have the complete picture could paste the command you
>>>>>>>>> issue to call your REST service ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jul 25, 2017 at 3:50 PM, Rajesh Ghosh <
>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Sebastien,
>>>>>>>>>>
>>>>>>>>>> Here is a token response -
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>   "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiJkNmY2MmM5YS1hNjAwLTQ4ZmQtY
>>>>>>>>>> mI3Ny0wMTI1NDQ0YmIzNWMiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>>>> XAiOiJCZWFyZXIiLCJhenAiOiJia29mYy13ZWIiLCJhdXRoX3RpbWUiOjAsI
>>>>>>>>>> nNlc3Npb25fc3RhdGUiOiIzMjMxZjQ2Zi0yMjliLTQyZDMtYTQxOS0wODlhM
>>>>>>>>>> jEzOTZlNjciLCJhY3IiOiIxIiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2M
>>>>>>>>>> C03ZTkyLTQ1ZDQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJhbGxvd2VkLW9yaWdpb
>>>>>>>>>> nMiOlsiaHR0cDovLzE5Mi4xNjguOTkuMTAwOjgwODAvIl0sInJlYWxtX2FjY
>>>>>>>>>> 2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiIsInVzZXIiXX0sI
>>>>>>>>>> nJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzI
>>>>>>>>>> jpbInZpZXctcmVhbG0iLCJ2aWV3LWlkZW50aXR5LXByb3ZpZGVycyIsIm1hb
>>>>>>>>>> mFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhb
>>>>>>>>>> G0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwidmlld
>>>>>>>>>> y1hdXRob3JpemF0aW9uIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsb
>>>>>>>>>> SIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsI
>>>>>>>>>> m1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiXX0sImFjY
>>>>>>>>>> 291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb
>>>>>>>>>> 3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sIm5hbWUiOiIiLCJwcmVmZ
>>>>>>>>>> XJyZWRfdXNlcm5hbWUiOiJzdXBlcmFkbWluIiwiZW1haWwiOiJ0cmlsaWEud
>>>>>>>>>> GVjaEBnbWFpbC5jb20ifQ.JCGcaQ-8yYhoOT_DfHvNa5HvG3x5WBI3ZcC4WE
>>>>>>>>>> cBA3NUL-mQdUhU1aEK9G5VulcRbMeYp9f_rFnFip-N9g3JwPGhR6ozgwdXlI
>>>>>>>>>> 09JAjM6zLk7cy0UKig5ghHX1-gXb5EHChzhmGI_xtV77t9dcKBjW4V3f7eFw
>>>>>>>>>> DmCMyWj8bqyoFMDTIp_Gz67Wt1iUXAaCZ5fIdXs3epdG82NhJrjQsIKiYGzU
>>>>>>>>>> g9JY2Dkvg_tHGHESN85KsW2TNj8Jd0CuS-cF0rOqx82pohW6RQMAZmGyMVof
>>>>>>>>>> sxH_uRrEbvpmI_ofkAUF6qCuLDD7idZC_j1ARXH-EOWxHgnSEDXc6SF2aAeg
>>>>>>>>>> mCpw",
>>>>>>>>>>   "expires_in": 300,
>>>>>>>>>>   "refresh_expires_in": 1800,
>>>>>>>>>>   "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiIyYzE4ZjkxYi0yMDljLTQwY2ItY
>>>>>>>>>> TE5OS02NGIwZTEyYjRkOGIiLCJleHAiOjE1MDA5OTE3NDgsIm5iZiI6MCwia
>>>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>>>> XAiOiJSZWZyZXNoIiwiYXpwIjoiYmtvZmMtd2ViIiwiYXV0aF90aW1lIjowL
>>>>>>>>>> CJzZXNzaW9uX3N0YXRlIjoiMzIzMWY0NmYtMjI5Yi00MmQzLWE0MTktMDg5Y
>>>>>>>>>> TIxMzk2ZTY3IiwiY2xpZW50X3Nlc3Npb24iOiI5MjFjYzM2MC03ZTkyLTQ1Z
>>>>>>>>>> DQtYjdmNy0xNWFkYTY2NmE4Y2EiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiO
>>>>>>>>>> lsidW1hX2F1dGhvcml6YXRpb24iLCJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc
>>>>>>>>>> 3MiOnsicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtI
>>>>>>>>>> iwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtaWRlbnRpdHktc
>>>>>>>>>> HJvdmlkZXJzIiwiaW1wZXJzb25hdGlvbiIsInJlYWxtLWFkbWluIiwiY3JlY
>>>>>>>>>> XRlLWNsaWVudCIsIm1hbmFnZS11c2VycyIsInZpZXctYXV0aG9yaXphdGlvb
>>>>>>>>>> iIsIm1hbmFnZS1ldmVudHMiLCJtYW5hZ2UtcmVhbG0iLCJ2aWV3LWV2ZW50c
>>>>>>>>>> yIsInZpZXctdXNlcnMiLCJ2aWV3LWNsaWVudHMiLCJtYW5hZ2UtYXV0aG9ya
>>>>>>>>>> XphdGlvbiIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzI
>>>>>>>>>> jpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2a
>>>>>>>>>> WV3LXByb2ZpbGUiXX19fQ.Uz0rqNlj09T_SdnfZK9ZxBcJ5EIEwwHCN5VwKI
>>>>>>>>>> hIF6Ua32fDlf1UvZSoZTmr5jiHeiwpp4JALWGTXsda4p-PlzMvwmMN5Qp46-
>>>>>>>>>> EXGJQkqH4NNqZ1W_1mRGySYokQCSkmdvAZPFGrqxpeb1seuKgaaiXXMsrvai
>>>>>>>>>> ucFCa8H599Ox6QRE3MkoLmm8w7_08kPG1_JjXIviHtwoWgsb0zCcMPyHRdCv
>>>>>>>>>> _rs6FIoTQiCRZ2joaXSvIsmVAkchgZbeB-_RSWzlk3_oaOCQw7OWZJRqnAdG
>>>>>>>>>> gDnL5jCCRLTVFnPo9TqKrt88h3fKkVuNuI8Y06sZ1If8wgSWRDRLUf0X8sam
>>>>>>>>>> pLww",
>>>>>>>>>>   "token_type": "bearer",
>>>>>>>>>>   "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgO
>>>>>>>>>> iAiSldUIiwia2lkIiA6ICJSSEVTaWNCUG9OQ3doQm5CTEVrXzhYNHVmajVXe
>>>>>>>>>> XVUbzIwemJ6T280SGZRIn0.eyJqdGkiOiI2ZDJkNWMxNS01YmE3LTRhNTgtO
>>>>>>>>>> TJkNC0wNGU0NTkyMjNkNGYiLCJleHAiOjE1MDA5OTAyNDgsIm5iZiI6MCwia
>>>>>>>>>> WF0IjoxNTAwOTg5OTQ4LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6M
>>>>>>>>>> zAwMDEvYXV0aC9yZWFsbXMvYmtvZmMiLCJhdWQiOiJia29mYy13ZWIiLCJzd
>>>>>>>>>> WIiOiIwYTA5MTQ0OC0wNjAyLTQ2YmMtOWU4MS05MjE1ZjgzYjVjOTgiLCJ0e
>>>>>>>>>> XAiOiJJRCIsImF6cCI6ImJrb2ZjLXdlYiIsImF1dGhfdGltZSI6MCwic2Vzc
>>>>>>>>>> 2lvbl9zdGF0ZSI6IjMyMzFmNDZmLTIyOWItNDJkMy1hNDE5LTA4OWEyMTM5N
>>>>>>>>>> mU2NyIsImFjciI6IjEiLCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lI
>>>>>>>>>> joic3VwZXJhZG1pbiIsImVtYWlsIjoidHJpbGlhLnRlY2hAZ21haWwuY29tI
>>>>>>>>>> n0.eFVxG7MImPS4yCEiLOzhvZ5M_XjRWuHJlt_T4r3djak7sH_XOXUmHAuih
>>>>>>>>>> xXrm7HLv8DU3OzHpN3FinOWufOdTCv9Ywww0DRq4ha1M7dodqMuv1H5d3XVB
>>>>>>>>>> n_kuHK68zWRI3t9WI4ZNeaEU0whLSnBqcbJ54dQrBloUPS4bpYG-BqfSNYs6
>>>>>>>>>> bG8cyJHQ4_FRpAi3X9qWOCwaPrZ5Z_vQfNbYcgIfON_puN8QfRxihg90KQYO
>>>>>>>>>> p4lJpU5JqeaVmYp9eOYTb5iQzOuLWDXenyIBmvT_K84HZKh8t5eWsqH01st-
>>>>>>>>>> Ls7uJcNAUM9PXRM7JswCjhouuQGBM6dn5iICoL00acuxg",
>>>>>>>>>>   "not-before-policy": 0,
>>>>>>>>>>   "session_state": "3231f46f-229b-42d3-a419-089a21396e67"
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I checked it in jwt.io . The kid is same as the "rsa-generated"
>>>>>>>>>> one, shown in the screen shot I shared yesterday. Although jwt complained
>>>>>>>>>> as "Invalid Signature" .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thomas, the connectivity should not be an issue as I am able to
>>>>>>>>>> get the access token from  my app wildfly server using curl. So keycloak is
>>>>>>>>>> reachable from my wildfly server. Anything specific you did to resolve your
>>>>>>>>>> issue ?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Rajesh
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 25, 2017 at 11:12 AM, Sebastien Blanc <
>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> This looks all correct. Could you try paste your access token or
>>>>>>>>>>> even check it your self on jwt.io to see if the kid is present ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 24, 2017 at 6:47 PM, Rajesh Ghosh <
>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Sebastien,
>>>>>>>>>>>>
>>>>>>>>>>>> I am attaching a pdf containing the screen shots.  Few more
>>>>>>>>>>>> points I wanted to mention.
>>>>>>>>>>>>
>>>>>>>>>>>> i)  I didn't install the public client  -- "bkofc-web"  in the
>>>>>>>>>>>> wildfly container which hosts my REST services. I did it for  "bkofc-svc"
>>>>>>>>>>>>  client which is bearer only. I hope that is the correct approach.
>>>>>>>>>>>> ii)  Both keycloak and my application are running on docker
>>>>>>>>>>>> containers locally in my laptop.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me know if you need anything else to analyze.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <
>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> yes please
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <
>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes definitely. I did replace it with the actual war name.
>>>>>>>>>>>>>> Let me know if you would like me to paste screen shots of realm
>>>>>>>>>>>>>> configurations, client configurations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <
>>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok and for :
>>>>>>>>>>>>>>> <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Did you replace that with the actual name of your war file ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <
>>>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Sebastien,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am using 3.1.0.Final build.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <
>>>>>>>>>>>>>>>> sblanc at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which version of Keycloak are you using ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <
>>>>>>>>>>>>>>>>> ghosh.rajesh at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am trying to secure my REST services using the method
>>>>>>>>>>>>>>>>>> described in the
>>>>>>>>>>>>>>>>>> document --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://blog.keycloak.org/2015/
>>>>>>>>>>>>>>>>>> 10/getting-started-with-keycloak-securing.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am securing my war using JBoss subsystem , instead of
>>>>>>>>>>>>>>>>>> per-war option. The
>>>>>>>>>>>>>>>>>> relevant sections from my standalone.xml  are posted
>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     <extensions>
>>>>>>>>>>>>>>>>>>          ......
>>>>>>>>>>>>>>>>>>         <extension module="org.keycloak.keycloak-
>>>>>>>>>>>>>>>>>> adapter-subsystem"/>
>>>>>>>>>>>>>>>>>>     </extensions>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>          <security-domains>
>>>>>>>>>>>>>>>>>>                 .....
>>>>>>>>>>>>>>>>>>                 <security-domain name="keycloak">
>>>>>>>>>>>>>>>>>>                     <authentication>
>>>>>>>>>>>>>>>>>>                         <login-module
>>>>>>>>>>>>>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>>>>>>>>>>>>>> flag="required"/>
>>>>>>>>>>>>>>>>>>                     </authentication>
>>>>>>>>>>>>>>>>>>                 </security-domain>
>>>>>>>>>>>>>>>>>>             </security-domains>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>>>>>>>>>>>>>             <secure-deployment name="my war file.war">
>>>>>>>>>>>>>>>>>>                 <realm>bkofc</realm>
>>>>>>>>>>>>>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <use-resource-role-mappings>tr
>>>>>>>>>>>>>>>>>> ue</use-resource-role-mappings>
>>>>>>>>>>>>>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>>>>>>>>>>>>>                 <auth-server-url>http://192.16
>>>>>>>>>>>>>>>>>> 8.99.100/30001/auth
>>>>>>>>>>>>>>>>>> </auth-server-url>
>>>>>>>>>>>>>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>>>>>>>>>>>>>                 <credential
>>>>>>>>>>>>>>>>>> name="secret">9bcc6d9f-9c72-4b
>>>>>>>>>>>>>>>>>> 58-b297-79f0f207d9e1</credential>
>>>>>>>>>>>>>>>>>>             </secure-deployment>
>>>>>>>>>>>>>>>>>>         </subsystem>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am able to obtain the access token.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> curl -i  curl --data
>>>>>>>>>>>>>>>>>> "grant_type=password&client_id
>>>>>>>>>>>>>>>>>> =bkofc-web&username=user&password=password"
>>>>>>>>>>>>>>>>>> http://192.168.99.100:30001/au
>>>>>>>>>>>>>>>>>> th/realms/bkofc/protocol/openid-connect/token
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is
>>>>>>>>>>>>>>>>>> bearer only, for
>>>>>>>>>>>>>>>>>> my REST services  ii) bkofc-web , a public client to
>>>>>>>>>>>>>>>>>> simulate UI login
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> However when I try to use the access token to invoke a
>>>>>>>>>>>>>>>>>> service, I am
>>>>>>>>>>>>>>>>>> getting the error -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Status: 401
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> WWW-Authenticate Bearer realm="bkofc",
>>>>>>>>>>>>>>>>>> error="invalid_token",
>>>>>>>>>>>>>>>>>> error_description="Didn't find publicKey for specified
>>>>>>>>>>>>>>>>>> kid"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please let me know if I am missing something here. I have
>>>>>>>>>>>>>>>>>> been breaking my
>>>>>>>>>>>>>>>>>> head last few days without any luck !  I have also tried
>>>>>>>>>>>>>>>>>> rotating the realm
>>>>>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Rajesh
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From bburke at redhat.com  Tue Jul 25 14:04:41 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 25 Jul 2017 14:04:41 -0400
Subject: [keycloak-user] RH SSO 7.1.1 derived from Keycloak x.y.z?
In-Reply-To: <CAG=THF3jTSzJ0=wGS7zXiWCc1EKftbGx2Oapj4ANhx9D=vVydA@mail.gmail.com>
References: <CAG=THF3jTSzJ0=wGS7zXiWCc1EKftbGx2Oapj4ANhx9D=vVydA@mail.gmail.com>
Message-ID: <211ac764-e206-fed6-6583-429b5ed45e12@redhat.com>

There is no corresponding Keycloak release.  We only do point releases 
in community of the lattest community release.  And only if there is 
some major regression we need to plug.


On 7/25/17 11:33 AM, Adrian Matei wrote:
> Hello guys,
>
> Does anyone know from which Keycloak Version is the RH SSO 7.1.1 patch
> derived from?
>
> Thanks,
> Adrian
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From thomas.darimont at googlemail.com  Tue Jul 25 14:30:44 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 25 Jul 2017 20:30:44 +0200
Subject: [keycloak-user] RH SSO 7.1.1 derived from Keycloak x.y.z?
In-Reply-To: <CAG=THF3jTSzJ0=wGS7zXiWCc1EKftbGx2Oapj4ANhx9D=vVydA@mail.gmail.com>
References: <CAG=THF3jTSzJ0=wGS7zXiWCc1EKftbGx2Oapj4ANhx9D=vVydA@mail.gmail.com>
Message-ID: <CAK-7U1jopSFxBgpdVgAYXP29gW-6AXhYZ_7HcHjHPubJ5xJH5A@mail.gmail.com>

Hello Adrian,

asked the same question a while ago:
http://www.keycloak.org/support.html

RH-SSO 7.1 Derived from Keycloak 2.5.5
RH-SSO 7.0 Derived from Keycloak 1.9.8

Cheers,
Thomas

2017-07-25 17:33 GMT+02:00 Adrian Matei <adrianmatei at gmail.com>:

> Hello guys,
>
> Does anyone know from which Keycloak Version is the RH SSO 7.1.1 patch
> derived from?
>
> Thanks,
> Adrian
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From thomas.darimont at googlemail.com  Tue Jul 25 14:44:44 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 25 Jul 2017 20:44:44 +0200
Subject: [keycloak-user] RH SSO 7.1.1 derived from Keycloak x.y.z?
In-Reply-To: <CAK-7U1jopSFxBgpdVgAYXP29gW-6AXhYZ_7HcHjHPubJ5xJH5A@mail.gmail.com>
References: <CAG=THF3jTSzJ0=wGS7zXiWCc1EKftbGx2Oapj4ANhx9D=vVydA@mail.gmail.com>
	<CAK-7U1jopSFxBgpdVgAYXP29gW-6AXhYZ_7HcHjHPubJ5xJH5A@mail.gmail.com>
Message-ID: <CAK-7U1gc+9gFAV1svDncx3M89o6i=xzug40NiiK=WgMCGxb9fA@mail.gmail.com>

... just noticed that RH-SSO 7.1.1 is not listed there yet :-/

If you have a RH subscription you might be able to see:
https://access.redhat.com/articles/3055391

On github one can see some explicit tags with -rhsso like 3.2.0.Final-rhsso
https://github.com/keycloak/keycloak/tree/3.2.0.Final-rhsso
... but that's of course just an indicator and no definitive answer.

Cheers,
Thomas

2017-07-25 20:30 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello Adrian,
>
> asked the same question a while ago:
> http://www.keycloak.org/support.html
>
> RH-SSO 7.1 Derived from Keycloak 2.5.5
> RH-SSO 7.0 Derived from Keycloak 1.9.8
>
> Cheers,
> Thomas
>
> 2017-07-25 17:33 GMT+02:00 Adrian Matei <adrianmatei at gmail.com>:
>
>> Hello guys,
>>
>> Does anyone know from which Keycloak Version is the RH SSO 7.1.1 patch
>> derived from?
>>
>> Thanks,
>> Adrian
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>

From mevans at aconex.com  Tue Jul 25 19:19:45 2017
From: mevans at aconex.com (Matt Evans)
Date: Tue, 25 Jul 2017 23:19:45 +0000
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
Message-ID: <ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>

After looking at the code it seems that this is controlled for each authentication attempt with the SSO_AUTH note, the CookieAuthenticator sets it as a client note if cookie authentication succeeds, and the AuthenticationManager checks it and if it's not true updates the auth_time. I can't see anywhere that clears it. I'm not sure how long client notes live, but I assume longer than the current authentication attempt, because once it's set, I can see that it stays true for all my "prompt=login" authentication attempts after that.

I changed the CookieAuthenticator to clear the flag first and this seems to fix the problem for me, however, I'm not sure if that's the best approach?

Matt

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Saturday, 22 July 2017 12:45 AM
To: Matt Evans <mevans at aconex.com>; keycloak-user <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] When should auth_time claim be updated?

On 21/07/17 07:57, Matt Evans wrote:
> Hi
>
> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>
> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>
> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>
> Is this intended behaviour?
Yes. The claim "auth_time" points to the time of the active authentication. And the re-authentication with SSO cookie is not treated as "active" authentication, so this won't update auth_time. With "prompt=login" you need actively authenticate, so that will update auth_time.

Marek
>
> Thanks
>
> Matt
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




From scott at xigole.com  Tue Jul 25 22:11:53 2017
From: scott at xigole.com (Scott Dunbar)
Date: Tue, 25 Jul 2017 20:11:53 -0600
Subject: [keycloak-user] Facebook "picture" / additional scopes access
Message-ID: <CACaM2NwGfiK+RjM06pbUn_mHRTbwro7i87B=dzZU9OmET9g5bg@mail.gmail.com>

Hi all,
I've not dealt with a Facebook integration in a while and am ultimately
trying to get the "picture" attribute of a Facebook user.  However, while I
see the code in
https://github.com/keycloak/keycloak/blob/2aa93d7d55869e3d262bef198e1059f42b7fa0f6/services/src/main/java/org/keycloak/social/facebook/FacebookIdentityProvider.java
that asks for some fields it is unclear how I add "picture" via the admin
console in "Identity Providers -> Facebook -> Default Scopes".  If I put
the word "picture" in "Default Scopes" I get an error from Facebook:

"Unsupported scope: 'picture'. Supported scopes: ads_management ads_read
email offline_access user_friends"

I've tried "public_profile" and, while it doesn't give an error, it does
not return what I'm looking for:

2017-07-25 20:06:27,595 DEBUG [org.keycloak.social.user_profile_dump]
(default task-84) User Profile JSON Data for provider facebook:
{"id":"1234567890","name":"Scott
Dunbar","first_name":"Scott","last_name":"Dunbar"}

I'm obviously missing something - how do I add some "scopes" to what is
requested from Facebook?

Thanks for any help.  I'll be doing the same for at least the Google
adapter next - any hints there?


-- 
Scott Dunbar

From scott at xigole.com  Tue Jul 25 22:16:54 2017
From: scott at xigole.com (Scott Dunbar)
Date: Tue, 25 Jul 2017 20:16:54 -0600
Subject: [keycloak-user] Facebook "picture" / additional scopes access
In-Reply-To: <CACaM2NwGfiK+RjM06pbUn_mHRTbwro7i87B=dzZU9OmET9g5bg@mail.gmail.com>
References: <CACaM2NwGfiK+RjM06pbUn_mHRTbwro7i87B=dzZU9OmET9g5bg@mail.gmail.com>
Message-ID: <CACaM2Nw9-gQsFpG1jVPfCws-sytidYxrQjBqeA8NuU5sc5JgaQ@mail.gmail.com>

Sorry - mailing list question etiquette 101 violated - this is with
"Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)" under Ubuntu with
1.8.0_131 JVM.

On Tue, Jul 25, 2017 at 8:11 PM, Scott Dunbar <scott at xigole.com> wrote:

> Hi all,
> I've not dealt with a Facebook integration in a while and am ultimately
> trying to get the "picture" attribute of a Facebook user.  However, while I
> see the code in
> https://github.com/keycloak/keycloak/blob/2aa93d7d55869e3d262bef198e1059
> f42b7fa0f6/services/src/main/java/org/keycloak/social/facebook/
> FacebookIdentityProvider.java that asks for some fields it is unclear how
> I add "picture" via the admin console in "Identity Providers -> Facebook ->
> Default Scopes".  If I put the word "picture" in "Default Scopes" I get an
> error from Facebook:
>
> "Unsupported scope: 'picture'. Supported scopes: ads_management ads_read
> email offline_access user_friends"
>
> I've tried "public_profile" and, while it doesn't give an error, it does
> not return what I'm looking for:
>
> 2017-07-25 20:06:27,595 DEBUG [org.keycloak.social.user_profile_dump]
> (default task-84) User Profile JSON Data for provider facebook:
> {"id":"1234567890","name":"Scott Dunbar","first_name":"Scott","
> last_name":"Dunbar"}
>
> I'm obviously missing something - how do I add some "scopes" to what is
> requested from Facebook?
>
> Thanks for any help.  I'll be doing the same for at least the Google
> adapter next - any hints there?
>
>
> --
> Scott Dunbar
>
>


-- 
Scott Dunbar
Cell: 303 667 6343

From Kevin.Cuijpers at mips.be  Wed Jul 26 07:51:08 2017
From: Kevin.Cuijpers at mips.be (Kevin Cuijpers)
Date: Wed, 26 Jul 2017 11:51:08 +0000
Subject: [keycloak-user]
 org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No
 login page was defined for FORM authentication in context
Message-ID: <6bfdb0694f6d44fd98d9f5cd0a953cde@srv-webmail.mips.be>

I have tried to use the same setup with Tomcat 7.0.65 with the SAML 2.0 Client Adapter for Tomcat 7 and there the example works. I am able to log in and see my account settings as expected so it is indeed related to Tomcat 8.

When I look at the source of the SAML 2.0 Client Adapter for Tomcat 8 I see:
public class KeycloakAuthenticatorValve extends AbstractKeycloakAuthenticatorValve {

    /**
     * Method called by Tomcat < 8.5.5
     */
    public boolean authenticate(Request request, HttpServletResponse response) throws IOException {
       return authenticateInternal(request, response, request.getContext().getLoginConfig());
    }

    /**
     * Method called by Tomcat >= 8.5.5
     */
    protected boolean doAuthenticate(Request request, HttpServletResponse response) throws IOException {
       return this.authenticate(request, response);
    }

So the fix mentioned in https://issues.jboss.org/browse/KEYCLOAK-3669?attachmentViewMode=list
Is in it, but is not solving the problem.
Can anyone please help?

Kevin

From: Kevin Cuijpers
Sent: Monday, July 24, 2017 4:19 PM
To: 'keycloak-user at lists.jboss.org' <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No login page was defined for FORM authentication in context

Hello,

I am trying to use the SAML 2.0 Client Adapter for Tomcat 8.5.8. I downloaded keycloak-saml-tomcat8-adapter-dist-3.2.1.Final and installed it in the lib folder of Tomcat.

I followed the instructions from app-profile-saml-jee-jsp quickstart to set up the Client.

I added following context.xml:
<Context path="app">
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
    <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>

    <!-- Required for KeyCloak -->
    <Valve className="org.keycloak.adapters.saml.tomcat.SamlAuthenticatorValve"/>
</Context>

I copied the files from app-profile-saml-jee-jsp quickstart into a separate project (see attached demo.zip) to make the war.

Tomcat starts up correctly and I see the Please login page when I go to http://localhost:8080/app/

When I click on LOGIN I get a 500 error page and following error:
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No login page was defined for FORM authentication in context [/app]

I found an old mailing with similar problem:
http://lists.jboss.org/pipermail/keycloak-user/2016-November/008380.html

pointing to an issue that should have been solved:
https://issues.jboss.org/browse/KEYCLOAK-3669?attachmentViewMode=list

It is unclear what I need to do to make this simple example work or what needs to be changed to the adapter.

Please help.

Kevin Cuijpers


From hmlnarik at redhat.com  Wed Jul 26 08:46:59 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 26 Jul 2017 14:46:59 +0200
Subject: [keycloak-user]
 org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No
 login page was defined for FORM authentication in context
In-Reply-To: <6bfdb0694f6d44fd98d9f5cd0a953cde@srv-webmail.mips.be>
References: <6bfdb0694f6d44fd98d9f5cd0a953cde@srv-webmail.mips.be>
Message-ID: <CAMvXD=Hq-PTAX-HJSn=hbzFfEKCpqFNKNnbZSi7RaRUEM8He8g@mail.gmail.com>

Could you please file a JIRA with the your findings?

Thanks

--Hynek

On Wed, Jul 26, 2017 at 1:51 PM, Kevin Cuijpers <Kevin.Cuijpers at mips.be> wrote:
> I have tried to use the same setup with Tomcat 7.0.65 with the SAML 2.0 Client Adapter for Tomcat 7 and there the example works. I am able to log in and see my account settings as expected so it is indeed related to Tomcat 8.
>
> When I look at the source of the SAML 2.0 Client Adapter for Tomcat 8 I see:
> public class KeycloakAuthenticatorValve extends AbstractKeycloakAuthenticatorValve {
>
>     /**
>      * Method called by Tomcat < 8.5.5
>      */
>     public boolean authenticate(Request request, HttpServletResponse response) throws IOException {
>        return authenticateInternal(request, response, request.getContext().getLoginConfig());
>     }
>
>     /**
>      * Method called by Tomcat >= 8.5.5
>      */
>     protected boolean doAuthenticate(Request request, HttpServletResponse response) throws IOException {
>        return this.authenticate(request, response);
>     }
>
> So the fix mentioned in https://issues.jboss.org/browse/KEYCLOAK-3669?attachmentViewMode=list
> Is in it, but is not solving the problem.
> Can anyone please help?
>
> Kevin
>
> From: Kevin Cuijpers
> Sent: Monday, July 24, 2017 4:19 PM
> To: 'keycloak-user at lists.jboss.org' <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
> Subject: org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No login page was defined for FORM authentication in context
>
> Hello,
>
> I am trying to use the SAML 2.0 Client Adapter for Tomcat 8.5.8. I downloaded keycloak-saml-tomcat8-adapter-dist-3.2.1.Final and installed it in the lib folder of Tomcat.
>
> I followed the instructions from app-profile-saml-jee-jsp quickstart to set up the Client.
>
> I added following context.xml:
> <Context path="app">
>     <WatchedResource>WEB-INF/web.xml</WatchedResource>
>     <WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
>
>     <!-- Required for KeyCloak -->
>     <Valve className="org.keycloak.adapters.saml.tomcat.SamlAuthenticatorValve"/>
> </Context>
>
> I copied the files from app-profile-saml-jee-jsp quickstart into a separate project (see attached demo.zip) to make the war.
>
> Tomcat starts up correctly and I see the Please login page when I go to http://localhost:8080/app/
>
> When I click on LOGIN I get a 500 error page and following error:
> org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage No login page was defined for FORM authentication in context [/app]
>
> I found an old mailing with similar problem:
> http://lists.jboss.org/pipermail/keycloak-user/2016-November/008380.html
>
> pointing to an issue that should have been solved:
> https://issues.jboss.org/browse/KEYCLOAK-3669?attachmentViewMode=list
>
> It is unclear what I need to do to make this simple example work or what needs to be changed to the adapter.
>
> Please help.
>
> Kevin Cuijpers
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From Marcus.May at bedag.ch  Wed Jul 26 10:07:52 2017
From: Marcus.May at bedag.ch (May Marcus, Bedag)
Date: Wed, 26 Jul 2017 14:07:52 +0000
Subject: [keycloak-user] Is there a way to use an OIDC IdP without any
 backchannel communication involved (like SAML 2.0 Web Browser SSO with
 HTTP-Post Binding)
Message-ID: <3835837561142448A72F035FFA6D0BAD018E2D1152@bisrv1040.ad.bedag.ch>

Hi,

I'm looking into using Keycloak as a Broker in my SAAS platform to federate with foreign IdPs which aren't in my control.

So my scenario is that:
1.      Customer navigates to his SP in my SAAS platform
2.      SP redirects him to my Keycloak in my SAAS platform
3.      Customer choses to login in with his IdP
4.      Keycloak redirects Customer to the login page of his IdP
5.      Customer accomplishes login to his IdP
6.      IdP redirects the Customer to my Keycloak
7.      My Keycloak provisions the user
8.      My Keycloak redirects the user to his SP in my SAAS platform
9.      SP accepts the login

For a proof of concept I tried to implement this scenario with two Keycloak instances, which aren't and shouldn't be able to communicate with each other. The only thing that should communicate with both Keycloak instances is the user agent, because I don't want the hassle that I have to establish a for example two-way-ssl connection between my SAAS Keycloak and foreign IdP.

My first attempt was using OpenID Connect, but then my SAAS Keycloak tried to get an access_token from the other Keycloak in step 7. That didn't work (as I expected and intended). So my question is: Is there a way to use an OIDC IdP without any backchannel communication involved?

My second attempt was using SAML 2.0 Web Browser SSO with HTTP-Post Binding. That did work fine.

Best regards
Marcus




From Nicolas.Geadah at vec.virginia.gov  Wed Jul 26 13:09:39 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Wed, 26 Jul 2017 17:09:39 +0000
Subject: [keycloak-user] NoSuchMethodError:
	org.keycloak.models.KeycloakSession.userCache()
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230B578E@COVMSGCES-MBX13>

Running the "authenticator" example provider in RedHat SSO 7.1.  The provider (Secret Question) comes up in the admin console, and I'm able to make it a required action as part of the registration flow.

When going through the registration process in the browser, the security question page is rendered (security-question-config.ftl) but submitting the security answer leads to exception below:


org.jboss.resteasy.spi.UnhandledException: java.lang.NoSuchMethodError: org.keycloak.models.KeycloakSession.userCache()Lorg/keycloak/models/cache/UserCache;


Any thoughts on how to resolve?

From Nicolas.Geadah at vec.virginia.gov  Wed Jul 26 13:52:48 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Wed, 26 Jul 2017 17:52:48 +0000
Subject: [keycloak-user] RHSSO 7.1 missing "login with email" toggle for
	realm configuration
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230B57AC@COVMSGCES-MBX13>

KeyCloak 2.5.0 added the ability to control whether users should able to login with their email address, and the ability to support duplicate email addresses.


We need these features and I was expecting to see them in RHSSO 7.1 (considering it is derived from Keycloak 2.5.5)

Unfortunately, I noticed that these features are not in the administrative console when configuring my realm.  It seems to boil down to missing

From Nicolas.Geadah at vec.virginia.gov  Wed Jul 26 13:54:34 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Wed, 26 Jul 2017 17:54:34 +0000
Subject: [keycloak-user] RHSSO 7.1 missing "login with email" toggle for
 realm configuration
In-Reply-To: <AA9A1979BCCB3F4998617B9D33FA3900230B57AC@COVMSGCES-MBX13>
References: <AA9A1979BCCB3F4998617B9D33FA3900230B57AC@COVMSGCES-MBX13>
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230B57B9@COVMSGCES-MBX13>

KeyCloak 2.5.0 added the ability to control whether users should able to login with their email address, and the ability to support duplicate email addresses.

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

We need these features and I was expecting to see them in RHSSO 7.1 (considering it is derived from Keycloak 2.5.5)

Unfortunately, I noticed that these features are not in the administrative console when configuring my realm.  It seems to boil down to an outdated template for the admin view (realm-login-settings.html in themes\base\admin\resources\partials)

Any reason why these features were not brought over into RHSSO 7.1?  Did they make it into 7.1.1?

From Nicolas.Geadah at vec.virginia.gov  Wed Jul 26 21:34:08 2017
From: Nicolas.Geadah at vec.virginia.gov (Geadah, Nicolas (VEC))
Date: Thu, 27 Jul 2017 01:34:08 +0000
Subject: [keycloak-user] Adding recaptcha to lost-password (credential
	reset) flow
Message-ID: <AA9A1979BCCB3F4998617B9D33FA3900230B57F2@COVMSGCES-MBX13>

What would be the best way to add recaptcha to the lost-password (credential-reset) flow?  It seems like a pretty basic requirement, since this flow would most likely be abused via scripting if it were left without a captcha.

The registration captcha FormAction (RegistrationRecaptcha class) seems like a good starting point, but I can't figure out how to get my own custom FormAction into the reset credentials flow.

Thanks!

From hmlnarik at redhat.com  Thu Jul 27 01:50:41 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 27 Jul 2017 07:50:41 +0200
Subject: [keycloak-user] Server 2016 ADFS won't accept descriptor
In-Reply-To: <CAMvXD=H5VkZxR_grk0DO8aMiVS5uoG8xUgL5fmezDZeifXJxSQ@mail.gmail.com>
References: <F32C3FA1-E14B-42A5-9FF3-36AB25D32A2F@geocent.com>
	<CAMvXD=EBjacCaKYd2WsYtj1Q+T1HBqNbQnojAHaU_WfUMQqLUQ@mail.gmail.com>
	<CY1PR06MB21547F7FE0C76CBDE3393C7D8BA40@CY1PR06MB2154.namprd06.prod.outlook.com>
	<CAMvXD=HYyd_9aVfnM6ResELgY_RNYMNUFCK2JMfOy0mn6z9d-g@mail.gmail.com>
	<7E8A6F18-8C9A-401F-A429-46A8A97DDE12@geocent.com>
	<CAMvXD=HYCBZzm2TV5XdrMRt6q421H+Cb1UMugwPPwhN-8dTq1Q@mail.gmail.com>
	<CY1PR06MB2154A535494D3EF967E62DF08BA40@CY1PR06MB2154.namprd06.prod.outlook.com>
	<CAMvXD=H5VkZxR_grk0DO8aMiVS5uoG8xUgL5fmezDZeifXJxSQ@mail.gmail.com>
Message-ID: <CAMvXD=GmFCp4f518cPi01SrV-T0==9SS=JnBdW63cZujs_sZNQ@mail.gmail.com>

Just for info - I have just tried to setup AD FS 2012 according to the blog
post and there was no import error or anything reported, everything just
worked as it should. Did you manage to find out what was causing you the
issues?

--Hynek

On Fri, Jul 21, 2017 at 8:51 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> In that case I don't think it is Keycloak issue but rather a AD FS or
> setup issue. Reportedly, there are people using AD FS 2016 brokering (see
> [1]) so there must be something else in the way. I'm curious what that can
> be. Firewall? Not using https? Using IP addresses instead of domain names?
> Just guessing, I don't know, and will be glad if you find out and share.
>
> --Hynek
>
> [1] http://lists.jboss.org/pipermail/keycloak-user/2017-March/010138.html
>
> On Fri, Jul 21, 2017 at 4:25 PM, John Craft <John.Craft at geocent.com>
> wrote:
>
>> Yep, it reports as valid.
>>
>>
>> This isn't supposed to be difficult.
>>
>>
>> I entered the params manually, it seemed to take them.  I'll know more
>> when I finish and try the brokered connection.
>>
>>
>> Thanks.
>>
>>
>> JC.
>>
>>
>>
>>
>> ------------------------------
>> *From:* Hynek Mlnarik <hmlnarik at redhat.com>
>> *Sent:* Friday, July 21, 2017 8:00 AM
>> *To:* John Craft
>> *Subject:* Re: [keycloak-user] Server 2016 ADFS won't accept descriptor
>>
>> Have you tried the descriptor validation?
>>
>> On Fri, Jul 21, 2017 at 2:29 PM, John Craft <John.Craft at geocent.com>
>> wrote:
>>
>>> Sorry, I never get past the part in ADFS to set up the trust
>>> relationship.   There is no event log as it never accepts the keycloak
>>> descriptor.
>>>
>>>
>>>
>>> John Craft
>>> Senior Software Engineer, GISP
>>> Geocent, LLC
>>> Cell : 601-299-1830 <(601)%20299-1830>
>>> Stennis Space Center MS
>>> www.geocent.com | John.Craft at Geocent.com
>>>
>>> On Jul 21, 2017, at 7:05 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>>
>>> Thanks. I am afraid more details would be needed, those from Windows
>>> Event Viewer. Furthermore, the descriptor should pass "metadata" type of
>>> validation [1], you can try that. If the descriptor passes, there is not
>>> much to be done on Keycloak side.
>>>
>>> [1] https://www.samltool.com/validate_xml.php
>>>
>>> On Fri, Jul 21, 2017 at 1:43 PM, John Craft <John.Craft at geocent.com>
>>> wrote:
>>>
>>>>
>>>> What is the Keycloak version?
>>>>
>>>> 3.1.0.Final
>>>>
>>>> What is URL for "help docs" - AFAIK
>>>> there is only a blog post and no docs within Keycloak documentation.
>>>>
>>>> http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as
>>>> -brokered.html
>>>>
>>>> <http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as-brokered.html>
>>>> Keycloak: How to Setup MS AD FS 3.0 as Brokered Identity ...
>>>> <http://blog.keycloak.org/2017/03/how-to-setup-ms-ad-fs-30-as-brokered.html>
>>>> blog.keycloak.org
>>>> This document guides you through initial setup of Microsoft Active
>>>> Directory Federation Services 3.0 as a brokered identity provider Keycloak.
>>>> Keycloak server has ...
>>>>
>>>>
>>>> What error is reported by ADFS?
>>>>
>>>> Details of the error can usually be
>>>> found in Windows Event Viewer.
>>>> <pastedImage.png>
>>>>
>>>>
>>>>
>>>> --Hynek
>>>>
>>>> On Fri, Jul 21, 2017 at 3:28 AM, John Craft <John.Craft at geocent.com>
>>>> wrote:
>>>> > I've installed Windows Server 2016 with ADFS.  When I try to create
>>>> the trust as per the Keycloak help docs, ADFS reports the descriptor as
>>>> malformed.  Anybody had experience with this?
>>>> >
>>>> > John Craft
>>>> > Senior Software Engineer, GISP
>>>> > Geocent, LLC
>>>> > Cell : 601-299-1830 <(601)%20299-1830>
>>>> > Stennis Space Center MS
>>>> > www.geocent.com | John.Craft at Geocent.com
>>>> Geocent <http://www.geocent.com/>
>>>> www.geocent.com
>>>> Software Engineering. Custom Software; Service Oriented Architecture
>>>> (SOA) Business Intelligence and Analytics; Geospatial Information Systems;
>>>> Mobile Application ...
>>>>
>>>>
>>>> >
>>>> > Confidentiality Notice:
>>>> > This email communication may contain confidential information, may be
>>>> legally privileged, and is intended only for the use of the intended
>>>> recipients(s) identified. Any unauthorized review, use, distribution,
>>>> downloading, or copying of this communication is strictly prohibited. If
>>>> you are not the intended recipient and have received this message in error,
>>>> immediately notify the sender by reply email, delete the communication, and
>>>> destroy all copies. Thank you.
>>>> >
>>>> > _______________________________________________
>>>> > keycloak-user mailing list
>>>> > keycloak-user at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> keycloak-user Info Page - JBoss Developer
>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>> lists.jboss.org
>>>> To see the collection of prior postings to the list, visit the
>>>> keycloak-user Archives. Using keycloak-user: To post a message to all the
>>>> list members ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --Hynek
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> --Hynek
>>>
>>>
>>
>>
>> --
>>
>> --Hynek
>>
>
>
>
> --
>
> --Hynek
>



-- 

--Hynek

From alexander.chriztopher at gmail.com  Thu Jul 27 06:36:39 2017
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Thu, 27 Jul 2017 12:36:39 +0200
Subject: [keycloak-user] /introspect always returns {"active":false}
Message-ID: <CAJfT+OqpTb12dybWg-6UbfOH3q3EFk75i-LwYvEVtiFtrEE2ZQ@mail.gmail.com>

Hi all,

Any idea about this point ? We always get : {"active":false} when we call
the api to make an intropection wether the access_token is valid or not.

Are there any params to tweek in the console to activate this service ?

These are the logs we get in Keycloak where every thing seems to work
nicely although i don't have all the details of whats going on :

2017-07-26 16:57:55,679 DEBUG [io.undertow.request.security] (default
task-14) Attempting to authenticate HttpServerExchange{ POST
/auth/realms/REALM/protocol/openid-connect/token/introspect request
{Accept=[*/*],  Content-Type=[application/x-www-form-urlencoded ],
User-Agent=[curl/7.51.0], Authorization=[Basic
ZW1wLW51bS1sb2dpbi1jbGllbnQ6NzVjOWQ4ODMtNGY2YS00ZWMxLWEzZGQtNDU0YjE1ZjNlZDIx],
X-Forwarded-Proto=[https], X-Forwarded-Port=[443], Content-Length=[968],
Content-Type=[application/x-www-form-urlencoded], Host=[host.com]} response
{X-Powered-By=[Undertow/1], Server=[JBoss-EAP/7]}}, authentication
required: false
2017-07-26 16:57:55,679 DEBUG [io.undertow.request.security] (default
task-14) Authentication outcome was NOT_ATTEMPTED with method
io.undertow.security.impl.CachedAuthenticatedSessionMechanism at 2724f346 for
HttpServerExchange{ POST
/auth/realms/REALM/protocol/openid-connect/token/introspect request
{Accept=[*/*],  Content-Type=[application/x-www-form-urlencoded ],
User-Agent=[curl/7.51.0], Authorization=[Basic
ZW1wLW51bS1sb2dpbi1jbGllbnQ6NzVjOWQ4ODMtNGY2YS00ZWMxLWEzZGQtNDU0YjE1ZjNlZDIx],
X-Forwarded-Proto=[https], X-Forwarded-Port=[443], Content-Length=[968],
Content-Type=[application/x-www-form-urlencoded], Host=[host.com]} response
{X-Powered-By=[Undertow/1], Server=[JBoss-EAP/7]}}
2017-07-26 16:57:55,679 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-14) new
JtaTransactionWrapper
2017-07-26 16:57:55,679 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-14) was
existing? false
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) RESTEASY002315: PathInfo:
/realms/REALM/protocol/openid-connect/token/introspect
2017-07-26 16:57:55,680 DEBUG
[org.keycloak.authentication.AuthenticationProcessor] (default task-14)
AUTHENTICATE CLIENT
2017-07-26 16:57:55,680 DEBUG
[org.keycloak.authentication.ClientAuthenticationFlow] (default task-14)
client authenticator: client-secret
2017-07-26 16:57:55,680 DEBUG
[org.keycloak.authentication.ClientAuthenticationFlow] (default task-14)
client authenticator SUCCESS: client-secret
2017-07-26 16:57:55,680 DEBUG
[org.keycloak.authentication.ClientAuthenticationFlow] (default task-14)
Client emp-num-login-client authenticated by client-secret
2017-07-26 16:57:55,680 DEBUG [org.keycloak.events] (default task-14)
type=INTROSPECT_TOKEN, realmId=REALM, clientId=emp-num-login-client,
userId=null, ipAddress=xx.xx.xx.xx, client_auth_method=client-secret
2017-07-26 16:57:55,680 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-14)
JtaTransactionWrapper  commit
2017-07-26 16:57:55,680 DEBUG
[org.keycloak.transaction.JtaTransactionWrapper] (default task-14)
JtaTransactionWrapper end
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) MessageBodyWriter:
org.jboss.resteasy.spi.ResteasyProviderFactory$SortedKey
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) MessageBodyWriter:
org.jboss.resteasy.plugins.providers.ByteArrayProvider
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) Interceptor Context:
org.jboss.resteasy.core.interception.ServerWriterInterceptorContext,
 Method : proceed
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) InterceptorWriter:
org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) Interceptor :
org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor,
Method : aroundWriteTo
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) Interceptor Context:
org.jboss.resteasy.core.interception.ServerWriterInterceptorContext,
 Method : proceed
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) InterceptorWriter:
org.jboss.resteasy.security.doseta.DigitalSigningInterceptor
2017-07-26 16:57:55,680 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) Interceptor Context:
org.jboss.resteasy.core.interception.ServerWriterInterceptorContext,
 Method : proceed
2017-07-26 16:57:55,681 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) MessageBodyWriter:
org.jboss.resteasy.spi.ResteasyProviderFactory$SortedKey
2017-07-26 16:57:55,681 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) MessageBodyWriter:
org.jboss.resteasy.plugins.providers.ByteArrayProvider
2017-07-26 16:57:55,681 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n]
(default task-14) Interceptor Context :
org.jboss.resteasy.core.interception.ServerWriterInterceptorContext, Method
: writeTo

Thanks for any help about this point.

From mposolda at redhat.com  Thu Jul 27 06:48:08 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 27 Jul 2017 12:48:08 +0200
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
	<ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>
Message-ID: <70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>

Looks like a bug. Could you please create JIRA for this?

Thanks,
Marek

On 26/07/17 01:19, Matt Evans wrote:
> After looking at the code it seems that this is controlled for each authentication attempt with the SSO_AUTH note, the CookieAuthenticator sets it as a client note if cookie authentication succeeds, and the AuthenticationManager checks it and if it's not true updates the auth_time. I can't see anywhere that clears it. I'm not sure how long client notes live, but I assume longer than the current authentication attempt, because once it's set, I can see that it stays true for all my "prompt=login" authentication attempts after that.
>
> I changed the CookieAuthenticator to clear the flag first and this seems to fix the problem for me, however, I'm not sure if that's the best approach?
>
> Matt
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Saturday, 22 July 2017 12:45 AM
> To: Matt Evans <mevans at aconex.com>; keycloak-user <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] When should auth_time claim be updated?
>
> On 21/07/17 07:57, Matt Evans wrote:
>> Hi
>>
>> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>>
>> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>>
>> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>>
>> Is this intended behaviour?
> Yes. The claim "auth_time" points to the time of the active authentication. And the re-authentication with SSO cookie is not treated as "active" authentication, so this won't update auth_time. With "prompt=login" you need actively authenticate, so that will update auth_time.
>
> Marek
>> Thanks
>>
>> Matt
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From mposolda at redhat.com  Thu Jul 27 06:51:25 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 27 Jul 2017 12:51:25 +0200
Subject: [keycloak-user] Facebook "picture" / additional scopes access
In-Reply-To: <CACaM2Nw9-gQsFpG1jVPfCws-sytidYxrQjBqeA8NuU5sc5JgaQ@mail.gmail.com>
References: <CACaM2NwGfiK+RjM06pbUn_mHRTbwro7i87B=dzZU9OmET9g5bg@mail.gmail.com>
	<CACaM2Nw9-gQsFpG1jVPfCws-sytidYxrQjBqeA8NuU5sc5JgaQ@mail.gmail.com>
Message-ID: <cb4d99aa-564c-824b-c65a-c6101f017dfe@redhat.com>

Rather looks like Facebook issue than Keycloak issue? I guess if you 
look at Facebook documentation around their supported scopes, it may help?

Marek

On 26/07/17 04:16, Scott Dunbar wrote:
> Sorry - mailing list question etiquette 101 violated - this is with
> "Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)" under Ubuntu with
> 1.8.0_131 JVM.
>
> On Tue, Jul 25, 2017 at 8:11 PM, Scott Dunbar <scott at xigole.com> wrote:
>
>> Hi all,
>> I've not dealt with a Facebook integration in a while and am ultimately
>> trying to get the "picture" attribute of a Facebook user.  However, while I
>> see the code in
>> https://github.com/keycloak/keycloak/blob/2aa93d7d55869e3d262bef198e1059
>> f42b7fa0f6/services/src/main/java/org/keycloak/social/facebook/
>> FacebookIdentityProvider.java that asks for some fields it is unclear how
>> I add "picture" via the admin console in "Identity Providers -> Facebook ->
>> Default Scopes".  If I put the word "picture" in "Default Scopes" I get an
>> error from Facebook:
>>
>> "Unsupported scope: 'picture'. Supported scopes: ads_management ads_read
>> email offline_access user_friends"
>>
>> I've tried "public_profile" and, while it doesn't give an error, it does
>> not return what I'm looking for:
>>
>> 2017-07-25 20:06:27,595 DEBUG [org.keycloak.social.user_profile_dump]
>> (default task-84) User Profile JSON Data for provider facebook:
>> {"id":"1234567890","name":"Scott Dunbar","first_name":"Scott","
>> last_name":"Dunbar"}
>>
>> I'm obviously missing something - how do I add some "scopes" to what is
>> requested from Facebook?
>>
>> Thanks for any help.  I'll be doing the same for at least the Google
>> adapter next - any hints there?
>>
>>
>> --
>> Scott Dunbar
>>
>>
>


From mposolda at redhat.com  Thu Jul 27 07:00:19 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 27 Jul 2017 13:00:19 +0200
Subject: [keycloak-user] Is there a way to use an OIDC IdP without any
 backchannel communication involved (like SAML 2.0 Web Browser SSO with
 HTTP-Post Binding)
In-Reply-To: <3835837561142448A72F035FFA6D0BAD018E2D1152@bisrv1040.ad.bedag.ch>
References: <3835837561142448A72F035FFA6D0BAD018E2D1152@bisrv1040.ad.bedag.ch>
Message-ID: <ef5247a9-c010-e8f5-48da-59fddf6fb48a@redhat.com>

OIDC protocol has implicit flow and we support that in Keycloak. However 
we don't support that for our Identity providers. I see that 
AbstractOAuth2IdentityProvider.createAuthorizationUrl has hardcoded 
"response_type" to "code" . So you would need to create your own impl of 
Identity Provider and override that method. Probably some other methods 
would need to be overriden too (eg. for logout).

I would rather try to setup SSL and make Keycloak servers communicate 
with each other . We have truststore SPI, which is documented and 
hopefully can simplify it.


Marek

On 26/07/17 16:07, May Marcus, Bedag wrote:
> Hi,
>
> I'm looking into using Keycloak as a Broker in my SAAS platform to federate with foreign IdPs which aren't in my control.
>
> So my scenario is that:
> 1.      Customer navigates to his SP in my SAAS platform
> 2.      SP redirects him to my Keycloak in my SAAS platform
> 3.      Customer choses to login in with his IdP
> 4.      Keycloak redirects Customer to the login page of his IdP
> 5.      Customer accomplishes login to his IdP
> 6.      IdP redirects the Customer to my Keycloak
> 7.      My Keycloak provisions the user
> 8.      My Keycloak redirects the user to his SP in my SAAS platform
> 9.      SP accepts the login
>
> For a proof of concept I tried to implement this scenario with two Keycloak instances, which aren't and shouldn't be able to communicate with each other. The only thing that should communicate with both Keycloak instances is the user agent, because I don't want the hassle that I have to establish a for example two-way-ssl connection between my SAAS Keycloak and foreign IdP.
>
> My first attempt was using OpenID Connect, but then my SAAS Keycloak tried to get an access_token from the other Keycloak in step 7. That didn't work (as I expected and intended). So my question is: Is there a way to use an OIDC IdP without any backchannel communication involved?
>
> My second attempt was using SAML 2.0 Web Browser SSO with HTTP-Post Binding. That did work fine.
>
> Best regards
> Marcus
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From lists at merit.unu.edu  Thu Jul 27 11:53:51 2017
From: lists at merit.unu.edu (mj)
Date: Thu, 27 Jul 2017 17:53:51 +0200
Subject: [keycloak-user] Dutch translation
In-Reply-To: <CAMvXD=FwQNNF+d4x=uNLCiuMsQ6BJ+qrui7sZs4WOinrAkhpkg@mail.gmail.com>
References: <CAMvXD=FwQNNF+d4x=uNLCiuMsQ6BJ+qrui7sZs4WOinrAkhpkg@mail.gmail.com>
Message-ID: <7b18d5f7-f421-074c-a04d-5885c246236b@merit.unu.edu>

Hi Hynek,

Are you asking someone dutch from the list to "approve" this, to take a 
look and say: "ok"?

(I am dutch, have taken a look, and can say "ok" to it)


On 07/25/2017 03:30 PM, Hynek Mlnarik wrote:
> Can someone please review Dutch translation in PR
> https://github.com/keycloak/keycloak/pull/4340?
> 
> --Hynek
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 

From wgao at utsc.utoronto.ca  Thu Jul 27 14:03:20 2017
From: wgao at utsc.utoronto.ca (Weijun Gao)
Date: Thu, 27 Jul 2017 14:03:20 -0400
Subject: [keycloak-user] scripts or API to query attributes from an external
 SQL database, but don't keep them in Keycloak?
Message-ID: <19355e65-ac89-aee5-67e5-0b4fdce81f16@utsc.utoronto.ca>

Hi,

We have a SQL database with user groups but the database cannot be used 
for authentication (no passwords). We want to authenticate users using 
AD / LDAP, but get a user's group information from the SQL database 
after authentication for authorization purposes (or sending to clients 
as custom attributes) without saving these attributes / group info in 
Keycloak:

     1) authenticate using AD / LDAP

     2) query user group info from the SQL database

     3) authorize / send as custom attributes

There are many user groups in the SQL database, so we don't want to 
maintain them in AD.

Can someone please shed some light on this? Methods / examples / 
documentation? We are kind of new to Keycloak.

Thanks and regards,

Weijun




From mevans at aconex.com  Thu Jul 27 20:52:15 2017
From: mevans at aconex.com (Matt Evans)
Date: Fri, 28 Jul 2017 00:52:15 +0000
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
	<ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>
Message-ID: <ME1PR01MB0769C4D569F17EC9D843D67DA9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>

Sure!

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Thursday, 27 July 2017 8:48 PM
To: Matt Evans <mevans at aconex.com>; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] When should auth_time claim be updated?

Looks like a bug. Could you please create JIRA for this?

Thanks,
Marek

On 26/07/17 01:19, Matt Evans wrote:
> After looking at the code it seems that this is controlled for each authentication attempt with the SSO_AUTH note, the CookieAuthenticator sets it as a client note if cookie authentication succeeds, and the AuthenticationManager checks it and if it's not true updates the auth_time. I can't see anywhere that clears it. I'm not sure how long client notes live, but I assume longer than the current authentication attempt, because once it's set, I can see that it stays true for all my "prompt=login" authentication attempts after that.
>
> I changed the CookieAuthenticator to clear the flag first and this seems to fix the problem for me, however, I'm not sure if that's the best approach?
>
> Matt
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Saturday, 22 July 2017 12:45 AM
> To: Matt Evans <mevans at aconex.com>; keycloak-user <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] When should auth_time claim be updated?
>
> On 21/07/17 07:57, Matt Evans wrote:
>> Hi
>>
>> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>>
>> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>>
>> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>>
>> Is this intended behaviour?
> Yes. The claim "auth_time" points to the time of the active authentication. And the re-authentication with SSO cookie is not treated as "active" authentication, so this won't update auth_time. With "prompt=login" you need actively authenticate, so that will update auth_time.
>
> Marek
>> Thanks
>>
>> Matt
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




From john.d.ament at gmail.com  Thu Jul 27 23:09:40 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Fri, 28 Jul 2017 03:09:40 +0000
Subject: [keycloak-user] Importing Realms with Fixed keys
Message-ID: <CAOqetn-J_32FtzYBTczSdkYGsZTMSL8q=eDCj2CZXHrQi9FjPg@mail.gmail.com>

Hi,

I recently found out about the ability to import a realm on start up,
using keycloak.import.  This works well, however I'm trying to use it to
fully automate a build end to end.

One of the hiccups I'm running into is that it seems I need to know about
the realm-public-key attribute.  When I don't set this, I get 401's.  When
I do set it and everything lines up, I'm able to authenticate
successfully.  The problem is that I can't seem to set the public
key/private key, they can only be generated.  This doesn't work if I'm
relying on a keycloak.json file.

So I guess first, why is realm-public-key required?  If it is required, is
there a way to import a realm with the key already set?  The
publicKey/privateKey attributes seem to be ignored in Keycloak 3.2.

John

From hmlnarik at redhat.com  Fri Jul 28 01:23:43 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 28 Jul 2017 07:23:43 +0200
Subject: [keycloak-user] Dutch translation
In-Reply-To: <7b18d5f7-f421-074c-a04d-5885c246236b@merit.unu.edu>
References: <CAMvXD=FwQNNF+d4x=uNLCiuMsQ6BJ+qrui7sZs4WOinrAkhpkg@mail.gmail.com>
	<7b18d5f7-f421-074c-a04d-5885c246236b@merit.unu.edu>
Message-ID: <CAMvXD=EHTgAbiG0rFCX+Y2RRPjYXganxgMQeTvZ_N4ndos=Egw@mail.gmail.com>

Yes, thank you.

On Thu, Jul 27, 2017 at 5:53 PM, mj <lists at merit.unu.edu> wrote:
> Hi Hynek,
>
> Are you asking someone dutch from the list to "approve" this, to take a
> look and say: "ok"?
>
> (I am dutch, have taken a look, and can say "ok" to it)
>
>
> On 07/25/2017 03:30 PM, Hynek Mlnarik wrote:
>> Can someone please review Dutch translation in PR
>> https://github.com/keycloak/keycloak/pull/4340?
>>
>> --Hynek
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek

From mevans at aconex.com  Fri Jul 28 02:32:15 2017
From: mevans at aconex.com (Matt Evans)
Date: Fri, 28 Jul 2017 06:32:15 +0000
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
	<ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>
Message-ID: <ME1PR01MB07691B667B4F1C35102E6024A9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>

I've been trying to raise a jira ticket. I've gone to https://issues.jboss.org/browse/KEYCLOAK , signed up, and logged in but I can't create issues. The Create button isn't visible.

Do I need to do something else?

Thanks

Matt

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Thursday, 27 July 2017 8:48 PM
To: Matt Evans <mevans at aconex.com>; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] When should auth_time claim be updated?

Looks like a bug. Could you please create JIRA for this?

Thanks,
Marek

On 26/07/17 01:19, Matt Evans wrote:
> After looking at the code it seems that this is controlled for each authentication attempt with the SSO_AUTH note, the CookieAuthenticator sets it as a client note if cookie authentication succeeds, and the AuthenticationManager checks it and if it's not true updates the auth_time. I can't see anywhere that clears it. I'm not sure how long client notes live, but I assume longer than the current authentication attempt, because once it's set, I can see that it stays true for all my "prompt=login" authentication attempts after that.
>
> I changed the CookieAuthenticator to clear the flag first and this seems to fix the problem for me, however, I'm not sure if that's the best approach?
>
> Matt
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Saturday, 22 July 2017 12:45 AM
> To: Matt Evans <mevans at aconex.com>; keycloak-user <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] When should auth_time claim be updated?
>
> On 21/07/17 07:57, Matt Evans wrote:
>> Hi
>>
>> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>>
>> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>>
>> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>>
>> Is this intended behaviour?
> Yes. The claim "auth_time" points to the time of the active authentication. And the re-authentication with SSO cookie is not treated as "active" authentication, so this won't update auth_time. With "prompt=login" you need actively authenticate, so that will update auth_time.
>
> Marek
>> Thanks
>>
>> Matt
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user




From mevans at aconex.com  Fri Jul 28 03:13:37 2017
From: mevans at aconex.com (Matt Evans)
Date: Fri, 28 Jul 2017 07:13:37 +0000
Subject: [keycloak-user] domain-extension example fails to deploy
Message-ID: <ME1PR01MB0769ECD6C38A1BC591BF9EAFA9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>

We're trying to build an spi to extend the database model, and have been having issues, so I thought I'd try the domain-extension example that we based our spi on, just to make sure it's our code that's the problem, and it seems that it's not. Unless we're doing something else wrong! :)

I cloned the source code and checked out the 3.2.1.Final tag, and built the whole project, to get the examples built. (I tried to 'mvn clean install' the examples folder in the distribution but it fails because it can't find the parent projects).

I've just downloaded and extracted 3.2.1.Final distribution, I then copied the `domain-extension-example.jar` from the source code to the `<distribution>\standalone\deployments` folder and then ran `bin\standalone.bat`.

It fails with the same issue that we are experiencing in our spi. I'm now struggling to work out why it's doing that, can anyone suggest what I'm doing wrong?

Thanks!

This is the log:

16:54:45,751 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        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)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
        at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
        at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
        at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
        at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
        at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
        at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
        at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
        ... 6 more
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: keycloak-default] Unable to build Hibernate SessionFactory
        at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
        at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
        at org.keycloak.connections.jpa.util.JpaUtils.createEntityManagerFactory(JpaUtils.java:63)
        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lambda$lazyInit$0(DefaultJpaConnectionProviderFactory.java:201)
        at org.keycloak.models.utils.KeycloakModelUtils.suspendJtaTransaction(KeycloakModelUtils.java:544)
        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:130)
        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:78)
        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:56)
        at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:163)
        at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:51)
        at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:33)
        at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:163)
        at org.keycloak.models.cache.infinispan.RealmCacheSession.getDelegate(RealmCacheSession.java:181)
        at org.keycloak.models.cache.infinispan.RealmCacheSession.getMigrationModel(RealmCacheSession.java:174)
        at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:70)
        at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:243)
        at org.keycloak.services.resources.KeycloakApplication.migrateAndBootstrap(KeycloakApplication.java:184)
        at org.keycloak.services.resources.KeycloakApplication$1.run(KeycloakApplication.java:143)
        at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:227)
        at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
        ... 19 more
Caused by: org.hibernate.MappingException: Could not get constructor for org.hibernate.persister.entity.SingleTableEntityPersister
        at org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:123)
        at org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:77)
        at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:346)
        at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
        at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
        ... 42 more
Caused by: org.hibernate.HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.PojoEntityTuplizer]
        at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:91)
        at org.hibernate.tuple.entity.EntityTuplizerFactory.constructDefaultTuplizer(EntityTuplizerFactory.java:116)
        at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:388)
        at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:509)
        at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:124)
        at sun.reflect.GeneratedConstructorAccessor98.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at org.hibernate.persister.internal.PersisterFactoryImpl.createEntityPersister(PersisterFactoryImpl.java:96)
        ... 46 more
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedConstructorAccessor99.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:88)
        ... 54 more
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
        at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:515)
        at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:492)
        at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:428)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:400)
        at org.hibernate.proxy.pojo.javassist.JavassistProxyFactory.postInstantiate(JavassistProxyFactory.java:72)
        at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:177)
        at org.hibernate.tuple.entity.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:157)
        at org.hibernate.tuple.entity.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:63)
        ... 58 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:170)
        at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:507)
        ... 65 more
Caused by: java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at sun.reflect.GeneratedMethodAccessor314.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:182)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:164)
        ... 66 more
Caused by: java.lang.ClassNotFoundException: org.hibernate.proxy.HibernateProxy from [Module "deployment.domain-extension-example.jar:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
        ... 73 more

From lason at posteo.ru  Fri Jul 28 04:26:25 2017
From: lason at posteo.ru (lason)
Date: Fri, 28 Jul 2017 01:26:25 -0700 (MST)
Subject: [keycloak-user] SAML Identity Broker - First Login/Browser Flow -
	Password
Message-ID: <1501230385275-3949.post@n6.nabble.com>

Hi guys,

I am currently trying to implement the following SAML broker flow with KC
3.0.1.Final:

Assumption: User not known

User goes to App 
User is redirected to KC 
User is redirected to SAML IDP and is authenticated there with smartcard 
User is redirected back to App 
In KC user was created and the assertion attributes were mapped 

Now user logs out
User goes to App 
User is redirected to KC 
User is redirected to SAML IDP and is authenticated there with smartcard 
But now KC says invalid username or password

How can it be done, that on second time IDP brokering,  the user is redirect
to the app without any password check by using the already existing KC user
info on username match (may updates the mapping beforehand in case saml
attributes changed)? 

thanks 
regards
lason




--
View this message in context: http://keycloak-user.88327.x6.nabble.com/SAML-Identity-Broker-First-Login-Browser-Flow-Password-tp3949.html
Sent from the keycloak-user mailing list archive at Nabble.com.

From lason at posteo.ru  Fri Jul 28 05:51:41 2017
From: lason at posteo.ru (lason)
Date: Fri, 28 Jul 2017 02:51:41 -0700 (MST)
Subject: [keycloak-user] SAML Identity Broker - First Login/Browser Flow -
	Password
Message-ID: <1501235501975-3950.post@n6.nabble.com>

Hi guys,

I am currently trying to implement the following SAML broker flow with KC
3.0.1.Final:

Assumption: User not known

User goes to App
User is redirected to KC
User is redirected to SAML IDP and is authenticated there with smartcard
User is redirected back to App
In KC user was created and the assertion attributes were mapped

Now user logs out
User goes to App
User is redirected to KC
User is redirected to SAML IDP and is authenticated there with smartcard
But now KC says invalid username or password

How can it be done, that on second time IDP brokering,  the user is redirect
to the app without any password check by using the already existing KC user
info on username match (may updates the mapping beforehand in case saml
attributes changed)?

thanks
regards
lason 



--
View this message in context: http://keycloak-user.88327.x6.nabble.com/SAML-Identity-Broker-First-Login-Browser-Flow-Password-tp3950.html
Sent from the keycloak-user mailing list archive at Nabble.com.

From thomas.darimont at googlemail.com  Fri Jul 28 07:35:31 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 28 Jul 2017 13:35:31 +0200
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <ME1PR01MB07691B667B4F1C35102E6024A9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
	<ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>
	<ME1PR01MB07691B667B4F1C35102E6024A9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>
Message-ID: <CAK-7U1hrHrebFB9CPU3_XBJhGg28uHWMHJ_skTRavL-LiZ6B6w@mail.gmail.com>

Hello Matt,

you need to create a JBoss jira account.

Cheers,
Thomas

2017-07-28 8:32 GMT+02:00 Matt Evans <mevans at aconex.com>:

> I've been trying to raise a jira ticket. I've gone to
> https://issues.jboss.org/browse/KEYCLOAK , signed up, and logged in but I
> can't create issues. The Create button isn't visible.
>
> Do I need to do something else?
>
> Thanks
>
> Matt
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Thursday, 27 July 2017 8:48 PM
> To: Matt Evans <mevans at aconex.com>; keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] When should auth_time claim be updated?
>
> Looks like a bug. Could you please create JIRA for this?
>
> Thanks,
> Marek
>
> On 26/07/17 01:19, Matt Evans wrote:
> > After looking at the code it seems that this is controlled for each
> authentication attempt with the SSO_AUTH note, the CookieAuthenticator sets
> it as a client note if cookie authentication succeeds, and the
> AuthenticationManager checks it and if it's not true updates the auth_time.
> I can't see anywhere that clears it. I'm not sure how long client notes
> live, but I assume longer than the current authentication attempt, because
> once it's set, I can see that it stays true for all my "prompt=login"
> authentication attempts after that.
> >
> > I changed the CookieAuthenticator to clear the flag first and this seems
> to fix the problem for me, however, I'm not sure if that's the best
> approach?
> >
> > Matt
> >
> > -----Original Message-----
> > From: Marek Posolda [mailto:mposolda at redhat.com]
> > Sent: Saturday, 22 July 2017 12:45 AM
> > To: Matt Evans <mevans at aconex.com>; keycloak-user <
> keycloak-user at lists.jboss.org>
> > Subject: Re: [keycloak-user] When should auth_time claim be updated?
> >
> > On 21/07/17 07:57, Matt Evans wrote:
> >> Hi
> >>
> >> We are working with keycloak v3.2.0  and are using 'prompt=login' to
> initiate a re-authentication for sensitive actions, and we use the
> auth_time claim to determine if this should occur.
> >>
> >> Ordinarily each time we redirect to the auth endpoint with
> 'prompt=login' the auth_time is updated to the time that the authentication
> occurred.
> >>
> >> However, if we then redirect to the auth endpoint and the cookie is
> valid and used, any subsequent time after this authentication that we use
> the auth endpoint with 'prompt=login' the auth_time claim is not updated.
> >>
> >> Is this intended behaviour?
> > Yes. The claim "auth_time" points to the time of the active
> authentication. And the re-authentication with SSO cookie is not treated as
> "active" authentication, so this won't update auth_time. With
> "prompt=login" you need actively authenticate, so that will update
> auth_time.
> >
> > Marek
> >> Thanks
> >>
> >> Matt
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From mevans at aconex.com  Fri Jul 28 08:32:13 2017
From: mevans at aconex.com (Matt Evans)
Date: Fri, 28 Jul 2017 12:32:13 +0000
Subject: [keycloak-user] When should auth_time claim be updated?
In-Reply-To: <CAK-7U1hrHrebFB9CPU3_XBJhGg28uHWMHJ_skTRavL-LiZ6B6w@mail.gmail.com>
References: <ME1PR01MB0769F70E5B12E5222ECC9A19A9A40@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<9d25ac7a-1fa5-48d5-f6b3-e3e8f2d5027c@redhat.com>
	<ME1PR01MB07696C343B6BB8882D150AECA9B80@ME1PR01MB0769.ausprd01.prod.outlook.com>
	<70d87168-c45a-9c65-8a7e-41e6c4392e50@redhat.com>
	<ME1PR01MB07691B667B4F1C35102E6024A9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>,
	<CAK-7U1hrHrebFB9CPU3_XBJhGg28uHWMHJ_skTRavL-LiZ6B6w@mail.gmail.com>
Message-ID: <ME1PR01MB07695AC1F28B2D0CF1259AE6A9BF0@ME1PR01MB0769.ausprd01.prod.outlook.com>

Hi Thomas, how do I do that? I pressed sign up in the top right corner and filled all that in... Then I did 'log in' but it never seemed to show I had logged in

Matt

Matt Evans
Aconex
________________________________
From: Thomas Darimont <thomas.darimont at googlemail.com>
Sent: Friday, July 28, 2017 9:35:31 PM
To: Matt Evans
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] When should auth_time claim be updated?

Hello Matt,

you need to create a JBoss jira account.

Cheers,
Thomas

2017-07-28 8:32 GMT+02:00 Matt Evans <mevans at aconex.com<mailto:mevans at aconex.com>>:
I've been trying to raise a jira ticket. I've gone to https://issues.jboss.org/browse/KEYCLOAK , signed up, and logged in but I can't create issues. The Create button isn't visible.

Do I need to do something else?

Thanks

Matt

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com<mailto:mposolda at redhat.com>]
Sent: Thursday, 27 July 2017 8:48 PM
To: Matt Evans <mevans at aconex.com<mailto:mevans at aconex.com>>; keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] When should auth_time claim be updated?

Looks like a bug. Could you please create JIRA for this?

Thanks,
Marek

On 26/07/17 01:19, Matt Evans wrote:
> After looking at the code it seems that this is controlled for each authentication attempt with the SSO_AUTH note, the CookieAuthenticator sets it as a client note if cookie authentication succeeds, and the AuthenticationManager checks it and if it's not true updates the auth_time. I can't see anywhere that clears it. I'm not sure how long client notes live, but I assume longer than the current authentication attempt, because once it's set, I can see that it stays true for all my "prompt=login" authentication attempts after that.
>
> I changed the CookieAuthenticator to clear the flag first and this seems to fix the problem for me, however, I'm not sure if that's the best approach?
>
> Matt
>
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com<mailto:mposolda at redhat.com>]
> Sent: Saturday, 22 July 2017 12:45 AM
> To: Matt Evans <mevans at aconex.com<mailto:mevans at aconex.com>>; keycloak-user <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: [keycloak-user] When should auth_time claim be updated?
>
> On 21/07/17 07:57, Matt Evans wrote:
>> Hi
>>
>> We are working with keycloak v3.2.0  and are using 'prompt=login' to initiate a re-authentication for sensitive actions, and we use the auth_time claim to determine if this should occur.
>>
>> Ordinarily each time we redirect to the auth endpoint with 'prompt=login' the auth_time is updated to the time that the authentication occurred.
>>
>> However, if we then redirect to the auth endpoint and the cookie is valid and used, any subsequent time after this authentication that we use the auth endpoint with 'prompt=login' the auth_time claim is not updated.
>>
>> Is this intended behaviour?
> Yes. The claim "auth_time" points to the time of the active authentication. And the re-authentication with SSO cookie is not treated as "active" authentication, so this won't update auth_time. With "prompt=login" you need actively authenticate, so that will update auth_time.
>
> Marek
>> Thanks
>>
>> Matt
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user



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


From thiago.addevico at gmail.com  Fri Jul 28 13:43:30 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Fri, 28 Jul 2017 14:43:30 -0300
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAHDpToX81WVWgTbdML_pAUWpHwNz-wHDQ-L9pO23s3fHPSSX7g@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
	<CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
	<CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>
	<CAHDpToX81WVWgTbdML_pAUWpHwNz-wHDQ-L9pO23s3fHPSSX7g@mail.gmail.com>
Message-ID: <CAHDpToUreutSkQxmxk1oZZUP90_gr7qjKaLZZ7Pjf-LZgB_u7Q@mail.gmail.com>

Hi,

It seems that there is an issue analogous to https://issues.jboss.org/
browse/KEYCLOAK-5209 but regarding account link. Can somebody confirm this?

Best regards,
Thiago

On Thu, Jul 20, 2017 at 4:29 PM, Thiago Presa <thiago.addevico at gmail.com>
wrote:

> Hi,
>
> Another change that I've noticed from 3.1.0.Final to 3.2.0.Final is that
> the email "Test connection" button now fails with the message "*Error!* Logged
> in user does not have an e-mail.". The email validation, however, keeps
> working just fine. Is this working as intended?
>
> Best regards,
> Thiago
>
> On Wed, Jul 19, 2017 at 10:25 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
>
>> Yes, thank you.
>>
>> https://issues.jboss.org/browse/KEYCLOAK-5209
>>
>> --Hynek
>>
>> On Wed, Jul 19, 2017 at 2:48 PM, Thiago Presa <thiago.addevico at gmail.com>
>> wrote:
>> > Sure. We've tested the login registration itself and the timeout is in
>> fact
>> > correct. However, when the user tries to federate with google (and
>> Keycloak
>> > tries to verify that e-mail) the timeout is 12 hours. Can you confirm
>> that?
>> >
>> > Best regards,
>> > Thiago Presa
>> >
>> > On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com>
>> wrote:
>> >>
>> >> I've checked email verification upon user registration - the timeout
>> >> in the e-mail is 5 minutes as expected. Can you share more details of
>> >> your setup?
>> >>
>> >> --Hynek
>> >>
>> >> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa <
>> thiago.addevico at gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that we're
>> >> > not
>> >> > sure is intentional. The e-mail verification time changed from 5
>> minutes
>> >> > (User-Initiated Action Lifespan) to 12 hours (Default Admin-Initiated
>> >> > Action Lifespan). It seems weird for us because it does not seem
>> >> > admin-initiated, since it is part of the default user registration
>> >> > process
>> >> > to verify his or her email. Is this a bug?
>> >> >
>> >> > Best regards,
>> >> > Thiago Presa
>> >> > _______________________________________________
>> >> > keycloak-user mailing list
>> >> > keycloak-user at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> --Hynek
>> >
>> >
>>
>>
>>
>> --
>>
>> --Hynek
>>
>
>

From pcfleischer at outlook.com  Sat Jul 29 05:03:17 2017
From: pcfleischer at outlook.com (Phillip Fleischer)
Date: Sat, 29 Jul 2017 09:03:17 +0000
Subject: [keycloak-user] Identity broker login SAMLResponse handling
Message-ID: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>

Hi,

We?re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.

Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.

broker: external-idp-name
client and url name: saml-idp-initiated

https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated


The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.

These result in following results...

1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
|?- infinite redirect loop POST SAMLResponses
2 - {realmUrl}/broker/{broker}/endpoint
|?- handleSamlResponse fails to validate ?code? set to ?relayState?.
3 - {realmUrl}/protocol/saml
|?- handles SAMLResponses as logout and fails.




It feels like we?re either totally missing the mark or this is a use case totally
not supported that we?re attempting to kluge together. Anyone have thoughts where we?re going conceptually wrong??


? Phil


From bburke at redhat.com  Sat Jul 29 10:06:07 2017
From: bburke at redhat.com (Bill Burke)
Date: Sat, 29 Jul 2017 10:06:07 -0400
Subject: [keycloak-user] Identity broker login SAMLResponse handling
In-Reply-To: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>
References: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>
Message-ID: <24a90799-735f-1741-5903-761655e2f15d@redhat.com>

I don't understand what the error is.  Your external IDP sends a login 
response to

https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated

And there is an infinite loop?

On 7/29/17 5:03 AM, Phillip Fleischer wrote:
> Hi,
>
> We?re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.
>
> Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.
>
> broker: external-idp-name
> client and url name: saml-idp-initiated
>
> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>
>
> The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.
>
> These result in following results...
>
> 1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
> |?- infinite redirect loop POST SAMLResponses
> 2 - {realmUrl}/broker/{broker}/endpoint
> |?- handleSamlResponse fails to validate ?code? set to ?relayState?.
> 3 - {realmUrl}/protocol/saml
> |?- handles SAMLResponses as logout and fails.
>
>
>
>
> It feels like we?re either totally missing the mark or this is a use case totally
> not supported that we?re attempting to kluge together. Anyone have thoughts where we?re going conceptually wrong??
>
>
> ? Phil
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From pcfleischer at outlook.com  Sun Jul 30 08:12:16 2017
From: pcfleischer at outlook.com (Phillip Fleischer)
Date: Sun, 30 Jul 2017 12:12:16 +0000
Subject: [keycloak-user] Identity broker login SAMLResponse handling
In-Reply-To: <24a90799-735f-1741-5903-761655e2f15d@redhat.com>
References: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>
	<24a90799-735f-1741-5903-761655e2f15d@redhat.com>
Message-ID: <DM3PR1001MB118237612B0959FB444817F9A6BD0@DM3PR1001MB1182.namprd10.prod.outlook.com>

Yeah, I presume it?s a logical understanding error but to elaborate?  

We?re attempting to relay the succesful login response and client session to an OIDC client using the js adapter.

- Idp Initiated broker seems to be succesful and gets to post login actions 
- Idp Initiated client POST another SAMLResponse to ACS POST Binding URL
- This response is signed by KC, if we set up another broker we?ll endlessly be sending SAMLResponses.

We were thinking we might just be relayed to our client after session and the app would check the session and kick of the OIDC flow. Maybe we need to implement saml adapter in our application to handle the final response?

? Phil

> On Jul 29, 2017, at 10:06 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> I don't understand what the error is.  Your external IDP sends a login 
> response to
> 
> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
> 
> And there is an infinite loop?
> 
> On 7/29/17 5:03 AM, Phillip Fleischer wrote:
>> Hi,
>> 
>> We?re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.
>> 
>> Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.
>> 
>> broker: external-idp-name
>> client and url name: saml-idp-initiated
>> 
>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>> 
>> 
>> The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.
>> 
>> These result in following results...
>> 
>> 1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>> |?- infinite redirect loop POST SAMLResponses
>> 2 - {realmUrl}/broker/{broker}/endpoint
>> |?- handleSamlResponse fails to validate ?code? set to ?relayState?.
>> 3 - {realmUrl}/protocol/saml
>> |?- handles SAMLResponses as logout and fails.
>> 
>> 
>> 
>> 
>> It feels like we?re either totally missing the mark or this is a use case totally
>> not supported that we?re attempting to kluge together. Anyone have thoughts where we?re going conceptually wrong??
>> 
>> 
>> ? Phil
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From thomas_connolly at yahoo.com  Sun Jul 30 19:25:08 2017
From: thomas_connolly at yahoo.com (Thomas Connolly)
Date: Sun, 30 Jul 2017 23:25:08 +0000 (UTC)
Subject: [keycloak-user] Keycloak 3.2.1.Final released
References: <1948212717.2702778.1501457108852.ref@mail.yahoo.com>
Message-ID: <1948212717.2702778.1501457108852@mail.yahoo.com>

Hi

Keycloak 3.2.1 appliance missing in the JBoss (and maven2) repo.

https://repository.jboss.org/nexus/content/groups/public/org/keycloak/keycloak-server-dist/

Raising as our build pulls this down then uses the CLI to overlay customisations.

Regards Tom Connolly.

Message: 3
Date: Mon, 24 Jul 2017 16:21:47 +0200
From: Marek Posolda <mposolda at redhat.com>
Subject: Re: [keycloak-user] Keycloak 3.2.1.Final released
To: "Federico Navarro Polo - Info.nl" <federico at info.nl>,
????"keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
Message-ID: <187ebc41-ec5a-bdd2-6d8d-c83a852e2935 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Thanks for the info! I missed one step during the release process though :)

It is available now in jboss repository 
https://repository.jboss.org/nexus/content/groups/public/org/keycloak/keycloak-core/ 
. AFAIK in public maven repository on repo1.maven.org, it will be in 
next 1-2 days.

Sorry for trouble,
Marek

Dne 24.7.2017 v 13:46 Federico Navarro Polo - Info.nl napsal(a):
> Hello Marek,
>
> Seems like dependencies for 3.2.1.Final are not in maven, latest available dependencies are 3.2.0.Final
>
> https://repo.maven.apache.org/maven2/org/keycloak/keycloak-core/
>
>
> Regards,
> Federico
>
>
> On 21/07/17 16:36, "keycloak-user-bounces at lists.jboss.org on behalf of Marek Posolda" <keycloak-user-bounces at lists.jboss.org on behalf of mposolda at redhat.com> wrote:
>
>??????Keycloak 3.2.1.Final has just been released.
>??????
>??????This release doesn't contain any new features. However there are few
>??????fixed bugs related to authorization services and new permissions for
>??????admin REST API.
>??????
>??????To download the release go to the Keycloak homepage
>??????<http://www.keycloak.org/downloads>.
>??????
>??????The full list of resolved issues is available in JIRA
>??????<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.2.1.Final>
>??????.
>??????Upgrading
>??????
>??????Before you upgrade remember to backup your database and check the migration
>??????guide
>??????<https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
>??????.
>??????
>??????_______________________________________________
>??????keycloak-user mailing list
>??????keycloak-user at lists.jboss.org
>??????https://lists.jboss.org/mailman/listinfo/keycloak-user
>??????
>


From hmlnarik at redhat.com  Mon Jul 31 01:43:13 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Jul 2017 07:43:13 +0200
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAHDpToUreutSkQxmxk1oZZUP90_gr7qjKaLZZ7Pjf-LZgB_u7Q@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
	<CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
	<CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>
	<CAHDpToX81WVWgTbdML_pAUWpHwNz-wHDQ-L9pO23s3fHPSSX7g@mail.gmail.com>
	<CAHDpToUreutSkQxmxk1oZZUP90_gr7qjKaLZZ7Pjf-LZgB_u7Q@mail.gmail.com>
Message-ID: <CAMvXD=HMvO_e6z=BR5JA27idLFgHYtPS0m27tgv2uOn0KBZ1EQ@mail.gmail.com>

I don't think I can confirm it anymore. Can you please explain how
that differs from case "when the user tries to federate with google"
that you reported originally and that has been fixed in latest master
at that time?

--Hynek

On Fri, Jul 28, 2017 at 7:43 PM, Thiago Presa <thiago.addevico at gmail.com> wrote:
> Hi,
>
> It seems that there is an issue analogous to
> https://issues.jboss.org/browse/KEYCLOAK-5209 but regarding account link.
> Can somebody confirm this?
>
> Best regards,
> Thiago
>
> On Thu, Jul 20, 2017 at 4:29 PM, Thiago Presa <thiago.addevico at gmail.com>
> wrote:
>>
>> Hi,
>>
>> Another change that I've noticed from 3.1.0.Final to 3.2.0.Final is that
>> the email "Test connection" button now fails with the message "Error! Logged
>> in user does not have an e-mail.". The email validation, however, keeps
>> working just fine. Is this working as intended?
>>
>> Best regards,
>> Thiago
>>
>> On Wed, Jul 19, 2017 at 10:25 AM, Hynek Mlnarik <hmlnarik at redhat.com>
>> wrote:
>>>
>>> Yes, thank you.
>>>
>>> https://issues.jboss.org/browse/KEYCLOAK-5209
>>>
>>> --Hynek
>>>
>>> On Wed, Jul 19, 2017 at 2:48 PM, Thiago Presa <thiago.addevico at gmail.com>
>>> wrote:
>>> > Sure. We've tested the login registration itself and the timeout is in
>>> > fact
>>> > correct. However, when the user tries to federate with google (and
>>> > Keycloak
>>> > tries to verify that e-mail) the timeout is 12 hours. Can you confirm
>>> > that?
>>> >
>>> > Best regards,
>>> > Thiago Presa
>>> >
>>> > On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com>
>>> > wrote:
>>> >>
>>> >> I've checked email verification upon user registration - the timeout
>>> >> in the e-mail is 5 minutes as expected. Can you share more details of
>>> >> your setup?
>>> >>
>>> >> --Hynek
>>> >>
>>> >> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa
>>> >> <thiago.addevico at gmail.com>
>>> >> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that
>>> >> > we're
>>> >> > not
>>> >> > sure is intentional. The e-mail verification time changed from 5
>>> >> > minutes
>>> >> > (User-Initiated Action Lifespan) to 12 hours (Default
>>> >> > Admin-Initiated
>>> >> > Action Lifespan). It seems weird for us because it does not seem
>>> >> > admin-initiated, since it is part of the default user registration
>>> >> > process
>>> >> > to verify his or her email. Is this a bug?
>>> >> >
>>> >> > Best regards,
>>> >> > Thiago Presa
>>> >> > _______________________________________________
>>> >> > keycloak-user mailing list
>>> >> > keycloak-user at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> --Hynek
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> --Hynek
>>
>>
>



-- 

--Hynek

From hmlnarik at redhat.com  Mon Jul 31 02:00:09 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Jul 2017 08:00:09 +0200
Subject: [keycloak-user] Identity broker login SAMLResponse handling
In-Reply-To: <DM3PR1001MB118237612B0959FB444817F9A6BD0@DM3PR1001MB1182.namprd10.prod.outlook.com>
References: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>
	<24a90799-735f-1741-5903-761655e2f15d@redhat.com>
	<DM3PR1001MB118237612B0959FB444817F9A6BD0@DM3PR1001MB1182.namprd10.prod.outlook.com>
Message-ID: <CAMvXD=H7kTQ_+hSuqs8NSPBKsb3xb3S8vkDhQp2su=CGdQk+9w@mail.gmail.com>

I don't understand the scenario either. What exactly is the scenario?
The loop is between which parties? How does "another broker" fit into
the picture, is it even Keycloak? Why does your OIDC client not use
Keycloak OIDC capabilities directly? Is it necessary to relay the SAML
response to the client and process it there?

Can you rephrase it with explicitly labeling the parties (kc server,
non-kc-server (?), client, brokered idp, ...) when you mention them?

On Sun, Jul 30, 2017 at 2:12 PM, Phillip Fleischer
<pcfleischer at outlook.com> wrote:
> Yeah, I presume it?s a logical understanding error but to elaborate?
>
> We?re attempting to relay the succesful login response and client session to an OIDC client using the js adapter.
>
> - Idp Initiated broker seems to be succesful and gets to post login actions
> - Idp Initiated client POST another SAMLResponse to ACS POST Binding URL
> - This response is signed by KC, if we set up another broker we?ll endlessly be sending SAMLResponses.
>
> We were thinking we might just be relayed to our client after session and the app would check the session and kick of the OIDC flow. Maybe we need to implement saml adapter in our application to handle the final response?
>
> ? Phil
>
>> On Jul 29, 2017, at 10:06 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> I don't understand what the error is.  Your external IDP sends a login
>> response to
>>
>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>
>> And there is an infinite loop?
>>
>> On 7/29/17 5:03 AM, Phillip Fleischer wrote:
>>> Hi,
>>>
>>> We?re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.
>>>
>>> Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.
>>>
>>> broker: external-idp-name
>>> client and url name: saml-idp-initiated
>>>
>>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>
>>>
>>> The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.
>>>
>>> These result in following results...
>>>
>>> 1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>> |?- infinite redirect loop POST SAMLResponses
>>> 2 - {realmUrl}/broker/{broker}/endpoint
>>> |?- handleSamlResponse fails to validate ?code? set to ?relayState?.
>>> 3 - {realmUrl}/protocol/saml
>>> |?- handles SAMLResponses as logout and fails.
>>>
>>>
>>>
>>>
>>> It feels like we?re either totally missing the mark or this is a use case totally
>>> not supported that we?re attempting to kluge together. Anyone have thoughts where we?re going conceptually wrong??
>>>
>>>
>>> ? Phil
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 

--Hynek


From pcfleischer at outlook.com  Mon Jul 31 05:53:24 2017
From: pcfleischer at outlook.com (Phillip Fleischer)
Date: Mon, 31 Jul 2017 09:53:24 +0000
Subject: [keycloak-user] Identity broker login SAMLResponse handling
In-Reply-To: <CAMvXD=H7kTQ_+hSuqs8NSPBKsb3xb3S8vkDhQp2su=CGdQk+9w@mail.gmail.com>
References: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>
	<24a90799-735f-1741-5903-761655e2f15d@redhat.com>
	<DM3PR1001MB118237612B0959FB444817F9A6BD0@DM3PR1001MB1182.namprd10.prod.outlook.com>
	<CAMvXD=H7kTQ_+hSuqs8NSPBKsb3xb3S8vkDhQp2su=CGdQk+9w@mail.gmail.com>
Message-ID: <DM3PR1001MB11829E565558E89DD6C3769BA6B20@DM3PR1001MB1182.namprd10.prod.outlook.com>

No problem,

Our application is angular js using keycloak oidc adapter with spring boot back end.  The native behavior to use keyclaok OIDC directly.

The Third Party (Non-kc-server) is the external SAML IdP which we wish to trust to authenticate in via SAMLResponse registering/linking and authenticating into the application.   We expect we may have many of these so we?re attempting to use KC for ease of use instead of rolling our own.

1) Not-KC -> POST SAMLResponse to kc to authenticate.
2) KC -> Idp broker - handle this saml response.
3) KC -> SAML client - Idp Initiated 
   (cannot use broker directly - it appears to require that KC initated SAMLRequest with ?code? to be sent in response??)
4) KC -> SAML client - result in POST SAMLResponse to the ACS url.
   (SAMLResponse still does not have a code that could be handled directly by broker directly??)

Up to #3 seems to work, but I think we?d expect that #4 saml client would redirect us to our client (thru relaystate), but it results with a SAMLResponse POST to the ACS url in the client configuration.  This is basically back where we started? so hence the logical infinite loop (if we add more brokers and clients we just keep getting more and more saml responses without codes).

Hope that helps explain, 

? Phil

> On Jul 31, 2017, at 2:00 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
> 
> I don't understand the scenario either. What exactly is the scenario?
> The loop is between which parties? How does "another broker" fit into
> the picture, is it even Keycloak? Why does your OIDC client not use
> Keycloak OIDC capabilities directly? Is it necessary to relay the SAML
> response to the client and process it there?
> 
> Can you rephrase it with explicitly labeling the parties (kc server,
> non-kc-server (?), client, brokered idp, ...) when you mention them?
> 
> On Sun, Jul 30, 2017 at 2:12 PM, Phillip Fleischer
> <pcfleischer at outlook.com> wrote:
>> Yeah, I presume it?s a logical understanding error but to elaborate?
>> 
>> We?re attempting to relay the succesful login response and client session to an OIDC client using the js adapter.
>> 
>> - Idp Initiated broker seems to be succesful and gets to post login actions
>> - Idp Initiated client POST another SAMLResponse to ACS POST Binding URL
>> - This response is signed by KC, if we set up another broker we?ll endlessly be sending SAMLResponses.
>> 
>> We were thinking we might just be relayed to our client after session and the app would check the session and kick of the OIDC flow. Maybe we need to implement saml adapter in our application to handle the final response?
>> 
>> ? Phil
>> 
>>> On Jul 29, 2017, at 10:06 AM, Bill Burke <bburke at redhat.com> wrote:
>>> 
>>> I don't understand what the error is.  Your external IDP sends a login
>>> response to
>>> 
>>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>> 
>>> And there is an infinite loop?
>>> 
>>> On 7/29/17 5:03 AM, Phillip Fleischer wrote:
>>>> Hi,
>>>> 
>>>> We?re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.
>>>> 
>>>> Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.
>>>> 
>>>> broker: external-idp-name
>>>> client and url name: saml-idp-initiated
>>>> 
>>>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>> 
>>>> 
>>>> The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.
>>>> 
>>>> These result in following results...
>>>> 
>>>> 1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>> |?- infinite redirect loop POST SAMLResponses
>>>> 2 - {realmUrl}/broker/{broker}/endpoint
>>>> |?- handleSamlResponse fails to validate ?code? set to ?relayState?.
>>>> 3 - {realmUrl}/protocol/saml
>>>> |?- handles SAMLResponses as logout and fails.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> It feels like we?re either totally missing the mark or this is a use case totally
>>>> not supported that we?re attempting to kluge together. Anyone have thoughts where we?re going conceptually wrong??
>>>> 
>>>> 
>>>> ? Phil
>>>> 
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> 
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> 
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 
> 
> -- 
> 
> --Hynek



From pcfleischer at outlook.com  Mon Jul 31 06:08:00 2017
From: pcfleischer at outlook.com (Phillip Fleischer)
Date: Mon, 31 Jul 2017 10:08:00 +0000
Subject: [keycloak-user] Identity broker login SAMLResponse handling
In-Reply-To: <83F6A601-D5EC-4249-8FA6-6D306042758C@outlook.com>
References: <CY1PR1001MB1177B54D02077A016868167CA6BC0@CY1PR1001MB1177.namprd10.prod.outlook.com>
	<24a90799-735f-1741-5903-761655e2f15d@redhat.com>
	<DM3PR1001MB118237612B0959FB444817F9A6BD0@DM3PR1001MB1182.namprd10.prod.outlook.com>
	<CAMvXD=H7kTQ_+hSuqs8NSPBKsb3xb3S8vkDhQp2su=CGdQk+9w@mail.gmail.com>
	<83F6A601-D5EC-4249-8FA6-6D306042758C@outlook.com>
Message-ID: <DM3PR1001MB11821AE7289DBACFCE9629F4A6B20@DM3PR1001MB1182.namprd10.prod.outlook.com>

Maybe we just have our client setup wrong and it?s possible to configure it to redirect to the ?management url???

We tried that for a while but it seemed that the client expected to only want to redirect or post another SAML Response to another endpoint.

> On Jul 31, 2017, at 5:53 AM, Phillip Fleischer <pcfleischer at outlook.com> wrote:
> 
> No problem,
> 
> Our application is angular js using keycloak oidc adapter with spring boot back end.  The native behavior to use keyclaok OIDC directly.
> 
> The Third Party (Non-kc-server) is the external SAML IdP which we wish to trust to authenticate in via SAMLResponse registering/linking and authenticating into the application.   We expect we may have many of these so we?re attempting to use KC for ease of use instead of rolling our own.
> 
> 1) Not-KC -> POST SAMLResponse to kc to authenticate.
> 2) KC -> Idp broker - handle this saml response.
> 3) KC -> SAML client - Idp Initiated 
>   (cannot use broker directly - it appears to require that KC initated SAMLRequest with ?code? to be sent in response??)
> 4) KC -> SAML client - result in POST SAMLResponse to the ACS url.
>   (SAMLResponse still does not have a code that could be handled directly by broker directly??)
> 
> Up to #3 seems to work, but I think we?d expect that #4 saml client would redirect us to our client (thru relaystate), but it results with a SAMLResponse POST to the ACS url in the client configuration.  This is basically back where we started? so hence the logical infinite loop (if we add more brokers and clients we just keep getting more and more saml responses without codes).
> 
> Hope that helps explain, 
> 
> ? Phil
> 
>> On Jul 31, 2017, at 2:00 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>> 
>> I don't understand the scenario either. What exactly is the scenario?
>> The loop is between which parties? How does "another broker" fit into
>> the picture, is it even Keycloak? Why does your OIDC client not use
>> Keycloak OIDC capabilities directly? Is it necessary to relay the SAML
>> response to the client and process it there?
>> 
>> Can you rephrase it with explicitly labeling the parties (kc server,
>> non-kc-server (?), client, brokered idp, ...) when you mention them?
>> 
>> On Sun, Jul 30, 2017 at 2:12 PM, Phillip Fleischer
>> <pcfleischer at outlook.com> wrote:
>>> Yeah, I presume it?s a logical understanding error but to elaborate?
>>> 
>>> We?re attempting to relay the succesful login response and client session to an OIDC client using the js adapter.
>>> 
>>> - Idp Initiated broker seems to be succesful and gets to post login actions
>>> - Idp Initiated client POST another SAMLResponse to ACS POST Binding URL
>>> - This response is signed by KC, if we set up another broker we?ll endlessly be sending SAMLResponses.
>>> 
>>> We were thinking we might just be relayed to our client after session and the app would check the session and kick of the OIDC flow. Maybe we need to implement saml adapter in our application to handle the final response?
>>> 
>>> ? Phil
>>> 
>>>> On Jul 29, 2017, at 10:06 AM, Bill Burke <bburke at redhat.com> wrote:
>>>> 
>>>> I don't understand what the error is.  Your external IDP sends a login
>>>> response to
>>>> 
>>>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>> 
>>>> And there is an infinite loop?
>>>> 
>>>> On 7/29/17 5:03 AM, Phillip Fleischer wrote:
>>>>> Hi,
>>>>> 
>>>>> We?re using keycloak for several authorization use cases already and are attempting to prototype some identity brokering with an external IdP application.
>>>>> 
>>>>> Our current configuration the user is logged in the external IdP which sends a POST with the SAMLResponse directly to our broker. It looks the appropriate solution is idp initiated configuration in the examples.
>>>>> 
>>>>> broker: external-idp-name
>>>>> client and url name: saml-idp-initiated
>>>>> 
>>>>> https://{root}/auth/realms/{realm}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>>> 
>>>>> 
>>>>> The challenge is that our client the posts yet another SAMLResponse either back to our broker or to the realm saml service.
>>>>> 
>>>>> These result in following results...
>>>>> 
>>>>> 1 - {realmUrl}/broker/external-idp-name/endpoint/clients/saml-idp-initiated
>>>>> |?- infinite redirect loop POST SAMLResponses
>>>>> 2 - {realmUrl}/broker/{broker}/endpoint
>>>>> |?- handleSamlResponse fails to validate ?code? set to ?relayState?.
>>>>> 3 - {realmUrl}/protocol/saml
>>>>> |?- handles SAMLResponses as logout and fails.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> It feels like we?re either totally missing the mark or this is a use case totally
>>>>> not supported that we?re attempting to kluge together. Anyone have thoughts where we?re going conceptually wrong??
>>>>> 
>>>>> 
>>>>> ? Phil
>>>>> 
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> 
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> 
>>> 
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> 
>> 
>> 
>> -- 
>> 
>> --Hynek
> 



From narendra_kadali at hotmail.com  Mon Jul 31 07:25:01 2017
From: narendra_kadali at hotmail.com (Narendra Kadali)
Date: Mon, 31 Jul 2017 11:25:01 +0000
Subject: [keycloak-user] Revokin an OAuth token
Message-ID: <CY4PR03MB2903B7FDBD7048ED601A9E369BB20@CY4PR03MB2903.namprd03.prod.outlook.com>

Hi,


I am wondering if Keycloak can support revoking an OAuth 's access/refresh tokens. I tried to look into Keycloak documentation and api guide but can't find any info on it.

I see there is an RFC for OAuth token revocation -  RFC 7009 (https://tools.ietf.org/html/rfc7009) . Is there any plans for implementing this RFC in future?


Thanks!

Naren

From sblanc at redhat.com  Mon Jul 31 08:14:28 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 31 Jul 2017 14:14:28 +0200
Subject: [keycloak-user] Revokin an OAuth token
In-Reply-To: <CY4PR03MB2903B7FDBD7048ED601A9E369BB20@CY4PR03MB2903.namprd03.prod.outlook.com>
References: <CY4PR03MB2903B7FDBD7048ED601A9E369BB20@CY4PR03MB2903.namprd03.prod.outlook.com>
Message-ID: <CAMZCGg91ZvUazCD127WAWbOxRXu0QpK6Rx0iVzeYFAZhepynjw@mail.gmail.com>

Is this what you are looking for
https://keycloak.gitbooks.io/documentation/content/server_admin/topics/sessions/revocation.html
?

On Mon, Jul 31, 2017 at 1:25 PM, Narendra Kadali <
narendra_kadali at hotmail.com> wrote:

> Hi,
>
>
> I am wondering if Keycloak can support revoking an OAuth 's access/refresh
> tokens. I tried to look into Keycloak documentation and api guide but can't
> find any info on it.
>
> I see there is an RFC for OAuth token revocation -  RFC 7009 (
> https://tools.ietf.org/html/rfc7009) . Is there any plans for
> implementing this RFC in future?
>
>
> Thanks!
>
> Naren
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From thiago.addevico at gmail.com  Mon Jul 31 08:20:46 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Mon, 31 Jul 2017 09:20:46 -0300
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAMvXD=HMvO_e6z=BR5JA27idLFgHYtPS0m27tgv2uOn0KBZ1EQ@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
	<CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
	<CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>
	<CAHDpToX81WVWgTbdML_pAUWpHwNz-wHDQ-L9pO23s3fHPSSX7g@mail.gmail.com>
	<CAHDpToUreutSkQxmxk1oZZUP90_gr7qjKaLZZ7Pjf-LZgB_u7Q@mail.gmail.com>
	<CAMvXD=HMvO_e6z=BR5JA27idLFgHYtPS0m27tgv2uOn0KBZ1EQ@mail.gmail.com>
Message-ID: <CAHDpToXyFU4aiAFWeq+UaWpQnD0awMuYEa7zJ8XUzVYZ3-nJfA@mail.gmail.com>

Sure. It seems that what was fixed was the e-mail verification timeout,
which renders the theme template email-verification.ftl.
What I'm reporting now is that when the user attempts to perform a social
login, an e-mail is sent to his e-mail address, asking for confirmation of
the account link. This e-mail renders the template
identity-provider-link.ftl This now is rendering the Default
Admin-Initiated Action Lifespan.

Best regards,
Thiago

On Mon, Jul 31, 2017 at 2:43 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> I don't think I can confirm it anymore. Can you please explain how
> that differs from case "when the user tries to federate with google"
> that you reported originally and that has been fixed in latest master
> at that time?
>
> --Hynek
>
> On Fri, Jul 28, 2017 at 7:43 PM, Thiago Presa <thiago.addevico at gmail.com>
> wrote:
> > Hi,
> >
> > It seems that there is an issue analogous to
> > https://issues.jboss.org/browse/KEYCLOAK-5209 but regarding account
> link.
> > Can somebody confirm this?
> >
> > Best regards,
> > Thiago
> >
> > On Thu, Jul 20, 2017 at 4:29 PM, Thiago Presa <thiago.addevico at gmail.com
> >
> > wrote:
> >>
> >> Hi,
> >>
> >> Another change that I've noticed from 3.1.0.Final to 3.2.0.Final is that
> >> the email "Test connection" button now fails with the message "Error!
> Logged
> >> in user does not have an e-mail.". The email validation, however, keeps
> >> working just fine. Is this working as intended?
> >>
> >> Best regards,
> >> Thiago
> >>
> >> On Wed, Jul 19, 2017 at 10:25 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> >> wrote:
> >>>
> >>> Yes, thank you.
> >>>
> >>> https://issues.jboss.org/browse/KEYCLOAK-5209
> >>>
> >>> --Hynek
> >>>
> >>> On Wed, Jul 19, 2017 at 2:48 PM, Thiago Presa <
> thiago.addevico at gmail.com>
> >>> wrote:
> >>> > Sure. We've tested the login registration itself and the timeout is
> in
> >>> > fact
> >>> > correct. However, when the user tries to federate with google (and
> >>> > Keycloak
> >>> > tries to verify that e-mail) the timeout is 12 hours. Can you confirm
> >>> > that?
> >>> >
> >>> > Best regards,
> >>> > Thiago Presa
> >>> >
> >>> > On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> >>> > wrote:
> >>> >>
> >>> >> I've checked email verification upon user registration - the timeout
> >>> >> in the e-mail is 5 minutes as expected. Can you share more details
> of
> >>> >> your setup?
> >>> >>
> >>> >> --Hynek
> >>> >>
> >>> >> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa
> >>> >> <thiago.addevico at gmail.com>
> >>> >> wrote:
> >>> >> > Hi,
> >>> >> >
> >>> >> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that
> >>> >> > we're
> >>> >> > not
> >>> >> > sure is intentional. The e-mail verification time changed from 5
> >>> >> > minutes
> >>> >> > (User-Initiated Action Lifespan) to 12 hours (Default
> >>> >> > Admin-Initiated
> >>> >> > Action Lifespan). It seems weird for us because it does not seem
> >>> >> > admin-initiated, since it is part of the default user registration
> >>> >> > process
> >>> >> > to verify his or her email. Is this a bug?
> >>> >> >
> >>> >> > Best regards,
> >>> >> > Thiago Presa
> >>> >> > _______________________________________________
> >>> >> > keycloak-user mailing list
> >>> >> > keycloak-user at lists.jboss.org
> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >>
> >>> >> --Hynek
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> --Hynek
> >>
> >>
> >
>
>
>
> --
>
> --Hynek
>

From thiago.addevico at gmail.com  Mon Jul 31 08:48:07 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Mon, 31 Jul 2017 09:48:07 -0300
Subject: [keycloak-user] Email verification timeout
In-Reply-To: <CAHDpToXyFU4aiAFWeq+UaWpQnD0awMuYEa7zJ8XUzVYZ3-nJfA@mail.gmail.com>
References: <CAHDpToUqN+_BbotRnKmmcZ-Mde5f_C-mTtq5xRwuB4CLxWC4ww@mail.gmail.com>
	<CAMvXD=H4D+0ijYd2VGMs4A-0hjAXBsXQJvY9BHZcO6cLX8WjCg@mail.gmail.com>
	<CAHDpToV6vTNBGfDsDMbAj6yPzvRfsPaqBAk+tz8xrxNVxmFfnw@mail.gmail.com>
	<CAMvXD=FN3pn_F4anh3-Ag5T4+9_kTUyd12QtJphrw198FxVKNw@mail.gmail.com>
	<CAHDpToX81WVWgTbdML_pAUWpHwNz-wHDQ-L9pO23s3fHPSSX7g@mail.gmail.com>
	<CAHDpToUreutSkQxmxk1oZZUP90_gr7qjKaLZZ7Pjf-LZgB_u7Q@mail.gmail.com>
	<CAMvXD=HMvO_e6z=BR5JA27idLFgHYtPS0m27tgv2uOn0KBZ1EQ@mail.gmail.com>
	<CAHDpToXyFU4aiAFWeq+UaWpQnD0awMuYEa7zJ8XUzVYZ3-nJfA@mail.gmail.com>
Message-ID: <CAHDpToWZAO7Xrgva=Eqjr2dEnpif2+njZG-TY9jNESRks4-2LA@mail.gmail.com>

Sorry, I may have confused myself. I thought https://issues.jboss.org/
browse/KEYCLOAK-5209 was already available at 3.2.1. I guess it's the same
bug, I just didn't realize where it occurred.

Best regards,
Thiago

On Mon, Jul 31, 2017 at 9:20 AM, Thiago Presa <thiago.addevico at gmail.com>
wrote:

> Sure. It seems that what was fixed was the e-mail verification timeout,
> which renders the theme template email-verification.ftl.
> What I'm reporting now is that when the user attempts to perform a social
> login, an e-mail is sent to his e-mail address, asking for confirmation of
> the account link. This e-mail renders the template
> identity-provider-link.ftl This now is rendering the Default
> Admin-Initiated Action Lifespan.
>
> Best regards,
> Thiago
>
> On Mon, Jul 31, 2017 at 2:43 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
>
>> I don't think I can confirm it anymore. Can you please explain how
>> that differs from case "when the user tries to federate with google"
>> that you reported originally and that has been fixed in latest master
>> at that time?
>>
>> --Hynek
>>
>> On Fri, Jul 28, 2017 at 7:43 PM, Thiago Presa <thiago.addevico at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > It seems that there is an issue analogous to
>> > https://issues.jboss.org/browse/KEYCLOAK-5209 but regarding account
>> link.
>> > Can somebody confirm this?
>> >
>> > Best regards,
>> > Thiago
>> >
>> > On Thu, Jul 20, 2017 at 4:29 PM, Thiago Presa <
>> thiago.addevico at gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Another change that I've noticed from 3.1.0.Final to 3.2.0.Final is
>> that
>> >> the email "Test connection" button now fails with the message "Error!
>> Logged
>> >> in user does not have an e-mail.". The email validation, however, keeps
>> >> working just fine. Is this working as intended?
>> >>
>> >> Best regards,
>> >> Thiago
>> >>
>> >> On Wed, Jul 19, 2017 at 10:25 AM, Hynek Mlnarik <hmlnarik at redhat.com>
>> >> wrote:
>> >>>
>> >>> Yes, thank you.
>> >>>
>> >>> https://issues.jboss.org/browse/KEYCLOAK-5209
>> >>>
>> >>> --Hynek
>> >>>
>> >>> On Wed, Jul 19, 2017 at 2:48 PM, Thiago Presa <
>> thiago.addevico at gmail.com>
>> >>> wrote:
>> >>> > Sure. We've tested the login registration itself and the timeout is
>> in
>> >>> > fact
>> >>> > correct. However, when the user tries to federate with google (and
>> >>> > Keycloak
>> >>> > tries to verify that e-mail) the timeout is 12 hours. Can you
>> confirm
>> >>> > that?
>> >>> >
>> >>> > Best regards,
>> >>> > Thiago Presa
>> >>> >
>> >>> > On Wed, Jul 19, 2017 at 2:30 AM, Hynek Mlnarik <hmlnarik at redhat.com
>> >
>> >>> > wrote:
>> >>> >>
>> >>> >> I've checked email verification upon user registration - the
>> timeout
>> >>> >> in the e-mail is 5 minutes as expected. Can you share more details
>> of
>> >>> >> your setup?
>> >>> >>
>> >>> >> --Hynek
>> >>> >>
>> >>> >> On Tue, Jul 18, 2017 at 7:27 PM, Thiago Presa
>> >>> >> <thiago.addevico at gmail.com>
>> >>> >> wrote:
>> >>> >> > Hi,
>> >>> >> >
>> >>> >> > We've noticed a change between 3.1.0.Final and 3.2.0.Final that
>> >>> >> > we're
>> >>> >> > not
>> >>> >> > sure is intentional. The e-mail verification time changed from 5
>> >>> >> > minutes
>> >>> >> > (User-Initiated Action Lifespan) to 12 hours (Default
>> >>> >> > Admin-Initiated
>> >>> >> > Action Lifespan). It seems weird for us because it does not seem
>> >>> >> > admin-initiated, since it is part of the default user
>> registration
>> >>> >> > process
>> >>> >> > to verify his or her email. Is this a bug?
>> >>> >> >
>> >>> >> > Best regards,
>> >>> >> > Thiago Presa
>> >>> >> > _______________________________________________
>> >>> >> > keycloak-user mailing list
>> >>> >> > keycloak-user at lists.jboss.org
>> >>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >>
>> >>> >> --Hynek
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> --Hynek
>> >>
>> >>
>> >
>>
>>
>>
>> --
>>
>> --Hynek
>>
>
>

From Harshad.Keluskar at Criti.in  Mon Jul 31 09:13:11 2017
From: Harshad.Keluskar at Criti.in (Harshad Keluskar)
Date: Mon, 31 Jul 2017 13:13:11 +0000
Subject: [keycloak-user] Help for Keycloak OpenID Connect integration with
	Apereo CAS
Message-ID: <ca5586bd2e464785afdf0d4571f7e346@CRITIMAIL.creativeit.in>

Hi Team,

I would need to use Keycloak as IDP and CAS as a delegation authentication for Liferay 7 CE. It would be great, if anyone could help me with examples or step by step guide, if ready with anyone.

Thanks,
Harshad. 


From bburke at redhat.com  Mon Jul 31 09:45:55 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Jul 2017 09:45:55 -0400
Subject: [keycloak-user] Revokin an OAuth token
In-Reply-To: <CAMZCGg91ZvUazCD127WAWbOxRXu0QpK6Rx0iVzeYFAZhepynjw@mail.gmail.com>
References: <CY4PR03MB2903B7FDBD7048ED601A9E369BB20@CY4PR03MB2903.namprd03.prod.outlook.com>
	<CAMZCGg91ZvUazCD127WAWbOxRXu0QpK6Rx0iVzeYFAZhepynjw@mail.gmail.com>
Message-ID: <141e18d6-d63f-b69e-68e7-52a19ed864c7@redhat.com>

logout endpoint accepts a token.


On 7/31/17 8:14 AM, Sebastien Blanc wrote:
> Is this what you are looking for
> https://keycloak.gitbooks.io/documentation/content/server_admin/topics/sessions/revocation.html
> ?
>
> On Mon, Jul 31, 2017 at 1:25 PM, Narendra Kadali <
> narendra_kadali at hotmail.com> wrote:
>
>> Hi,
>>
>>
>> I am wondering if Keycloak can support revoking an OAuth 's access/refresh
>> tokens. I tried to look into Keycloak documentation and api guide but can't
>> find any info on it.
>>
>> I see there is an RFC for OAuth token revocation -  RFC 7009 (
>> https://tools.ietf.org/html/rfc7009) . Is there any plans for
>> implementing this RFC in future?
>>
>>
>> Thanks!
>>
>> Naren
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From rjvduijn at gmail.com  Mon Jul 31 10:51:44 2017
From: rjvduijn at gmail.com (Richard van Duijn)
Date: Mon, 31 Jul 2017 14:51:44 +0000
Subject: [keycloak-user] Obtaining profile from AccessToken
Message-ID: <CAO54wy7Bh1Rx6mGAg6oBahqWc8Mvj34nBH1W4ffJTBsWhJV9qA@mail.gmail.com>

I have an application that uses bearer-token validation of backend
requests. This Bearer token is an Accesstoken.
What API endpoint should i call to obtain the full User Profile including
IDToken and RefreshToken?
I know of the userInfo endpoint, but that only gives me basic user
information, not the IdToken or Refreshtoken?

Thanks in advance!

From ghosh.rajesh at gmail.com  Mon Jul 24 12:47:58 2017
From: ghosh.rajesh at gmail.com (Rajesh Ghosh)
Date: Mon, 24 Jul 2017 16:47:58 -0000
Subject: [keycloak-user] Hitting error -- "Didn't find publicKey for
 specified kid"
In-Reply-To: <CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
References: <CAOKDOxLs2BFxtSFMUb9aVHB1FeEOFUaaCfDuO8OT18Cf1haZFA@mail.gmail.com>
	<CAMZCGg9KDi-8s6QNt4u6UtH7jmWq8DR7FGVhrYZ=P83THwsTDw@mail.gmail.com>
	<CAOKDOxLVMJMknKfSDhNMM1vuKke8gzo5pyqH=HvR5n+mDNSkmw@mail.gmail.com>
	<CAMZCGg-oKoxcvXP17ZZEZg=w-3OUNt=sBBKEyKJos9oZyDMZAg@mail.gmail.com>
	<CAOKDOx+nkpTSA48QL00jMbHqf+PNM7FRmU7MAmTLWfJMc078Bw@mail.gmail.com>
	<CAMZCGg8pkeYXrc=LjQUOBSiKErKiHOJu3jWxBoYKEv50qL4PqA@mail.gmail.com>
Message-ID: <CAOKDOx+qeebmFefW_Sahvcunppk5Oi-7y6YZPK18-gtY_ZEbSA@mail.gmail.com>

Sebastien,

I am attaching a pdf containing the screen shots.  Few more points I wanted
to mention.

i)  I didn't install the public client  -- "bkofc-web"  in the wildfly
container which hosts my REST services. I did it for  "bkofc-svc"  client
which is bearer only. I hope that is the correct approach.
ii)  Both keycloak and my application are running on docker containers
locally in my laptop.

Let me know if you need anything else to analyze.

Thanks,
Rajesh


On Mon, Jul 24, 2017 at 9:13 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> yes please
>
> On Mon, Jul 24, 2017 at 4:54 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
> wrote:
>
>> Yes definitely. I did replace it with the actual war name. Let me know if
>> you would like me to paste screen shots of realm configurations, client
>> configurations.
>>
>> Thanks,
>> Rajesh
>>
>> On Mon, Jul 24, 2017 at 8:12 PM, Sebastien Blanc <sblanc at redhat.com>
>> wrote:
>>
>>> Ok and for :
>>> <secure-deployment name="my war file.war">
>>>
>>> Did you replace that with the actual name of your war file ?
>>>
>>> On Mon, Jul 24, 2017 at 4:35 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>> wrote:
>>>
>>>> Hello Sebastien,
>>>>
>>>> I am using 3.1.0.Final build.
>>>>
>>>> Thanks,
>>>> Rajesh
>>>>
>>>> On Mon, Jul 24, 2017 at 7:56 PM, Sebastien Blanc <sblanc at redhat.com>
>>>> wrote:
>>>>
>>>>> Which version of Keycloak are you using ?
>>>>>
>>>>> On Mon, Jul 24, 2017 at 3:15 PM, Rajesh Ghosh <ghosh.rajesh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to secure my REST services using the method described in
>>>>>> the
>>>>>> document --
>>>>>>
>>>>>>
>>>>>> http://blog.keycloak.org/2015/10/getting-started-with-keyclo
>>>>>> ak-securing.html
>>>>>>
>>>>>>
>>>>>> I am securing my war using JBoss subsystem , instead of per-war
>>>>>> option. The
>>>>>> relevant sections from my standalone.xml  are posted below.
>>>>>>
>>>>>>     <extensions>
>>>>>>          ......
>>>>>>         <extension module="org.keycloak.keycloak-adapter-subsystem"/>
>>>>>>     </extensions>
>>>>>>
>>>>>>          <security-domains>
>>>>>>                 .....
>>>>>>                 <security-domain name="keycloak">
>>>>>>                     <authentication>
>>>>>>                         <login-module
>>>>>> code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>>>>>> flag="required"/>
>>>>>>                     </authentication>
>>>>>>                 </security-domain>
>>>>>>             </security-domains>
>>>>>>
>>>>>>         <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>>>>             <secure-deployment name="my war file.war">
>>>>>>                 <realm>bkofc</realm>
>>>>>>                 <resource>bkofc-svc</resource>
>>>>>>
>>>>>> <use-resource-role-mappings>true</use-resource-role-mappings>
>>>>>>                 <bearer-only>true</bearer-only>
>>>>>>                 <auth-server-url>http://192.168.99.100/30001/auth
>>>>>> </auth-server-url>
>>>>>>                 <ssl-required>none</ssl-required>
>>>>>>                 <credential
>>>>>> name="secret">9bcc6d9f-9c72-4b58-b297-79f0f207d9e1</credential>
>>>>>>             </secure-deployment>
>>>>>>         </subsystem>
>>>>>>
>>>>>> I am able to obtain the access token.
>>>>>>
>>>>>> curl -i  curl --data
>>>>>> "grant_type=password&client_id=bkofc-web&username=user&passw
>>>>>> ord=password"
>>>>>> http://192.168.99.100:30001/auth/realms/bkofc/protocol/openi
>>>>>> d-connect/token
>>>>>>
>>>>>> Note:- I have created 2 clients -- i)  bkofc-svc which is bearer
>>>>>> only, for
>>>>>> my REST services  ii) bkofc-web , a public client to simulate UI login
>>>>>>
>>>>>> However when I try to use the access token to invoke a service, I am
>>>>>> getting the error -
>>>>>>
>>>>>> Status: 401
>>>>>>
>>>>>> WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
>>>>>> error_description="Didn't find publicKey for specified kid"
>>>>>>
>>>>>> Please let me know if I am missing something here. I have been
>>>>>> breaking my
>>>>>> head last few days without any luck !  I have also tried rotating the
>>>>>> realm
>>>>>> keys.
>>>>>>
>>>>>> Thanks,
>>>>>> Rajesh
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>