From tdudgeon.ml at gmail.com Sat Aug 1 06:13:20 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sat, 01 Aug 2015 11:13:20 +0100 Subject: [keycloak-user] problems getting started with tomcat In-Reply-To: <55BB585A.7030600@redhat.com> References: <55BB5438.107@gmail.com> <55BB585A.7030600@redhat.com> Message-ID: <55BC9BC0.8020402@gmail.com> https://issues.jboss.org/browse/KEYCLOAK-1724 On 31/07/2015 12:13, Bill Burke wrote: > Sorry, haven't had a chance to look at this. Can you log a JIRA? > > On 7/31/2015 6:55 AM, Tim Dudgeon wrote: >> a couple of weeks back I posted about having problems getting started >> with tomcat, but not had any response. >> The post is here, along with an example: >> http://lists.jboss.org/pipermail/keycloak-user/2015-July/002652.html >> >> I'm still struggling with this, and think I have followed the >> instructions here correctly: >> http://keycloak.github.io/docs/userguide/html/ch08.html#tomcat-adapter >> >> Basically I think I'm having problems with the valve not doing anything. >> I have copied the appropriate keycloak jars to $TOMCAT_HOME/lib and a >> web app with META-INF/context.xml containing this: >> >> >> >> > className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/> >> >> >> and a WEB-INF/web.xml pretty well as described in the docs, but I'm not >> getting any authentication challenge. >> >> Any ideas what's wrong? >> >> Thanks >> Tim >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> From stephen.flynn at jftechnology.com Sat Aug 1 11:19:40 2015 From: stephen.flynn at jftechnology.com (Stephen Flynn) Date: Sat, 1 Aug 2015 16:19:40 +0100 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing Message-ID: <55BCE38C.5090805@jftechnology.com> Hi all, I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. The liquibase db scripts are failing. The particular script that is failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long'. More stack trace below. Any ideas as to why this might be happening ? Is there anything else I can provide to give more insight ? best rgds, Steve F. Environment is... * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final * jdk1.7.0_51 * Oracle 10 + odbcj6.jar (11.2.0.2.0) Liquibase change log from the DB * 1.0.0.Final sthorger at redhat.com META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 00:55:28.95072 1 EXECUTED * 1.1.0.Beta1 sthorger at redhat.com META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 00:55:30.070692 2 EXECUTED * 1.1.0.Final sthorger at redhat.com META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 00:55:27.065618 3 EXECUTED Error message in log... 15:12:31,238 INFO [org.keycloak.services.resources.KeycloakApplication] (ServerService Thread Pool -- 69) Load config from /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json 15:12:34,416 INFO [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 69) Updating database 15:12:35,982 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 69) Change Set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com failed. Error: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) at liquibase.Liquibase.update(Liquibase.java:200) at liquibase.Liquibase.update(Liquibase.java:181) at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) [keycloak-services-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) [keycloak-services-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) [keycloak-services-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) [keycloak-services-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) [keycloak-services-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) [keycloak-services-1.4.0.Final.jar:1.4.0.Final] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_51] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_51] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_51] at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_51] at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) [resteasy-jaxrs-3.0.11.Final.jar:] at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) [resteasy-jaxrs-3.0.11.Final.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) [resteasy-jaxrs-3.0.11.Final.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) [resteasy-jaxrs-3.0.11.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) [resteasy-jaxrs-3.0.11.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-3.0.11.Final.jar:] at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] 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:471) [rt.jar:1.7.0_51] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) ... 44 more Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] ... 46 more -- =================================================== *Stephen Flynn* *Director, JF Technology (UK) Ltd* Cell (UK) : +44 7768 003 882 Phone : +44 20 7833 8346 IM : xmpp:stephen.flynn at jftechnology.com IM : aim:stephen.flynn at jftechnology.com Website : http://www.jftechnology.com Tech support : support at jftechnology.com =================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150801/34c9a8be/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: stephen_flynn.vcf Type: text/x-vcard Size: 233 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150801/34c9a8be/attachment-0001.vcf From tdudgeon.ml at gmail.com Sat Aug 1 17:03:09 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sat, 01 Aug 2015 22:03:09 +0100 Subject: [keycloak-user] common roles within multiple clients Message-ID: <55BD340D.3070701@gmail.com> I have a keycloak realm that contains a number of clients (app1, app2, app3 ...). Those clients share a set of common roles (user, editor, manager ...). Is there a way I can directly assign those roles to the keycloak user so that they apply across all clients? The only approach I can find is to set up each of those roles for every client (e.g. for 5 clients set up 5 sets of identical roles) and then for each client apply the relevant roles to each of the users (e.g. repeat the same process for every user/client combination). Is there a better way? Thanks Tim From tair.sabirgaliev at bee.kz Sat Aug 1 23:31:53 2015 From: tair.sabirgaliev at bee.kz (Tair Sabirgaliev) Date: Sun, 2 Aug 2015 09:31:53 +0600 Subject: [keycloak-user] common roles within multiple clients In-Reply-To: <55BD340D.3070701@gmail.com> References: <55BD340D.3070701@gmail.com> Message-ID: <769126587586734316@unknownmsgid> Why not specify roles at realm level and apply them once for a user? http://keycloak.github.io/docs/userguide/html/roles.html > On 2 ???. 2015 ?., at 3:03, Tim Dudgeon wrote: > > I have a keycloak realm that contains a number of clients (app1, app2, > app3 ...). > Those clients share a set of common roles (user, editor, manager ...). > Is there a way I can directly assign those roles to the keycloak user so > that they apply across all clients? > The only approach I can find is to set up each of those roles for every > client (e.g. for 5 clients set up 5 sets of identical roles) and then > for each client apply the relevant roles to each of the users (e.g. > repeat the same process for every user/client combination). > Is there a better way? > > Thanks > Tim > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From tdudgeon.ml at gmail.com Sun Aug 2 04:04:47 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 02 Aug 2015 09:04:47 +0100 Subject: [keycloak-user] common roles within multiple clients In-Reply-To: <769126587586734316@unknownmsgid> References: <55BD340D.3070701@gmail.com> <769126587586734316@unknownmsgid> Message-ID: <55BDCF1F.4070007@gmail.com> Because that doesn't seem to work. I already tried it. I added a realm role to a user, but it does not allow to authenticate from a client app. In my understanding realm roles are for managing the realm, not for client applications? Tim On 02/08/2015 04:31, Tair Sabirgaliev wrote: > Why not specify roles at realm level and apply them once for a user? > > http://keycloak.github.io/docs/userguide/html/roles.html > > >> On 2 ???. 2015 ?., at 3:03, Tim Dudgeon wrote: >> >> I have a keycloak realm that contains a number of clients (app1, app2, >> app3 ...). >> Those clients share a set of common roles (user, editor, manager ...). >> Is there a way I can directly assign those roles to the keycloak user so >> that they apply across all clients? >> The only approach I can find is to set up each of those roles for every >> client (e.g. for 5 clients set up 5 sets of identical roles) and then >> for each client apply the relevant roles to each of the users (e.g. >> repeat the same process for every user/client combination). >> Is there a better way? >> >> Thanks >> Tim >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user From tdudgeon.ml at gmail.com Sun Aug 2 07:13:27 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 02 Aug 2015 12:13:27 +0100 Subject: [keycloak-user] Using access token Message-ID: <55BDFB57.4020906@gmail.com> This page mentions basics about the access token and how it contains information about the user: http://keycloak.github.io/docs/userguide/html/Overview.html#d4e54 But its a bit vague about how to get access to this information. e.g. in my client app I might want to access the user's email address. Is there documentation on how to do this? Tim From bburke at redhat.com Sun Aug 2 09:08:48 2015 From: bburke at redhat.com (Bill Burke) Date: Sun, 2 Aug 2015 09:08:48 -0400 Subject: [keycloak-user] common roles within multiple clients In-Reply-To: <55BDCF1F.4070007@gmail.com> References: <55BD340D.3070701@gmail.com> <769126587586734316@unknownmsgid> <55BDCF1F.4070007@gmail.com> Message-ID: <55BE1660.30506@redhat.com> Your client adapter config should have: "use-resource-role-mappings" : false, On 8/2/2015 4:04 AM, Tim Dudgeon wrote: > Because that doesn't seem to work. I already tried it. > I added a realm role to a user, but it does not allow to authenticate > from a client app. > In my understanding realm roles are for managing the realm, not for > client applications? > > Tim > > On 02/08/2015 04:31, Tair Sabirgaliev wrote: >> Why not specify roles at realm level and apply them once for a user? >> >> http://keycloak.github.io/docs/userguide/html/roles.html >> >> >>> On 2 ???. 2015 ?., at 3:03, Tim Dudgeon wrote: >>> >>> I have a keycloak realm that contains a number of clients (app1, app2, >>> app3 ...). >>> Those clients share a set of common roles (user, editor, manager ...). >>> Is there a way I can directly assign those roles to the keycloak user so >>> that they apply across all clients? >>> The only approach I can find is to set up each of those roles for every >>> client (e.g. for 5 clients set up 5 sets of identical roles) and then >>> for each client apply the relevant roles to each of the users (e.g. >>> repeat the same process for every user/client combination). >>> Is there a better way? >>> >>> Thanks >>> Tim >>> _______________________________________________ >>> 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Sun Aug 2 09:09:38 2015 From: bburke at redhat.com (Bill Burke) Date: Sun, 2 Aug 2015 09:09:38 -0400 Subject: [keycloak-user] Using access token In-Reply-To: <55BDFB57.4020906@gmail.com> References: <55BDFB57.4020906@gmail.com> Message-ID: <55BE1692.50100@redhat.com> examples/... in the distro is all we got. On 8/2/2015 7:13 AM, Tim Dudgeon wrote: > This page mentions basics about the access token and how it contains > information about the user: > http://keycloak.github.io/docs/userguide/html/Overview.html#d4e54 > But its a bit vague about how to get access to this information. > e.g. in my client app I might want to access the user's email address. > Is there documentation on how to do this? > > Tim > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Sun Aug 2 09:11:10 2015 From: bburke at redhat.com (Bill Burke) Date: Sun, 2 Aug 2015 09:11:10 -0400 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BCE38C.5090805@jftechnology.com> References: <55BCE38C.5090805@jftechnology.com> Message-ID: <55BE16EE.6070006@redhat.com> You probably have to export your database to json and re-import it until we track this down. On 8/1/2015 11:19 AM, Stephen Flynn wrote: > > Hi all, > > I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. > > The liquibase db scripts are failing. The particular script that is > failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused > by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to > java.lang.Long'. More stack trace below. > > Any ideas as to why this might be happening ? Is there anything else I > can provide to give more insight ? > > best rgds, > > Steve F. > > > Environment is... > > * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final > * jdk1.7.0_51 > * Oracle 10 + odbcj6.jar (11.2.0.2.0) > > > Liquibase change log from the DB > > * 1.0.0.Final sthorger at redhat.com > META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 > 00:55:28.95072 1 EXECUTED > * 1.1.0.Beta1 sthorger at redhat.com > META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 > 00:55:30.070692 2 EXECUTED > * 1.1.0.Final sthorger at redhat.com > META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 > 00:55:27.065618 3 EXECUTED > > > Error message in log... > > 15:12:31,238 INFO [org.keycloak.services.resources.KeycloakApplication] > (ServerService Thread Pool -- 69) Load config from > /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json > 15:12:34,416 INFO > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (ServerService Thread Pool -- 69) Updating database > 15:12:35,982 ERROR > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (ServerService Thread Pool -- 69) Change Set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com > failed. Error: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version: > liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception > when updating data from previous version > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) > at > liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) > at > liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) > at > liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) > at liquibase.Liquibase.update(Liquibase.java:200) > at liquibase.Liquibase.update(Liquibase.java:181) > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) > [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) > [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) > [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) > [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > [keycloak-services-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) > [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) > [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > [keycloak-services-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) > [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > [keycloak-services-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > [keycloak-services-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) > [keycloak-services-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) > [keycloak-services-1.4.0.Final.jar:1.4.0.Final] > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > [rt.jar:1.7.0_51] > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > [rt.jar:1.7.0_51] > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > [rt.jar:1.7.0_51] > at > java.lang.reflect.Constructor.newInstance(Constructor.java:526) > [rt.jar:1.7.0_51] > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > [resteasy-jaxrs-3.0.11.Final.jar:] > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > [resteasy-jaxrs-3.0.11.Final.jar:] > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > [resteasy-jaxrs-3.0.11.Final.jar:] > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > [resteasy-jaxrs-3.0.11.Final.jar:] > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > [resteasy-jaxrs-3.0.11.Final.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > [resteasy-jaxrs-3.0.11.Final.jar:] > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) > [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) > [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) > [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] > 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:471) > [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > [rt.jar:1.7.0_51] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_51] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) > [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) > [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) > ... 44 more > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be > cast to java.lang.Long > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) > [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) > [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] > ... 46 more > > -- > =================================================== > > *Stephen Flynn* > > *Director, JF Technology (UK) Ltd* > > Cell (UK) : +44 7768 003 882 > Phone : +44 20 7833 8346 > IM : xmpp:stephen.flynn at jftechnology.com > IM : aim:stephen.flynn at jftechnology.com > Website : http://www.jftechnology.com > Tech support : support at jftechnology.com > > =================================================== > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From tdudgeon.ml at gmail.com Sun Aug 2 12:39:33 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 02 Aug 2015 17:39:33 +0100 Subject: [keycloak-user] common roles within multiple clients In-Reply-To: <55BE1660.30506@redhat.com> References: <55BD340D.3070701@gmail.com> <769126587586734316@unknownmsgid> <55BDCF1F.4070007@gmail.com> <55BE1660.30506@redhat.com> Message-ID: <55BE47C5.6020204@gmail.com> Thanks. That does the job. So its either realm roles or client roles, but there's no option to have the union of both? Tim On 02/08/2015 14:08, Bill Burke wrote: > Your client adapter config should have: > > "use-resource-role-mappings" : false, > > On 8/2/2015 4:04 AM, Tim Dudgeon wrote: >> Because that doesn't seem to work. I already tried it. >> I added a realm role to a user, but it does not allow to authenticate >> from a client app. >> In my understanding realm roles are for managing the realm, not for >> client applications? >> >> Tim >> >> On 02/08/2015 04:31, Tair Sabirgaliev wrote: >>> Why not specify roles at realm level and apply them once for a user? >>> >>> http://keycloak.github.io/docs/userguide/html/roles.html >>> >>> >>>> On 2 ???. 2015 ?., at 3:03, Tim Dudgeon wrote: >>>> >>>> I have a keycloak realm that contains a number of clients (app1, app2, >>>> app3 ...). >>>> Those clients share a set of common roles (user, editor, manager ...). >>>> Is there a way I can directly assign those roles to the keycloak user so >>>> that they apply across all clients? >>>> The only approach I can find is to set up each of those roles for every >>>> client (e.g. for 5 clients set up 5 sets of identical roles) and then >>>> for each client apply the relevant roles to each of the users (e.g. >>>> repeat the same process for every user/client combination). >>>> Is there a better way? >>>> >>>> Thanks >>>> Tim >>>> _______________________________________________ >>>> 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 bburke at redhat.com Sun Aug 2 12:43:42 2015 From: bburke at redhat.com (Bill Burke) Date: Sun, 2 Aug 2015 12:43:42 -0400 Subject: [keycloak-user] common roles within multiple clients In-Reply-To: <55BE47C5.6020204@gmail.com> References: <55BD340D.3070701@gmail.com> <769126587586734316@unknownmsgid> <55BDCF1F.4070007@gmail.com> <55BE1660.30506@redhat.com> <55BE47C5.6020204@gmail.com> Message-ID: <55BE48BE.4070704@redhat.com> Java EE requires a flat role scheme. In this case, what you would have to do is define some client mappers (Role Name Mapper) that maps a role into another role name in the JWT claim. Then in your client keycloak.json file pick either "use-resource-role-mappings" : false or true depending on how you've mapped it. On 8/2/2015 12:39 PM, Tim Dudgeon wrote: > Thanks. That does the job. > So its either realm roles or client roles, but there's no option to have > the union of both? > > Tim > > On 02/08/2015 14:08, Bill Burke wrote: >> Your client adapter config should have: >> >> "use-resource-role-mappings" : false, >> >> On 8/2/2015 4:04 AM, Tim Dudgeon wrote: >>> Because that doesn't seem to work. I already tried it. >>> I added a realm role to a user, but it does not allow to authenticate >>> from a client app. >>> In my understanding realm roles are for managing the realm, not for >>> client applications? >>> >>> Tim >>> >>> On 02/08/2015 04:31, Tair Sabirgaliev wrote: >>>> Why not specify roles at realm level and apply them once for a user? >>>> >>>> http://keycloak.github.io/docs/userguide/html/roles.html >>>> >>>> >>>>> On 2 ???. 2015 ?., at 3:03, Tim Dudgeon wrote: >>>>> >>>>> I have a keycloak realm that contains a number of clients (app1, app2, >>>>> app3 ...). >>>>> Those clients share a set of common roles (user, editor, manager ...). >>>>> Is there a way I can directly assign those roles to the keycloak user so >>>>> that they apply across all clients? >>>>> The only approach I can find is to set up each of those roles for every >>>>> client (e.g. for 5 clients set up 5 sets of identical roles) and then >>>>> for each client apply the relevant roles to each of the users (e.g. >>>>> repeat the same process for every user/client combination). >>>>> Is there a better way? >>>>> >>>>> Thanks >>>>> Tim >>>>> _______________________________________________ >>>>> 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From rajat.nair at hp.com Mon Aug 3 03:12:33 2015 From: rajat.nair at hp.com (Nair, Rajat) Date: Mon, 3 Aug 2015 07:12:33 +0000 Subject: [keycloak-user] Distributed Keycloak user sessions using Infinispan In-Reply-To: <966246176.551354.1438190443054.JavaMail.zimbra@redhat.com> References: <59651412.706872.1438003614393.JavaMail.zimbra@redhat.com> <1045151906.720245.1438004746473.JavaMail.zimbra@redhat.com> <1732913135.720424.1438004774275.JavaMail.zimbra@redhat.com> <1042060711.1068309.1438058940079.JavaMail.zimbra@redhat.com> <966246176.551354.1438190443054.JavaMail.zimbra@redhat.com> Message-ID: Hi, Some more info from log of test-server-110 server (server names are test-server-110 and test-server-111) - Infinispan subsystem initialized logs for sessions cache - [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 39) WFLYCLINF0001: Activating Infinispan subsystem. [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000078: Starting JGroups channel keycloak [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000094: Received new cluster view for channel keycloak: [test-server-111|0] (1) [test-server-111] [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000079: Channel keycloak local address is test-server-111, physical addresses are [XX.XX.XX.XX:7600] [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started sessions cache from keycloak container [org.infinispan.CLUSTER] (remote-thread--p3-t3) ISPN000310: Starting cluster-wide rebalance for cache sessions, topology CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.CLUSTER] (remote-thread--p3-t2) ISPN000336: Finished cluster-wide rebalance for cache sessions, topology id = 1 Session cache details - [org.infinispan.jmx.JmxUtil] (ServerService Thread Pool -- 63) Object name jboss.infinispan:type=Cache,name="sessions(dist_sync)",manager="keycloak",component=Cache already registered [org.infinispan.topology.LocalTopologyManagerImpl] (ServerService Thread Pool -- 63) Node test-server-110 joining cache sessions [org.infinispan.topology.LocalTopologyManagerImpl] (ServerService Thread Pool -- 63) Updating local topology for cache sessions: CacheTopology{id=0, rebalanceId=0, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=null, unionCH=null, actualMembers=[test-server-111]} [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t5) Updating local topology for cache sessions: CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t5) Starting local rebalance for cache sessions, topology = CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t5) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t5) Removing no longer owned entries for cache sessions [org.infinispan.statetransfer.InboundTransferTask] (stateTransferExecutor-thread--p5-t19) Finished receiving state for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions [org.infinispan.statetransfer.StateConsumerImpl] (stateTransferExecutor-thread--p5-t24) Finished receiving of segments for cache sessions for topology 1. [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t10) Updating local topology for cache sessions: CacheTopology{id=2, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, pendingCH=null, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t10) Removing no longer owned entries for cache sessions [org.infinispan.cache.impl.CacheImpl] (ServerService Thread Pool -- 63) Started cache sessions on test-server-110 [org.wildfly.clustering.infinispan.spi.service.CacheBuilder] (ServerService Thread Pool -- 63) sessions keycloak cache started Looks like the servers are talking to each other (setup on unicast) and session cache between the servers are shared, but we still cannot successfully fetch user info when token is generated by one server (test-server-110) and data from another (test-server-111). Any suggestions/debugging approaches appreciated. -- Rajat -----Original Message----- From: Stian Thorgersen [mailto:stian at redhat.com] Sent: 29 July 2015 22:51 To: Nair, Rajat; Marek Posolda Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Distributed Keycloak user sessions using Infinispan I'm away on holiday, Marek can you take a look at this? ----- Original Message ----- > From: "Rajat Nair" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Wednesday, 29 July, 2015 2:56:07 PM > Subject: RE: [keycloak-user] Distributed Keycloak user sessions using > Infinispan > > Follow up to our discussion - > > I upgrade my nodes to Keycloak 1.4 Final. Dropped and re-created > database Postgres database (shared between both the nodes) and tested > distributed user session using following commands - > - Fetch access token using following curl from one server > curl --write-out " %{http_code}" -s --request POST --header "Content-Type: > application/x-www-form-urlencoded; charset=UTF-8" --data > "username=user1 at email.com&password=testpassword@&client_id=admin-client&grant_type=password" > "http://test-server-110:8080/auth/realms/test/protocol/openid-connect/token" > > - Validated the token on different server using > curl --write-out " %{http_code}" -s --request GET --header "Content-Type: > application/json" --header "Authorization: Bearer > [ACCESS_TOKEN_FROM_PREVIOUS_CALL]" > "http://test-server-111:8081/auth/realms/test/protocol/openid-connect/userinfo" > > And we get this - {"error":"invalid_grant","error_description":"Token > invalid"} > No more NPE and internal server error. > > If we use the same token and try to fetch user details on server which > issued the token - we get the correct data. (Note - I have confirmed > that the token has not expired) > > > One thing you can try is to make sure user session replication is > > working > > properly: > > 1. Start two nodes > > 2. Open admin console directly on node 1 - login as admin/admin 3. > > Open admin console directly on node 2 from another machine/browser > > or use incognito mode - login as admin/admin 4. On node 1 go to > > users -> view all > > -> click on admin -> sessions - > > you should see two sessions 5. > > -> On node > > 2 do the same and check you can see two sessions there as well > Now this is where things get strange. I followed the steps described - > used 2 different browsers - and I can see 2 sessions listed! > > Are the process we use to validate the token incorrect? Or is master > console on the web doing something different (like get the data from > Postgres database used by both the nodes). > > -- Rajat > > -----Original Message----- > From: Stian Thorgersen [mailto:stian at redhat.com] > Sent: 28 July 2015 10:19 > To: Nair, Rajat > Cc: keycloak-user at lists.jboss.org > Subject: Re: [keycloak-user] Distributed Keycloak user sessions using > Infinispan > > > > ----- Original Message ----- > > From: "Rajat Nair" > > To: "Stian Thorgersen" > > Cc: keycloak-user at lists.jboss.org > > Sent: Monday, 27 July, 2015 7:33:25 PM > > Subject: RE: [keycloak-user] Distributed Keycloak user sessions > > using Infinispan > > > > > Can you send me your standalone-ha.xml and keycloak-server.json? > > Files attached. The service is started like - > > /opt/jboss/keycloak/bin/standalone.sh -c standalone-ha.xml > > -b=test-server-110 > > -bmanagement=test-server-110 -u 230.0.0.4 > > -Djboss.node.name=test-server-110 > > > > > Also, any chance you can try it out with master? I've been testing > > > with that as we're about to do 1.4 release soon > > Glad to give back to the community. Will build and deploy the master > > on my nodes. Will send findings tomorrow. > > > > Regarding a scenario I described earlier - Case 2 1. Start with 1 > > Node down. We bring it back up. We wait for some time so that > > Infinispan can sync. > > 2. Bring down other node. > > 3. Try to get user info using existing token. > > > > Is this a valid use-case? > > Yes - I've tried the same use-case and it works fine every time. One > caveat is that access token can expire, but in this case you should > get a 403 returned, not a NPE exception and 500. > > One thing you can try is to make sure user session replication is > working > properly: > > 1. Start two nodes > 2. Open admin console directly on node 1 - login as admin/admin 3. > Open admin console directly on node 2 from another machine/browser or > use incognito mode - login as admin/admin 4. On node 1 go to users -> > view all -> click on admin -> sessions - you should see two sessions > 5. On node 2 do the same and check you can see two sessions there as > well > > > > > -- Rajat > > > > -----Original Message----- > > From: Stian Thorgersen [mailto:stian at redhat.com] > > Sent: 27 July 2015 19:16 > > To: Nair, Rajat > > Cc: keycloak-user at lists.jboss.org > > Subject: Re: [keycloak-user] Distributed Keycloak user sessions > > using Infinispan > > > > Also, any chance you can try it out with master? I've been testing > > with that as we're about to do 1.4 release soon > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" > > > To: "Rajat Nair" > > > Cc: keycloak-user at lists.jboss.org > > > Sent: Monday, 27 July, 2015 3:45:46 PM > > > Subject: Re: [keycloak-user] Distributed Keycloak user sessions > > > using Infinispan > > > > > > Can you send me your standalone-ha.xml and keycloak-server.json? > > > > > > ----- Original Message ----- > > > > From: "Rajat Nair" > > > > To: "Stian Thorgersen" > > > > Cc: keycloak-user at lists.jboss.org > > > > Sent: Monday, 27 July, 2015 3:41:36 PM > > > > Subject: RE: [keycloak-user] Distributed Keycloak user sessions > > > > using Infinispan > > > > > > > > > Do you have both nodes fully up and running before you kill one node? > > > > Yes. > > > > This is what we tried - > > > > Case 1 > > > > 1. Two node cluster (both running Keycloak engines) - both up > > > > and running. > > > > Configured load balancing using mod_cluster. > > > > 2. Login and get token. > > > > 3. Bring down one node. > > > > 4. Get user info using existing token. This is when we get NPE. > > > > > > > > Case 2 > > > > 1. Start with 1 Node down. We bring it back up. We wait for some > > > > time so that Infinispan can sync. > > > > 2. Bring down other node. > > > > 3. Try to get user info using existing token. Again we see NPE. > > > > > > > > >It's a bug - if session is expired it should return an error > > > > >message, not a NPE (see > > > > >https://issues.jboss.org/browse/KEYCLOAK-1710) > > > > Thanks for tracking this. > > > > > > > > -- Rajat > > > > > > > > ----- Original Message ----- > > > > > From: "Rajat Nair" > > > > > To: "Stian Thorgersen" > > > > > Cc: keycloak-user at lists.jboss.org > > > > > Sent: Monday, 27 July, 2015 3:20:27 PM > > > > > Subject: RE: [keycloak-user] Distributed Keycloak user > > > > > sessions using Infinispan > > > > > > > > > > Thanks for quick reply Stian. > > > > > > > > > > > What version? > > > > > We are using Keycloak 1.3.1 Final. > > > > > > > > > > > Did you remember to change userSessions provider to > > > > > > infinispan in keycloak-server.json? > > > > > Yes. We got following in keycloak-server.json - > > > > > "userSessions": { > > > > > "provider": "infinispan" > > > > > } > > > > > > > > > > > Firstly owners="2" should work fine as long as only one node > > > > > > dies and the other remains active. Secondly it should return > > > > > > a NPE, but an error if user session is not found. > > > > > Could you elaborate on your 2nd point? > > > > > > > > Do you have both nodes fully up and running before you kill one node? > > > > > > > > It's a bug - if session is expired it should return an error > > > > message, not a NPE (see > > > > https://issues.jboss.org/browse/KEYCLOAK-1710) > > > > > > > > > > > > > > -- Rajat > > > > > > > > > > -----Original Message----- > > > > > From: Stian Thorgersen [mailto:stian at redhat.com] > > > > > Sent: 27 July 2015 18:07 > > > > > To: Nair, Rajat > > > > > Cc: keycloak-user at lists.jboss.org > > > > > Subject: Re: [keycloak-user] Distributed Keycloak user > > > > > sessions using Infinispan > > > > > > > > > > Did you remember to change userSessions provider to infinispan > > > > > in keycloak-server.json? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Stian Thorgersen" > > > > > > To: "Rajat Nair" > > > > > > Cc: keycloak-user at lists.jboss.org > > > > > > Sent: Monday, 27 July, 2015 2:24:17 PM > > > > > > Subject: Re: [keycloak-user] Distributed Keycloak user > > > > > > sessions using Infinispan > > > > > > > > > > > > What version? > > > > > > > > > > > > Firstly owners="2" should work fine as long as only one node > > > > > > dies and the other remains active. Secondly it should return > > > > > > a NPE, but an error if user session is not found. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajat Nair" > > > > > > > To: keycloak-user at lists.jboss.org > > > > > > > Sent: Monday, 27 July, 2015 2:03:47 PM > > > > > > > Subject: [keycloak-user] Distributed Keycloak user > > > > > > > sessions using Infinispan > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I?m in the process of setting up distributed user sessions > > > > > > > using Infinispan on my Keycloak cluster. This is the > > > > > > > configuration I use ? > > > > > > > > > > > > > > > > > > > > jndi-name="java:jboss/infinispan/Keycloak"> > > > > > > > lock-timeout="60000"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > owners="2"/> > > > > > > > > > > > > > > > > > > > > owners="1"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And in server.logs, I can see my servers communicate ? > > > > > > > > > > > > > > 2015-07-27 10:27:24,662 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t7) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > users, topology CacheTopology{id=57, rebalanceId=17, > > > > > > > currentCH=ReplicatedConsistentHash{ns > > > > > > > = > > > > > > > 60, owners = (1)[test-server-110: 60]}, > > > > > > > pendingCH=ReplicatedConsistentHash{ns = 60, owners = > > > > > > > (2)[test-server-110: > > > > > > > 30, test-server-111: 30]}, unionCH=null, > > > > > > > actualMembers=[test-server-110, test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t10) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > realms, topology CacheTopology{id=57, rebalanceId=17, > > > > > > > currentCH=ReplicatedConsistentHash{ns > > > > > > > = > > > > > > > 60, owners = (1)[test-server-110: 60]}, > > > > > > > pendingCH=ReplicatedConsistentHash{ns = 60, owners = > > > > > > > (2)[test-server-110: > > > > > > > 30, test-server-111: 30]}, unionCH=null, > > > > > > > actualMembers=[test-server-110, test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t8) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > loginFailures, topology CacheTopology{id=57, > > > > > > > rebalanceId=17, currentCH=DefaultConsistentHash{ns=80, > > > > > > > owners = > > > > > > > (1)[test-server-110: > > > > > > > 80+0]}, > > > > > > > pendingCH=DefaultConsistentHash{ns=80, owners = > > > > > > > (2)[test-server-110: > > > > > > > 40+0, > > > > > > > test-server-111: 40+0]}, unionCH=null, > > > > > > > actualMembers=[test-server-110, test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,669 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t9) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > sessions, topology CacheTopology{id=56, rebalanceId=17, > > > > > > > currentCH=DefaultConsistentHash{ns=80, > > > > > > > owners = (1)[test-server-110: 80+0]}, > > > > > > > pendingCH=DefaultConsistentHash{ns=80, > > > > > > > owners = (2)[test-server-110: 40+0, test-server-111: > > > > > > > 40+0]}, unionCH=null, actualMembers=[test-server-110, > > > > > > > test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,808 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t9) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > loginFailures, topology id = 57 > > > > > > > > > > > > > > 2015-07-27 10:27:24,810 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t12) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > sessions, topology id = 56 > > > > > > > > > > > > > > 2015-07-27 10:27:24,988 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t12) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > realms, topology id = > > > > > > > 57 > > > > > > > > > > > > > > 2015-07-27 10:27:25,530 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t8) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > users, topology id = > > > > > > > 57 > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can successfully login, get a token and fetch user > > > > > > > details with this token. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem is, if one of the nodes on the cluster goes down > > > > > > > and if we try to reuse a token which was already issued > > > > > > > (so workflow is ? user logins in, get token, (a node in > > > > > > > the cluster goes down) and then fetch user details using > > > > > > > token) ? we see an internal server exception. From the > > > > > > > logs ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2015-07-27 10:24:25,714 ERROR [io.undertow.request] > > > > > > > (default > > > > > > > task-1) > > > > > > > UT005023: Exception handling request to > > > > > > > /auth/realms/scaletest/protocol/openid-connect/userinfo: > > > > > > > java.lang.RuntimeException: request path: > > > > > > > /auth/realms/scaletest/protocol/openid-connect/userinfo > > > > > > > > > > > > > > at > > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > KeycloakSessionServletFilter.java:54) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. > > > > > > > java > > > > > > > :6 > > > > > > > 0) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > FilterHandler.java:132) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler.handleRequest(F > > > > > > > il > > > > > > > te > > > > > > > rHan > > > > > > > dl > > > > > > > er.java:85) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.ServletSecurityRoleH > > > > > > > an > > > > > > > dl > > > > > > > er.h > > > > > > > an > > > > > > > dleRequest(ServletSecurityRoleHandler.java:62) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletDispatchingHandler.han > > > > > > > dl > > > > > > > eR > > > > > > > eque > > > > > > > st > > > > > > > (ServletDispatchingHandler.java:36) > > > > > > > > > > > > > > at > > > > > > > org.wildfly.extension.undertow.security.SecurityContextAss > > > > > > > oc > > > > > > > ia > > > > > > > tion > > > > > > > Ha > > > > > > > ndler.handleRequest(SecurityContextAssociationHandler.java > > > > > > > :7 > > > > > > > 8) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.SSLInformationAssoci > > > > > > > at > > > > > > > io > > > > > > > nHan > > > > > > > dl > > > > > > > er.handleRequest(SSLInformationAssociationHandler.java:131 > > > > > > > ) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.ServletAuthenticatio > > > > > > > nC > > > > > > > al > > > > > > > lHan > > > > > > > dl > > > > > > > er.handleRequest(ServletAuthenticationCallHandler.java:57) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.AbstractConfidentialityHandl > > > > > > > er > > > > > > > .h > > > > > > > andl > > > > > > > eR > > > > > > > equest(AbstractConfidentialityHandler.java:46) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.ServletConfidentiali > > > > > > > ty > > > > > > > Co > > > > > > > nstr > > > > > > > ai > > > > > > > ntHandler.handleRequest(ServletConfidentialityConstraintHa > > > > > > > nd > > > > > > > le > > > > > > > r.ja > > > > > > > va > > > > > > > :64) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.AuthenticationMechanismsHandler. > > > > > > > hand > > > > > > > le > > > > > > > Request(AuthenticationMechanismsHandler.java:58) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.CachedAuthenticatedS > > > > > > > es > > > > > > > si > > > > > > > onHa > > > > > > > nd > > > > > > > ler.handleRequest(CachedAuthenticatedSessionHandler.java:7 > > > > > > > 2) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.NotificationReceiverHandler. > > > > > > > ha > > > > > > > nd > > > > > > > leRe > > > > > > > qu > > > > > > > est(NotificationReceiverHandler.java:50) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.SecurityInitialHandler.handl > > > > > > > eR > > > > > > > eq > > > > > > > uest > > > > > > > (S > > > > > > > ecurityInitialHandler.java:76) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler. > > > > > > > ha > > > > > > > ndleRequest(JACCContextIdHandler.java:61) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.MetricsHandler.handleRequest(M > > > > > > > et > > > > > > > ri > > > > > > > csHa > > > > > > > nd > > > > > > > ler.java:62) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.core.MetricsChainHandler.handleRequest > > > > > > > (M > > > > > > > et > > > > > > > rics > > > > > > > Ch > > > > > > > ainHandler.java:59) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.handleF > > > > > > > ir > > > > > > > st > > > > > > > Requ > > > > > > > es > > > > > > > t(ServletInitialHandler.java:274) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.dispatc > > > > > > > hR > > > > > > > eq > > > > > > > uest > > > > > > > (S > > > > > > > ervletInitialHandler.java:253) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.access$ > > > > > > > 00 > > > > > > > 0( > > > > > > > Serv > > > > > > > le > > > > > > > tInitialHandler.java:80) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler$1.handl > > > > > > > eR > > > > > > > eq > > > > > > > uest > > > > > > > (S > > > > > > > ervletInitialHandler.java:172) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.Connectors.executeRootHandler(Connectors. > > > > > > > ja > > > > > > > va:1 > > > > > > > 99 > > > > > > > ) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java: > > > > > > > 774) > > > > > > > > > > > > > > at > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at java.lang.Thread.run(Unknown Source) > > > > > > > > > > > > > > Caused by: org.jboss.resteasy.spi.UnhandledException: > > > > > > > java.lang.NullPointerException > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ExceptionHandler.handleApplication > > > > > > > Ex > > > > > > > ce > > > > > > > ptio > > > > > > > n( > > > > > > > ExceptionHandler.java:76) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ExceptionHandler.handleException(E > > > > > > > xc > > > > > > > ep > > > > > > > tion > > > > > > > Ha > > > > > > > ndler.java:212) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.writeExcepti > > > > > > > on > > > > > > > (S > > > > > > > ynch > > > > > > > ro > > > > > > > nousDispatcher.java:149) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch > > > > > > > ro > > > > > > > no > > > > > > > usDi > > > > > > > sp > > > > > > > atcher.java:372) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch > > > > > > > ro > > > > > > > no > > > > > > > usDi > > > > > > > sp > > > > > > > atcher.java:179) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainer > > > > > > > Di > > > > > > > sp > > > > > > > atch > > > > > > > er > > > > > > > .service(ServletContainerDispatcher.java:220) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispa > > > > > > > tc > > > > > > > he > > > > > > > r.se > > > > > > > rv > > > > > > > ice(HttpServletDispatcher.java:56) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispa > > > > > > > tc > > > > > > > he > > > > > > > r.se > > > > > > > rv > > > > > > > ice(HttpServletDispatcher.java:51) > > > > > > > > > > > > > > at > > > > > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:79 > > > > > > > 0) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletHandler.handleRequest( > > > > > > > Se > > > > > > > rv > > > > > > > letH > > > > > > > an > > > > > > > dler.java:86) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > FilterHandler.java:130) > > > > > > > > > > > > > > at > > > > > > > org.keycloak.services.filters.ClientConnectionFilter.doFil > > > > > > > te > > > > > > > r( > > > > > > > Clie > > > > > > > nt > > > > > > > ConnectionFilter.java:41) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. > > > > > > > java > > > > > > > :6 > > > > > > > 0) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > FilterHandler.java:132) > > > > > > > > > > > > > > at > > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > KeycloakSessionServletFilter.java:40) > > > > > > > > > > > > > > ... 31 more > > > > > > > > > > > > > > Caused by: java.lang.NullPointerException > > > > > > > > > > > > > > at > > > > > > > org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu > > > > > > > eU > > > > > > > se > > > > > > > rInf > > > > > > > o( > > > > > > > UserInfoEndpoint.java:128) > > > > > > > > > > > > > > at > > > > > > > org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu > > > > > > > eU > > > > > > > se > > > > > > > rInf > > > > > > > oG > > > > > > > et(UserInfoEndpoint.java:101) > > > > > > > > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > > > > Method) > > > > > > > > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at java.lang.reflect.Method.invoke(Unknown Source) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodIn > > > > > > > je > > > > > > > ct > > > > > > > orIm > > > > > > > pl > > > > > > > .java:137) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarg > > > > > > > et > > > > > > > (R > > > > > > > esou > > > > > > > rc > > > > > > > eMethodInvoker.java:296) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resou > > > > > > > rc > > > > > > > eM > > > > > > > etho > > > > > > > dI > > > > > > > nvoker.java:250) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar > > > > > > > ge > > > > > > > tO > > > > > > > bjec > > > > > > > t( > > > > > > > ResourceLocatorInvoker.java:140) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso > > > > > > > ur > > > > > > > ce > > > > > > > Loca > > > > > > > to > > > > > > > rInvoker.java:109) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar > > > > > > > ge > > > > > > > tO > > > > > > > bjec > > > > > > > t( > > > > > > > ResourceLocatorInvoker.java:135) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso > > > > > > > ur > > > > > > > ce > > > > > > > Loca > > > > > > > to > > > > > > > rInvoker.java:103) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch > > > > > > > ro > > > > > > > no > > > > > > > usDi > > > > > > > sp > > > > > > > atcher.java:356) > > > > > > > > > > > > > > ... 42 more > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The user guide says ? > > > > > > > > > > > > > > If you need to prevent node failures from requiring users > > > > > > > to log in again, set the owners attribute to 2 or more for > > > > > > > the sessions cache > > > > > > > > > > > > > > > > > > > > > > > > > > > > Questions - > > > > > > > > > > > > > > 1. Have we configured Infinispan incorrectly? We don?t > > > > > > > want the users to login again if any of the nodes in the > > > > > > > cluster go down. > > > > > > > > > > > > > > 2. Will changing distributed-cache to replicated-cache > > > > > > > help in this scenario? > > > > > > > > > > > > > > 3. Any way we can see the contents of the cache? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Rajat > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Aug 3 05:27:18 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 03 Aug 2015 11:27:18 +0200 Subject: [keycloak-user] LDAP with Kerberos, login with different user In-Reply-To: <02df0f9e-faae-4124-a5f7-c31cbc2dde13@me.com> References: <02df0f9e-faae-4124-a5f7-c31cbc2dde13@me.com> Message-ID: <55BF33F6.5030501@redhat.com> Yes, feel free to create JIRA with the link to this discussion. Marek On 28.7.2015 08:03, Michael Gerber wrote: > Should I create a Jira issue for that task? > Or will you anyway implement something in this direction? > > Am 24. Juli 2015 um 09:57 schrieb Stian Thorgersen : > >> >> >> ----- Original Message ----- >>> From: "Marek Posolda" > >>> To: "Raghu Prabhala" >> >, "Bill Burke" >> > >>> Cc: "Stian Thorgersen" >, >>> keycloak-user at lists.jboss.org >>> Sent: Friday, 24 July, 2015 9:49:45 AM >>> Subject: Re: [keycloak-user] LDAP with Kerberos, login with >>> different user >>> >>> Support for prompt=select_account will be cool. Another suggestion for >>> adding query parameter for skip some mechanisms (like >>> skipAuthMechanism=cookie,kerberos ) might be good too. >> >> That'll only make sense if we also add support to allow multiple >> accounts, which could be fairly easy on the server-side, but much >> harder to support in adapters. >> >>> >>> Not sure if we need to support both, but IMO it will be good to have >>> solution not tightly coupled to Kerberos. I can imagine similar >>> situation with other login mechanisms as well. For example with >>> authenticating users by certificate, admin may also want to skip >>> automatic login with the certificate from his browser and instead login >>> with username/password form. >>> >>> Marek >>> >>> On 23.7.2015 17:43, Raghu Prabhala wrote: >>> > The select account prompt wouldn't work for us as some of our >>> applications >>> > require that the user login only by entering userid/pw but your other >>> > suggestion might work as long as we do the Kerberos authentication >>> using >>> > Id/ow >>> > >>> > Sent from my iPhone >>> > >>> >> On Jul 23, 2015, at 11:28 AM, Bill Burke >> > wrote: >>> >> >>> >> All this interaction is defined by the SAML and OIDC specifications. >>> >> Logout redirects you back to the application and its up to the >>> >> application what to do next. We could add a query param that if it is >>> >> set, to not do kerberos. This could be in addition to the "login >>> >> automatically" flag. >>> >> >>> >> >>> >>> On 7/23/2015 11:14 AM, Raghu Prabhala wrote: >>> >>> Why can't we have two separate authentication mechanisms - one >>> IWA, in >>> >>> which case the user is logged in automatically and on logout he >>> is taken >>> >>> to a login page where a diff userid can be entered and two, a >>> login page >>> >>> that allows userid/password? That would address our use case. >>> >>> >>> >>> >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> >>>> On Jul 23, 2015, at 10:50 AM, Marek Posolda >>> > wrote: >>> >>>> >>> >>>> Maybe it can be configurable for the kerberos mechanism? Just >>> the flag >>> >>>> "login automatically" . If it's off, another confirmation >>> screen for the >>> >>>> user will be displayed? >>> >>>> >>> >>>> Marek >>> >>>> >>> >>>>> On 23.7.2015 16:36, Stian Thorgersen wrote: >>> >>>>> "Is this you?" >>> >>>>> >>> >>>>> ----- Original Message ----- >>> >>>>>> From: "Bill Burke" > >>> >>>>>> To: keycloak-user at lists.jboss.org >>> >>> >>>>>> Sent: Thursday, 23 July, 2015 4:02:53 PM >>> >>>>>> Subject: Re: [keycloak-user] LDAP with Kerberos, login with >>> different >>> >>>>>> user >>> >>>>>> >>> >>>>>> With the new flows, we could detect a kerberos login then ask >>> if they >>> >>>>>> want to login as that user or another. >>> >>>>>> >>> >>>>>>> On 7/23/2015 2:26 AM, Marek Posolda wrote: >>> >>>>>>> Do you want that for normal users or just for admin users? Just >>> >>>>>>> trying >>> >>>>>>> to understand the usecase. Because AFAIK the point of >>> kerberos is, >>> >>>>>>> that >>> >>>>>>> you login into the desktop and then you're automatically >>> logged into >>> >>>>>>> integrated web applications without need to deal with any login >>> >>>>>>> screens >>> >>>>>>> and username/password. When user has just one keycloak account >>> >>>>>>> corresponding to his kerberos ticket, then why he need to >>> login as >>> >>>>>>> different user? >>> >>>>>>> >>> >>>>>>> I can understand the usecase for admin, when you want to >>> login as >>> >>>>>>> different user for testing purpose etc. For this, isn't it >>> possible >>> >>>>>>> in >>> >>>>>>> windows to do something like "kdestroy" to be able to login >>> without >>> >>>>>>> kerberos? >>> >>>>>>> >>> >>>>>>> Marek >>> >>>>>>> >>> >>>>>>>> On 23.7.2015 07:44, Michael Gerber wrote: >>> >>>>>>>> Isn't it possible to create a cookie or add an url >>> parameter after >>> >>>>>>>> the >>> >>>>>>>> logout, so the user is not logged in automatically? >>> >>>>>>>> >>> >>>>>>>> It's crucial for us to be able to log in as a different user, >>> >>>>>>>> otherwise we can not use kerberos at all :( >>> >>>>>>>> >>> >>>>>>>> Michael >>> >>>>>>>> >>> >>>>>>>>> Am 22. Juli 2015 um 23:06 schrieb Marek Posolda >>> >>>>>>>>> >: >>> >>>>>>>>> >>> >>>>>>>>> I don't think it's doable. Kerberos is kind of desktop >>> login and >>> >>>>>>>>> logout from the web application won't destroy the kerberos >>> ticket - >>> >>>>>>>>> similarly like it can't logout your laptop/desktop >>> session. So when >>> >>>>>>>>> you visit the secured application next time, you are >>> automatically >>> >>>>>>>>> logged into Keycloak through SPNEGO due to the Kerberos >>> ticket. >>> >>>>>>>>> >>> >>>>>>>>> Hence you need to remove kerberos ticket manually (For example >>> >>>>>>>>> "kdestroy" works on Linux, but I guess you're using Windows + >>> >>>>>>>>> ActiveDirectory? ) and then you will be able to see >>> keycloak login >>> >>>>>>>>> screen and login as different user. >>> >>>>>>>>> >>> >>>>>>>>> Marek >>> >>>>>>>>> >>> >>>>>>>>>> On 22.7.2015 15:38, Michael Gerber wrote: >>> >>>>>>>>>> Hi all, >>> >>>>>>>>>> >>> >>>>>>>>>> I use LDAP with Kerberos and would like to logout and >>> login again >>> >>>>>>>>>> with a different user (no kerberos login, just keycloak >>> username >>> >>>>>>>>>> and >>> >>>>>>>>>> password dialog). >>> >>>>>>>>>> Is that possible? >>> >>>>>>>>>> >>> >>>>>>>>>> cheers >>> >>>>>>>>>> Michael >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> _______________________________________________ >>> >>>>>>>>>> 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 >>> >>>>>> -- >>> >>>>>> Bill Burke >>> >>>>>> JBoss, a division of Red Hat >>> >>>>>> http://bill.burkecentral.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 >>> >> -- >>> >> Bill Burke >>> >> JBoss, a division of Red Hat >>> >> http://bill.burkecentral.com >>> >>> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/5291e049/attachment-0001.html From paulojeronimo at gmail.com Mon Aug 3 07:24:34 2015 From: paulojeronimo at gmail.com (=?UTF-8?Q?Paulo_Jer=C3=B4nimo?=) Date: Mon, 3 Aug 2015 08:24:34 -0300 Subject: [keycloak-user] JBoss BPM Suite integration with Keycloak Message-ID: Hello! I need to make the Business Center and the Dashbuilder (JBoss BPM Suite) to authenticate using a realm created in Keycloak. I have all the necessary settings. My steps can be reproduced with an script. The Keycloak 1.4.0 examples are successfully executed in this instance configured JBoss BPM Suite. It is configured with patches for JBoss EAP 6.4.2 and, also, with patches for JBoss BPM Suite 6.1.1. The datasources are configured for a Oracle instance. I exported the realm for myapp-realm.json file and I'm starting the JBoss BPM Suite. I can log into Dashbuilder but in the Central Business I am getting the following error: https://github.com/paulojeronimo/gerador-jboss-bpmsuite-keycloak/blob/master/problemas/01/a.log My JBoss BPM Suite integration project with Keycloak is public and available: https://github.com/paulojeronimo/gerador-jboss-bpmsuite-keycloak Can help me solve this problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/bdf5c802/attachment.html From mposolda at redhat.com Mon Aug 3 08:00:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 03 Aug 2015 14:00:17 +0200 Subject: [keycloak-user] Having trouble with LDAP attribute mapping in 1.3.1 In-Reply-To: References: <5583DDCA.10607@redhat.com>

<55840FFF.7080208@redhat.com> <55842599.8000301@redhat.com> <5588118F.6090307@redhat.com>

Message-ID: <55BF57D1.2070701@redhat.com> Hi Kevin, Great to hear that things work well for you. Were you able to find the "mappers" page in admin console after all? Thanks, Marek On 31.7.2015 12:46, Kevin Thorpe wrote: > Hi Marek, thank you and your colleagues very much for working on the > LDAP mapping for us. > Works like a charm. This was holding us up so we're very grateful that > it was accomplished > so quickly. > > *Kevin Thorpe > * > CTO > > > > www.p-i.net | @PI_150 > > M: +44 (0)7425 160 368 | T: +44 (0)203 005 6750 | F: +44(0)207 730 2635 > 150 Buckingham Palace Road, London, SW1W 9TR, UK > > ** > _____________________________ > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. If you > are not the intended recipient you are notified that disclosing, > copying, distributing or taking any action in reliance on the contents > of this information is strictly prohibited. > > *"SAVE PAPER - THINK BEFORE YOU PRINT!" * > > > On 31 July 2015 at 10:23, Kevin Thorpe > wrote: > > Sorry to bother you but where has the user federation mapper > option gone in 1.4.0.final? > > IIRC there was a page user federation > my_ldap > mapper to map > LDAP attributes to > keycloak user attributes. I can't find it now at all. > > *Kevin Thorpe > * > CTO > > > > www.p-i.net | @PI_150 > > > M: +44 (0)7425 160 368 | T: +44 (0)203 005 6750 | F: +44(0)207 730 > 2635 > 150 Buckingham Palace Road, London, SW1W 9TR, UK > > ** > _____________________________ > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom > they are addressed. If you have received this email in error > please notify the system manager. This message contains > confidential information and is intended only for the individual > named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the > sender immediately by e-mail if you have received this e-mail by > mistake and delete this e-mail from your system. If you are not > the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of > this information is strictly prohibited. > > *"SAVE PAPER - THINK BEFORE YOU PRINT!" * > > > On 22 June 2015 at 14:49, Kevin Thorpe > wrote: > > Brilliant, I'm waiting for it so yes I'd like to try as soon > as available. > > > *Kevin Thorpe > * > CTO > > > > www.p-i.net | @PI_150 > > > M: +44 (0)7425 160 368 | T: +44 (0)203 005 6750 | F: +44(0)207 > 730 2635 > 150 Buckingham Palace Road, London, SW1W 9TR, UK > > ** > _____________________________ > > This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in > error please notify the system manager. This message contains > confidential information and is intended only for the > individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your > system. If you are not the intended recipient you are notified > that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly > prohibited. > > *"SAVE PAPER - THINK BEFORE YOU PRINT!" * > > > On 22 June 2015 at 14:45, Marek Posolda > wrote: > > Thanks for the info Kevin. I've also created > https://issues.jboss.org/browse/KEYCLOAK-1490 for the sync > issue. Will try to address both issues for the next > release. Will let you know once it's fixed in master if > you want to try it before the next release is out. > > Marek > > Dne 19.6.2015 v 17:45 Kevin Thorpe napsal(a): >> I agree with you on the delimiter option. That wouldn't >> require any database changes. For the small >> attribute applications I could wrap into a delimited >> string but we have some others for fine grained >> permissions/roles that can be dozens of already delimited >> strings. Roles in particular are: >> application|role|path/that/role/represents >> I know it's very common to have multi-attributes in LDAP >> anyway so this will affect others. >> >> JIRA: https://issues.jboss.org/browse/KEYCLOAK-1487 >> >> >> *Kevin Thorpe >> * >> CTO >> >> >> >> www.p-i.net | @PI_150 >> >> >> M: +44 (0)7425 160 368 | T: +44 (0)203 005 6750 | F: >> +44(0)207 730 2635 >> 150 Buckingham Palace Road, London, SW1W 9TR, UK >> >> ** >> _____________________________ >> >> This email and any files transmitted with it are >> confidential and intended solely for the use of the >> individual or entity to whom they are addressed. If you >> have received this email in error please notify the >> system manager. This message contains confidential >> information and is intended only for the individual >> named. If you are not the named addressee you should not >> disseminate, distribute or copy this e-mail. Please >> notify the sender immediately by e-mail if you have >> received this e-mail by mistake and delete this e-mail >> from your system. If you are not the intended recipient >> you are notified that disclosing, copying, distributing >> or taking any action in reliance on the contents of this >> information is strictly prohibited. >> >> *"SAVE PAPER - THINK BEFORE YOU PRINT!" * >> >> >> On 19 June 2015 at 15:22, Marek Posolda >> > wrote: >> >> Ouch, this is a bug:-( >> >> Feel free to create JIRA. >> >> The UserModel in Keycloak DB has each attribute >> modelled as one string value. But I think I can >> address it with the usage of some delimiter and then >> for access token has the protocol mapper, which will >> handle it. >> >> So for example if your LDAP user has 3 values of >> attribute "applications" with values "finance", >> "sales", "development", the attribute on the Keycloak >> UserModel will have value like >> "finance###sales###development" (The sequence ### >> will be used as delimiter), but for the access token >> it will be divided again. So in your application, you >> will have possibility to have something like: >> >> Set applications = >> accessToken.getOtherClaims().getAttribute("applications"); >> >> which will return set with 3 values "finance", >> "sales", "development". >> >> Marek >> >> >> On 19.6.2015 15:22, Kevin Thorpe wrote: >>> Ok, I think I understand. I tried 'sync all users' >>> and got an error. Is this because applications is a >>> multiple >>> attribute? Obviously I will probably have access to >>> more than one application. In the meantime I'll try >>> a brand >>> new user and see if that works. >>> >>> Log shows: >>> >>> 2015-06-19 14:19:26,361 INFO >>> [org.keycloak.federation.ldap.LDAPFederationProviderFactory] >>> (default task-2) Sync all users from LDAP to local >>> store: realm: master, federation provider: PI >>> ordinary users >>> 2015-06-19 14:19:26,611 ERROR [io.undertow.request] >>> (default task-2) UT005023: Exception handling >>> request to >>> /auth/admin/realms/master/user-federation/instances/141db483-1f5c-412f-acbb-0ea642015798/sync: >>> java.lang.RuntimeException: request path: >>> /auth/admin/realms/master/user-federation/instances/141db483-1f5c-412f-acbb-0ea642015798/sync >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>> at >>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) >>> at >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) >>> 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:58) >>> at >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) >>> at >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> at >>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) >>> 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:274) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) >>> at >>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) >>> 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: >>> org.jboss.resteasy.spi.UnhandledException: >>> java.lang.ClassCastException: java.util.TreeSet >>> cannot be cast to java.lang.String >>> at >>> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) >>> at >>> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) >>> 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:86) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) >>> at >>> org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) >>> at >>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) >>> ... 29 more >>> Caused by: java.lang.ClassCastException: >>> java.util.TreeSet cannot be cast to java.lang.String >>> at >>> org.keycloak.federation.ldap.mappers.UserAttributeLDAPFederationMapper.onImportUserFromLDAP(UserAttributeLDAPFederationMapper.java:60) >>> at >>> org.keycloak.federation.ldap.LDAPFederationProvider.importLDAPUsers(LDAPFederationProvider.java:404) >>> at >>> org.keycloak.federation.ldap.LDAPFederationProviderFactory.importLdapUsers(LDAPFederationProviderFactory.java:269) >>> at >>> org.keycloak.federation.ldap.LDAPFederationProviderFactory$1.run(LDAPFederationProviderFactory.java:223) >>> at >>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:241) >>> at >>> org.keycloak.federation.ldap.LDAPFederationProviderFactory.syncImpl(LDAPFederationProviderFactory.java:219) >>> at >>> org.keycloak.federation.ldap.LDAPFederationProviderFactory.syncAllUsers(LDAPFederationProviderFactory.java:177) >>> at >>> org.keycloak.services.managers.UsersSyncManager.syncAllUsers(UsersSyncManager.java:50) >>> at >>> org.keycloak.services.resources.admin.UserFederationProviderResource.syncUsers(UserFederationProviderResource.java:144) >>> 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:497) >>> at >>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) >>> ... 40 more >>> >>> >>> *Kevin Thorpe >>> * >>> CTO >>> >>> >>> >>> www.p-i.net | @PI_150 >>> >>> >>> M: +44 (0)7425 160 368 | T: +44 (0)203 005 6750 | F: >>> +44(0)207 730 2635 >>> 150 Buckingham Palace Road, London, SW1W 9TR, UK >>> >>> ** >>> _____________________________ >>> >>> This email and any files transmitted with it are >>> confidential and intended solely for the use of the >>> individual or entity to whom they are addressed. If >>> you have received this email in error please notify >>> the system manager. This message contains >>> confidential information and is intended only for >>> the individual named. If you are not the named >>> addressee you should not disseminate, distribute or >>> copy this e-mail. Please notify the sender >>> immediately by e-mail if you have received this >>> e-mail by mistake and delete this e-mail from your >>> system. If you are not the intended recipient you >>> are notified that disclosing, copying, distributing >>> or taking any action in reliance on the contents of >>> this information is strictly prohibited. >>> >>> *"SAVE PAPER - THINK BEFORE YOU PRINT!" * >>> >>> >>> On 19 June 2015 at 13:50, Marek Posolda >>> > >>> wrote: >>> >>> Thanks for the info. Now I think I know what's >>> going on. >>> >>> The issue is that currently when we import users >>> from LDAP (federation in general), we sync the >>> configured attributes to the Keycloak DB. But >>> during searching, we don't sync the attributes >>> from LDAP to Keycloak DB anymore. So I guess you >>> did the steps like this: >>> - You first authenticate as LDAP user "joe" (or >>> search this user from admin console), which >>> imported this user into Keycloak DB >>> - Then you created mapper for the 'applications' >>> attribute. But user 'joe' was already imported >>> into Keycloak DB from the previous step, right? >>> >>> I believe that when you import some other user >>> from LDAP, which is not yet exist in Keycloak >>> DB, the 'applications' attribute will be there. >>> For the existing user, the only possibility >>> right now is to use "Synchronize all users" or >>> "Synchronize changed users" on LDAP federation >>> screen. This will update existing users into >>> Keycloak DB as well, so 'joe' will be updated. >>> >>> Please let me know if it helps. Looks that it's >>> something we should address better in Keycloak. >>> >>> Marek >>> >>> >>> On 19.6.2015 11:56, Kevin Thorpe wrote: >>>> I had a hunch so I added a record in >>>> USER_ATTRIBUTE for applications and it is >>>> getting passed >>>> in the JWT claims now. That squarely points at >>>> the ldap federation part. >>>> >>>> *Kevin Thorpe >>>> * >>>> CTO >>>> >>>> >>>> >>>> >>>> www.p-i.net | @PI_150 >>>> >>>> >>>> M: +44 (0)7425 160 368 | T: +44 (0)203 005 6750 >>>> | F: +44(0)207 730 2635 >>>> 150 Buckingham Palace Road, London, SW1W 9TR, UK >>>> >>>> ** >>>> _____________________________ >>>> >>>> This email and any files transmitted with it >>>> are confidential and intended solely for the >>>> use of the individual or entity to whom they >>>> are addressed. If you have received this email >>>> in error please notify the system manager. This >>>> message contains confidential information and >>>> is intended only for the individual named. If >>>> you are not the named addressee you should not >>>> disseminate, distribute or copy this e-mail. >>>> Please notify the sender immediately by e-mail >>>> if you have received this e-mail by mistake and >>>> delete this e-mail from your system. If you are >>>> not the intended recipient you are notified >>>> that disclosing, copying, distributing or >>>> taking any action in reliance on the contents >>>> of this information is strictly prohibited. >>>> >>>> *"SAVE PAPER - THINK BEFORE YOU PRINT!" * >>>> >>>> >>>> On 19 June 2015 at 10:42, Kevin Thorpe >>>> >>> > wrote: >>>> >>>> Hi Marek, thanks for the quick reply. >>>> >>>> 1. I am definitely sure that the attributes >>>> I need are in the LDAP record. >>>> >>>> 2. adding trace to federation.ldap shows my >>>> mapped attributes being read >>>> >>>> 3. there is no USER_ATTRIBUTES table I'm >>>> assuming you meant USER_ATTRIBUTE but it >>>> doesn't have my attributes. >>>> it does have a reference to my LDAP_ID >>>> so i8t looks like it should be here >>>> >>>> MariaDB [keycloak]> select * from >>>> USER_ATTRIBUTE; >>>> +---------+-------------------------------------+--------------------------------------+ >>>> | NAME | VALUE | USER_ID | >>>> +---------+-------------------------------------+--------------------------------------+ >>>> | LDAP_ID | >>>> 7fc89601-96e711e2-a5a7b2a9-738d4470 | >>>> 471f0b4f-cb7c-4610-b3d6-ddd3a18e9986 | >>>> | LDAP_ID | >>>> 3245fc81-55c211e2-a5a7b2a9-738d4470 | >>>> 6d64f5a2-d356-4ab6-9b4d-3f89a3ee38c4 | >>>> +---------+-------------------------------------+--------------------------------------+ >>>> >>>> thanks for your time on this >>>> >>>> *Kevin Thorpe >>>> * >>>> CTO >>>> >>>> >>>> >>>> >>>> www.p-i.net | @PI_150 >>>> >>>> >>>> M: +44 (0)7425 160 368 | T: +44 (0)203 005 >>>> 6750 | F: +44(0)207 730 2635 >>>> 150 Buckingham Palace Road, London, SW1W >>>> 9TR, UK >>>> >>>> ** >>>> _____________________________ >>>> >>>> This email and any files transmitted with >>>> it are confidential and intended solely for >>>> the use of the individual or entity to whom >>>> they are addressed. If you have received >>>> this email in error please notify the >>>> system manager. This message contains >>>> confidential information and is intended >>>> only for the individual named. If you are >>>> not the named addressee you should not >>>> disseminate, distribute or copy this >>>> e-mail. Please notify the sender >>>> immediately by e-mail if you have received >>>> this e-mail by mistake and delete this >>>> e-mail from your system. If you are not the >>>> intended recipient you are notified that >>>> disclosing, copying, distributing or taking >>>> any action in reliance on the contents of >>>> this information is strictly prohibited. >>>> >>>> *"SAVE PAPER - THINK BEFORE YOU PRINT!" * >>>> >>>> >>>> On 19 June 2015 at 10:15, Marek Posolda >>>> >>> > wrote: >>>> >>>> There are few steps here and the result >>>> will work only if all steps success. So >>>> it might help to try which step could >>>> be wrong here: >>>> >>>> 1) You can doublecheck if your user >>>> really has 'applications' attribute in LDAP >>>> >>>> 2) If (1) is ok, you can enable TRACE >>>> logging for >>>> "org.keycloak.federation.ldap" category >>>> in standalone.xml . With it, you should >>>> see some trace messages with the names >>>> and values of all LDAP attributes, >>>> which are loaded in user record. You >>>> should see the 'applications' attribute >>>> loaded >>>> >>>> 3) If (2) is ok, you can browse >>>> keycloak database and check if >>>> attribute 'applications' is really >>>> here. The user attributes are saved in >>>> table USER_ATTRIBUTES. Currently it's >>>> not possible to browse user attributes >>>> generically in admin console (unless >>>> you do custom theme) so browse DB seems >>>> to be the only possibility. >>>> >>>> 4) If (3) is ok, the issue is not in >>>> LDAP interaction, but in protocol >>>> mapper configuration. Make sure you use >>>> correct protocol mapper (In your case >>>> it should be "User attributes" mapper, >>>> not "User property" mapper). Also if >>>> your application is Java based, the >>>> value of 'applications' claim is saved >>>> in accessToken in 'otherClaims' map and >>>> can be retrieved with something like: >>>> accessToken.getOtherClaims().get("applications"); >>>> >>>> Marek >>>> >>>> >>>> >>>> On 18.6.2015 17:50, Kevin Thorpe wrote: >>>>> Thanks to the team for 1.3.1. We were >>>>> eagerly waiting for that to add LDAP >>>>> attribute mappings which I see has now >>>>> been done. Unfortunately I can't seem >>>>> to get it to work. >>>>> >>>>> I have added a user attribute mapper >>>>> to my ldap federation. This maps the >>>>> LDAP atribute 'applications' which >>>>> exists on my LDAP user record to >>>>> 'applications' in Keycloak. >>>>> >>>>> I have also added a user attribute >>>>> token mapper to my Keycloak client >>>>> definition to map user attribute >>>>> 'applications' to token claim >>>>> 'applications'. I've also asked to add >>>>> to both id and access token. >>>>> >>>>> However this attribute is not present >>>>> in either the ID or access token when >>>>> testing. Is there something I've missed? >>>>> >>>>> Something that may be an issue though >>>>> is that I'm using a home written >>>>> openid-connect Lua client based on >>>>> your javascript one. This uses the >>>>> endpoint >>>>> /auth/realms/master/protocol/openid-connect/token. >>>>> Is it that the openid-connect endpoint >>>>> doesn't support these attributes yet? >>>>> >>>>> *Kevin Thorpe >>>>> * >>>>> CTO, PI ltd >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> >>>> >>> >>> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3053 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0008.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1204 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0009.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3053 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0010.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1204 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0011.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3053 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0012.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1204 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0013.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3053 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0014.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1204 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/ec9c63b2/attachment-0015.jpe From emorny at gmail.com Mon Aug 3 08:23:37 2015 From: emorny at gmail.com (Edem Morny) Date: Mon, 03 Aug 2015 12:23:37 +0000 Subject: [keycloak-user] REST API: Create User With Roles Message-ID: <1438604617.4587.8.camel@localhost.localdomain> Hi, We're currently using Keycloak 1.2.0.Final. We are migrating users from an existing application with it's own user management implementation to Keycloak, and have been making extensive use of the Via the REST api to achieve this. I'm able to create a new user, set their temporary password and so on. However, I'm finding that all our attempts to add the roles to the created user seem not to be taking effect when we observe the newly created user on the keycloak side. Here's the code we are trying to use to do this UserRepresentation user = new UserRepresentation(); user.setUsername(username); user.setFirstName(employee.getFirstName()); user.setLastName(employee.getLastName()); user.setEmail(employee.getEmail()); user.setEnabled(true); user.setEmailVerified(false); List requiredActions = new ArrayList<>(); requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); List userRoles = getMigrateRoles(employee); user.setRealmRoles(userRoles); user.setRequiredActions(requiredActions); adminClient.createUser(settings.getKeycloackUrl(), settings.getRealm(), access, user); It seams setting the list of roles to the Realm Roles isn't enough to the user with these roles. The user gets created alright, but doesn't come with any roles. Is there any other means by which we can specify the user roles during the process of account creation? The migration will be very tedious if we ask the administrators to manually do the assignment of the user to their roles after our current implementation of being able to automatically migrate the user accounts themselves to keycloak. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/0166cbfd/attachment.html From Martin.Hipfinger at oebb.at Mon Aug 3 08:31:16 2015 From: Martin.Hipfinger at oebb.at (=?utf-8?B?SGlwZmluZ2VyIE1hcnRpbiAoQkNDLsOWQkIuVGlja2V0U2hvcC5NQSk=?=) Date: Mon, 3 Aug 2015 12:31:16 +0000 Subject: [keycloak-user] WG: AW: AW: multi tenant configuration with 1.3.1? References: <1CBE59D9C302B841A9562E1A3A6F5B7333076AED@LAXEX004.oebb.at> <980465831.2641731.1437564183052.JavaMail.zimbra@redhat.com> <1CBE59D9C302B841A9562E1A3A6F5B7333076B48@LAXEX004.oebb.at> <913052916.2646145.1437564831858.JavaMail.zimbra@redhat.com> <1CBE59D9C302B841A9562E1A3A6F5B7333076B6D@LAXEX004.oebb.at> <1781006219.2656792.1437565562724.JavaMail.zimbra@redhat.com> Message-ID: <1CBE59D9C302B841A9562E1A3A6F5B7333083E6A@LAXEX004.oebb.at> In our current setup, each tenant is using several realms. Each tenant is using it?s own database. This setup fits exactly to our needs. However, we?d need 1.3.1 features, so I?m searching for the best fitting new setup. @ multi-tenancy example: after following the steps mentioned in the example, I see the urls configured in the ?tenant-realm? [cid:image001.png at 01D0C52C.EADCB4B0] The url of the client-id multi-tenant brings 404 The url of the client-id security-admin-console and account brings the login page, but the user user-tenant1 cannot login (we?re sorry ? no access) -----Urspr?ngliche Nachricht----- Von: Stian Thorgersen [mailto:stian at redhat.com] Gesendet: Mittwoch, 22. Juli 2015 13:46 An: Hipfinger Martin (BCC.?BB.TicketShop.MA) Betreff: Re: AW: AW: [keycloak-user] multi tenant configuration with 1.3.1? Yes, multi-tenancy is based on realms. Why would we need two levels of multi-tenancy? I'd need more info about what your problem is to be able to help you out with the multi-tenancy example ----- Original Message ----- > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > > > To: "Stian Thorgersen" > > Sent: Wednesday, 22 July, 2015 1:41:05 PM > Subject: AW: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > But i don't understand the multi tenancy concept then - is it based > just on realms? However, I couldn't get this example working either > https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant > > -----Urspr?ngliche Nachricht----- > Von: Stian Thorgersen [mailto:stian at redhat.com] > Gesendet: Mittwoch, 22. Juli 2015 13:34 > An: Hipfinger Martin (BCC.?BB.TicketShop.MA) > Betreff: Re: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > Ah, sorry thought you where talking about providers. We don't support > overlays and really never have, it was an experimental feature. You > should configure Keycloak through standalone/configuration/keycloak-server.json. > > ----- Original Message ----- > > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > > > > > To: "Stian Thorgersen" > > > Sent: Wednesday, 22 July, 2015 1:30:12 PM > > Subject: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > > > Hi, > > > > i've already done that for sure - but cannot see the necessary > > steps; would you please be so kind and point me to the right direction? > > > > br, > > Martin > > > > -----Urspr?ngliche Nachricht----- > > Von: Stian Thorgersen [mailto:stian at redhat.com] > > Gesendet: Mittwoch, 22. Juli 2015 13:23 > > An: Hipfinger Martin (BCC.?BB.TicketShop.MA) > > Cc: keycloak-user at lists.jboss.org > > Betreff: Re: [keycloak-user] multi tenant configuration with 1.3.1? > > > > Read the manual: > > http://keycloak.github.io/docs/userguide/html/Migration_from_older_v > > er > > sions.html#d4e3319 > > > > ----- Original Message ----- > > > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > > > > > > > To: keycloak-user at lists.jboss.org > > > Sent: Wednesday, 22 July, 2015 1:07:54 PM > > > Subject: [keycloak-user] multi tenant configuration with 1.3.1? > > > > > > > > > > > > Hi, > > > > > > > > > > > > we?re running keycloak 1.1 with several overlays ? in detail: > > > > > > > > > > > > - A new datasource per overlay > > > > > > /opt/keycloak/bin/jboss-cli.sh --commands="connect, data-source > > > add --name= xxx DS --connection-url=jdbc:oracle:thin:@ > > > xxxxx:1522:xxxxx --jndi-name=java:jboss/datasources/ xxx DS > > > --driver-name=ojdbc --password= xxx --user-name= XXX " > > > > > > > > > > > > - A new auth-server entry > > > > > > /opt/keycloak/bin/jboss-cli.sh --commands="connect, > > > /subsystem=keycloak/auth-server= xxx -server/:add(web-context= xxx > > > , enabled=true)" > > > > > > > > > > > > - An own keycloak-server.json > > > > > > "connectionsJpa": { > > > > > > "default": { > > > > > > "dataSource": "java:jboss/datasources/ xxx DS", > > > > > > "databaseSchema": "update" > > > > > > } > > > > > > } > > > > > > "connectionsInfinispan": { > > > > > > "default" : { > > > > > > "cacheContainer" : "java:jboss/infinispan/ xxx Keycloak" > > > > > > } > > > > > > > > > > > > /opt/keycloak/bin/jboss-cli.sh --commands=?connect, > > > /subsystem=keycloak/auth-server= xxx > > > -server:update-server-config(bytes-to-upload=/opt/keycloak/standal > > > on > > > e/ > > > configuration/keycloak-server- > > > xxx .json,overwrite=true)? > > > > > > > > > > > > This configuration isn?t supported anymore with 1.3.1 - do you > > > have any hint for me, how to achieve a similar config with 1.3.1? > > > > > > > > > > > > br, > > > > > > Martin > > > > > > > > > > > > > > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/f9042574/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 41829 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/f9042574/attachment-0001.png From bburke at redhat.com Mon Aug 3 08:36:24 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 3 Aug 2015 08:36:24 -0400 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <1438604617.4587.8.camel@localhost.localdomain> References: <1438604617.4587.8.camel@localhost.localdomain> Message-ID: <55BF6048.8000600@redhat.com> Is adminClient.createUser(...) your own method? There is a different REST API for adding roles. create the user then add the roles On 8/3/2015 8:23 AM, Edem Morny wrote: > Hi, > > We're currently using Keycloak 1.2.0.Final. > > We are migrating users from an existing application with it's own user > management implementation to Keycloak, and have been making extensive > use of the Via the REST api to achieve this. I'm able to create a new > user, set their temporary password and so on. However, I'm finding that > all our attempts to add the roles to the created user seem not to be > taking effect when we observe the newly created user on the keycloak > side. Here's the code we are trying to use to do this > > UserRepresentation user = new UserRepresentation(); > user.setUsername(username); > user.setFirstName(employee.getFirstName()); > user.setLastName(employee.getLastName()); > user.setEmail(employee.getEmail()); > user.setEnabled(true); > user.setEmailVerified(false); > List requiredActions = new ArrayList<>(); > requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); > *List userRoles = getMigrateRoles(employee);* > * user.setRealmRoles(userRoles);* > user.setRequiredActions(requiredActions); > adminClient.createUser(settings.getKeycloackUrl(), settings.getRealm(), access, user); > > It seams setting the list of roles to the Realm Roles isn't enough to > the user with these roles. The user gets created alright, but doesn't > come with any roles. Is there any other means by which we can specify > the user roles during the process of account creation? > > The migration will be very tedious if we ask the administrators to > manually do the assignment of the user to their roles after our current > implementation of being able to automatically migrate the user accounts > themselves to keycloak. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From emorny at gmail.com Mon Aug 3 09:07:23 2015 From: emorny at gmail.com (Edem Morny) Date: Mon, 03 Aug 2015 13:07:23 +0000 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <55BF6048.8000600@redhat.com> References: <1438604617.4587.8.camel@localhost.localdomain> <55BF6048.8000600@redhat.com> Message-ID: <1438607243.4587.12.camel@localhost.localdomain> Hi Bill, The adminClient.createUser is my modification of the code situated in the AdminClient implementation of the "admin-access-app" in the examples. Could you point me in the direction of the API calls to do the addition of the roles? I had a feeling it might be a subsequent step (like for setting the password, which I actually implemented), but I'm struggling to find any pointers as to how to do this particular one. On Mon, 2015-08-03 at 08:36 -0400, Bill Burke wrote: > Is adminClient.createUser(...) your own method? There is a different > REST API for adding roles. > > create the user > then add the roles > > On 8/3/2015 8:23 AM, Edem Morny wrote: > > Hi, > > > > We're currently using Keycloak 1.2.0.Final. > > > > We are migrating users from an existing application with it's own user > > management implementation to Keycloak, and have been making extensive > > use of the Via the REST api to achieve this. I'm able to create a new > > user, set their temporary password and so on. However, I'm finding that > > all our attempts to add the roles to the created user seem not to be > > taking effect when we observe the newly created user on the keycloak > > side. Here's the code we are trying to use to do this > > > > UserRepresentation user = new UserRepresentation(); > > user.setUsername(username); > > user.setFirstName(employee.getFirstName()); > > user.setLastName(employee.getLastName()); > > user.setEmail(employee.getEmail()); > > user.setEnabled(true); > > user.setEmailVerified(false); > > List requiredActions = new ArrayList<>(); > > requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); > > *List userRoles = getMigrateRoles(employee);* > > * user.setRealmRoles(userRoles);* > > user.setRequiredActions(requiredActions); > > adminClient.createUser(settings.getKeycloackUrl(), settings.getRealm(), access, user); > > > > It seams setting the list of roles to the Realm Roles isn't enough to > > the user with these roles. The user gets created alright, but doesn't > > come with any roles. Is there any other means by which we can specify > > the user roles during the process of account creation? > > > > The migration will be very tedious if we ask the administrators to > > manually do the assignment of the user to their roles after our current > > implementation of being able to automatically migrate the user accounts > > themselves to keycloak. > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/aa15c801/attachment.html From bburke at redhat.com Mon Aug 3 09:13:54 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 3 Aug 2015 09:13:54 -0400 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <1438607243.4587.12.camel@localhost.localdomain> References: <1438604617.4587.8.camel@localhost.localdomain> <55BF6048.8000600@redhat.com> <1438607243.4587.12.camel@localhost.localdomain> Message-ID: <55BF6912.4090502@redhat.com> If you're just using the admin client interfaces its: realm("realm").users().get("user-id").roles().realmLevel().add(List rolesToAdd) On 8/3/2015 9:07 AM, Edem Morny wrote: > Hi Bill, > > The adminClient.createUser is my modification of the code situated in > the AdminClient implementation of the "admin-access-app" in the examples. > > Could you point me in the direction of the API calls to do the addition > of the roles? I had a feeling it might be a subsequent step (like for > setting the password, which I actually implemented), but I'm struggling > to find any pointers as to how to do this particular one. > > > On Mon, 2015-08-03 at 08:36 -0400, Bill Burke wrote: >> Is adminClient.createUser(...) your own method? There is a different >> REST API for adding roles. >> >> create the user >> then add the roles >> >> On 8/3/2015 8:23 AM, Edem Morny wrote: >> > Hi, >> > >> > We're currently using Keycloak 1.2.0.Final. >> > >> > We are migrating users from an existing application with it's own user >> > management implementation to Keycloak, and have been making extensive >> > use of the Via the REST api to achieve this. I'm able to create a new >> > user, set their temporary password and so on. However, I'm finding that >> > all our attempts to add the roles to the created user seem not to be >> > taking effect when we observe the newly created user on the keycloak >> > side. Here's the code we are trying to use to do this >> > >> > UserRepresentation user = new UserRepresentation(); >> > user.setUsername(username); >> > user.setFirstName(employee.getFirstName()); >> > user.setLastName(employee.getLastName()); >> > user.setEmail(employee.getEmail()); >> > user.setEnabled(true); >> > user.setEmailVerified(false); >> > List requiredActions = new ArrayList<>(); >> > requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); >> > *List userRoles = getMigrateRoles(employee);* >> > * user.setRealmRoles(userRoles);* >> > user.setRequiredActions(requiredActions); >> > adminClient.createUser(settings.getKeycloackUrl(), >> settings.getRealm(), access, user); >> > >> > It seams setting the list of roles to the Realm Roles isn't enough to >> > the user with these roles. The user gets created alright, but doesn't >> > come with any roles. Is there any other means by which we can specify >> > the user roles during the process of account creation? >> > >> > The migration will be very tedious if we ask the administrators to >> > manually do the assignment of the user to their roles after our current >> > implementation of being able to automatically migrate the user accounts >> > themselves to keycloak. >> > >> > >> > _______________________________________________ >> > 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From emorny at gmail.com Mon Aug 3 09:48:56 2015 From: emorny at gmail.com (Edem Morny) Date: Mon, 03 Aug 2015 13:48:56 +0000 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <55BF6912.4090502@redhat.com> References: <1438604617.4587.8.camel@localhost.localdomain> <55BF6048.8000600@redhat.com> <1438607243.4587.12.camel@localhost.localdomain> <55BF6912.4090502@redhat.com> Message-ID: <1438609736.4587.18.camel@localhost.localdomain> Hi, Sorry Bill, I think I'm confusing matters here. The AdminClient I'm referring to is not the keycloak-admin-client.jar but rather a combination of insights from https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java and from the documentation in the user guide. That means I'm constructing the URLs myself to invoke the operation. I intend to move to the keycloak-admin-client in the future though. I can't find the corresponding REST url(s) to invoke to achieve the same results as you describe in your response below. I think that's what I need. Cheers. On Mon, 2015-08-03 at 09:13 -0400, Bill Burke wrote: > If you're just using the admin client interfaces its: > > realm("realm").users().get("user-id").roles().realmLevel().add(List > rolesToAdd) > > On 8/3/2015 9:07 AM, Edem Morny wrote: > > Hi Bill, > > > > The adminClient.createUser is my modification of the code situated in > > the AdminClient implementation of the "admin-access-app" in the examples. > > > > Could you point me in the direction of the API calls to do the addition > > of the roles? I had a feeling it might be a subsequent step (like for > > setting the password, which I actually implemented), but I'm struggling > > to find any pointers as to how to do this particular one. > > > > > > On Mon, 2015-08-03 at 08:36 -0400, Bill Burke wrote: > >> Is adminClient.createUser(...) your own method? There is a different > >> REST API for adding roles. > >> > >> create the user > >> then add the roles > >> > >> On 8/3/2015 8:23 AM, Edem Morny wrote: > >> > Hi, > >> > > >> > We're currently using Keycloak 1.2.0.Final. > >> > > >> > We are migrating users from an existing application with it's own user > >> > management implementation to Keycloak, and have been making extensive > >> > use of the Via the REST api to achieve this. I'm able to create a new > >> > user, set their temporary password and so on. However, I'm finding that > >> > all our attempts to add the roles to the created user seem not to be > >> > taking effect when we observe the newly created user on the keycloak > >> > side. Here's the code we are trying to use to do this > >> > > >> > UserRepresentation user = new UserRepresentation(); > >> > user.setUsername(username); > >> > user.setFirstName(employee.getFirstName()); > >> > user.setLastName(employee.getLastName()); > >> > user.setEmail(employee.getEmail()); > >> > user.setEnabled(true); > >> > user.setEmailVerified(false); > >> > List requiredActions = new ArrayList<>(); > >> > requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); > >> > *List userRoles = getMigrateRoles(employee);* > >> > * user.setRealmRoles(userRoles);* > >> > user.setRequiredActions(requiredActions); > >> > adminClient.createUser(settings.getKeycloackUrl(), > >> settings.getRealm(), access, user); > >> > > >> > It seams setting the list of roles to the Realm Roles isn't enough to > >> > the user with these roles. The user gets created alright, but doesn't > >> > come with any roles. Is there any other means by which we can specify > >> > the user roles during the process of account creation? > >> > > >> > The migration will be very tedious if we ask the administrators to > >> > manually do the assignment of the user to their roles after our current > >> > implementation of being able to automatically migrate the user accounts > >> > themselves to keycloak. > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/f64e7ed6/attachment-0001.html From bburke at redhat.com Mon Aug 3 09:51:04 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 3 Aug 2015 09:51:04 -0400 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <1438609736.4587.18.camel@localhost.localdomain> References: <1438604617.4587.8.camel@localhost.localdomain> <55BF6048.8000600@redhat.com> <1438607243.4587.12.camel@localhost.localdomain> <55BF6912.4090502@redhat.com> <1438609736.4587.18.camel@localhost.localdomain> Message-ID: <55BF71C8.5050306@redhat.com> http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/clients/%7Bclient%7D/index.html On 8/3/2015 9:48 AM, Edem Morny wrote: > Hi, > > Sorry Bill, I think I'm confusing matters here. The AdminClient I'm > referring to is not the keycloak-admin-client.jar but rather a > combination of insights from > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java > and from the documentation in the user guide. > > That means I'm constructing the URLs myself to invoke the operation. I > intend to move to the keycloak-admin-client in the future though. > > I can't find the corresponding REST url(s) to invoke to achieve the same > results as you describe in your response below. I think that's what I need. > Cheers. > > > On Mon, 2015-08-03 at 09:13 -0400, Bill Burke wrote: >> If you're just using the admin client interfaces its: >> >> realm("realm").users().get("user-id").roles().realmLevel().add(List >> rolesToAdd) >> >> On 8/3/2015 9:07 AM, Edem Morny wrote: >> > Hi Bill, >> > >> > The adminClient.createUser is my modification of the code situated in >> > the AdminClient implementation of the "admin-access-app" in the >> examples. >> > >> > Could you point me in the direction of the API calls to do the addition >> > of the roles? I had a feeling it might be a subsequent step (like for >> > setting the password, which I actually implemented), but I'm struggling >> > to find any pointers as to how to do this particular one. >> > >> > >> > On Mon, 2015-08-03 at 08:36 -0400, Bill Burke wrote: >> >> Is adminClient.createUser(...) your own method? There is a different >> >> REST API for adding roles. >> >> >> >> create the user >> >> then add the roles >> >> >> >> On 8/3/2015 8:23 AM, Edem Morny wrote: >> >> > Hi, >> >> > >> >> > We're currently using Keycloak 1.2.0.Final. >> >> > >> >> > We are migrating users from an existing application with it's own >> user >> >> > management implementation to Keycloak, and have been making extensive >> >> > use of the Via the REST api to achieve this. I'm able to create a new >> >> > user, set their temporary password and so on. However, I'm >> finding that >> >> > all our attempts to add the roles to the created user seem not to be >> >> > taking effect when we observe the newly created user on the keycloak >> >> > side. Here's the code we are trying to use to do this >> >> > >> >> > UserRepresentation user = new UserRepresentation(); >> >> > user.setUsername(username); >> >> > user.setFirstName(employee.getFirstName()); >> >> > user.setLastName(employee.getLastName()); >> >> > user.setEmail(employee.getEmail()); >> >> > user.setEnabled(true); >> >> > user.setEmailVerified(false); >> >> > List requiredActions = new ArrayList<>(); >> >> > requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); >> >> > *List userRoles = getMigrateRoles(employee);* >> >> > * user.setRealmRoles(userRoles);* >> >> > user.setRequiredActions(requiredActions); >> >> > adminClient.createUser(settings.getKeycloackUrl(), >> >> settings.getRealm(), access, user); >> >> > >> >> > It seams setting the list of roles to the Realm Roles isn't enough to >> >> > the user with these roles. The user gets created alright, but doesn't >> >> > come with any roles. Is there any other means by which we can specify >> >> > the user roles during the process of account creation? >> >> > >> >> > The migration will be very tedious if we ask the administrators to >> >> > manually do the assignment of the user to their roles after our >> current >> >> > implementation of being able to automatically migrate the user >> accounts >> >> > themselves to keycloak. >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> > >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Aug 3 10:00:07 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 3 Aug 2015 10:00:07 -0400 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <55BF71C8.5050306@redhat.com> References: <1438604617.4587.8.camel@localhost.localdomain> <55BF6048.8000600@redhat.com> <1438607243.4587.12.camel@localhost.localdomain> <55BF6912.4090502@redhat.com> <1438609736.4587.18.camel@localhost.localdomain> <55BF71C8.5050306@redhat.com> Message-ID: <55BF73E7.3090709@redhat.com> Sorry, its this: http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/realm/index.html#POST On 8/3/2015 9:51 AM, Bill Burke wrote: > http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/clients/%7Bclient%7D/index.html > > On 8/3/2015 9:48 AM, Edem Morny wrote: >> Hi, >> >> Sorry Bill, I think I'm confusing matters here. The AdminClient I'm >> referring to is not the keycloak-admin-client.jar but rather a >> combination of insights from >> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java >> and from the documentation in the user guide. >> >> That means I'm constructing the URLs myself to invoke the operation. I >> intend to move to the keycloak-admin-client in the future though. >> >> I can't find the corresponding REST url(s) to invoke to achieve the same >> results as you describe in your response below. I think that's what I need. >> Cheers. >> >> >> On Mon, 2015-08-03 at 09:13 -0400, Bill Burke wrote: >>> If you're just using the admin client interfaces its: >>> >>> realm("realm").users().get("user-id").roles().realmLevel().add(List >>> rolesToAdd) >>> >>> On 8/3/2015 9:07 AM, Edem Morny wrote: >>>> Hi Bill, >>>> >>>> The adminClient.createUser is my modification of the code situated in >>>> the AdminClient implementation of the "admin-access-app" in the >>> examples. >>>> >>>> Could you point me in the direction of the API calls to do the addition >>>> of the roles? I had a feeling it might be a subsequent step (like for >>>> setting the password, which I actually implemented), but I'm struggling >>>> to find any pointers as to how to do this particular one. >>>> >>>> >>>> On Mon, 2015-08-03 at 08:36 -0400, Bill Burke wrote: >>>>> Is adminClient.createUser(...) your own method? There is a different >>>>> REST API for adding roles. >>>>> >>>>> create the user >>>>> then add the roles >>>>> >>>>> On 8/3/2015 8:23 AM, Edem Morny wrote: >>>>>> Hi, >>>>>> >>>>>> We're currently using Keycloak 1.2.0.Final. >>>>>> >>>>>> We are migrating users from an existing application with it's own >>> user >>>>>> management implementation to Keycloak, and have been making extensive >>>>>> use of the Via the REST api to achieve this. I'm able to create a new >>>>>> user, set their temporary password and so on. However, I'm >>> finding that >>>>>> all our attempts to add the roles to the created user seem not to be >>>>>> taking effect when we observe the newly created user on the keycloak >>>>>> side. Here's the code we are trying to use to do this >>>>>> >>>>>> UserRepresentation user = new UserRepresentation(); >>>>>> user.setUsername(username); >>>>>> user.setFirstName(employee.getFirstName()); >>>>>> user.setLastName(employee.getLastName()); >>>>>> user.setEmail(employee.getEmail()); >>>>>> user.setEnabled(true); >>>>>> user.setEmailVerified(false); >>>>>> List requiredActions = new ArrayList<>(); >>>>>> requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); >>>>>> *List userRoles = getMigrateRoles(employee);* >>>>>> * user.setRealmRoles(userRoles);* >>>>>> user.setRequiredActions(requiredActions); >>>>>> adminClient.createUser(settings.getKeycloackUrl(), >>>>> settings.getRealm(), access, user); >>>>>> >>>>>> It seams setting the list of roles to the Realm Roles isn't enough to >>>>>> the user with these roles. The user gets created alright, but doesn't >>>>>> come with any roles. Is there any other means by which we can specify >>>>>> the user roles during the process of account creation? >>>>>> >>>>>> The migration will be very tedious if we ask the administrators to >>>>>> manually do the assignment of the user to their roles after our >>> current >>>>>> implementation of being able to automatically migrate the user >>> accounts >>>>>> themselves to keycloak. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From emorny at gmail.com Mon Aug 3 10:02:36 2015 From: emorny at gmail.com (Edem Morny) Date: Mon, 03 Aug 2015 14:02:36 +0000 Subject: [keycloak-user] REST API: Create User With Roles In-Reply-To: <55BF73E7.3090709@redhat.com> References: <1438604617.4587.8.camel@localhost.localdomain> <55BF6048.8000600@redhat.com> <1438607243.4587.12.camel@localhost.localdomain> <55BF6912.4090502@redhat.com> <1438609736.4587.18.camel@localhost.localdomain> <55BF71C8.5050306@redhat.com> <55BF73E7.3090709@redhat.com> Message-ID: <1438610556.4587.19.camel@localhost.localdomain> Thanks very much. Will jump to it. On Mon, 2015-08-03 at 10:00 -0400, Bill Burke wrote: > Sorry, its this: > > http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/realm/index.html#POST > > On 8/3/2015 9:51 AM, Bill Burke wrote: > > http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/clients/%7Bclient%7D/index.html > > > > On 8/3/2015 9:48 AM, Edem Morny wrote: > >> Hi, > >> > >> Sorry Bill, I think I'm confusing matters here. The AdminClient I'm > >> referring to is not the keycloak-admin-client.jar but rather a > >> combination of insights from > >> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java > >> and from the documentation in the user guide. > >> > >> That means I'm constructing the URLs myself to invoke the operation. I > >> intend to move to the keycloak-admin-client in the future though. > >> > >> I can't find the corresponding REST url(s) to invoke to achieve the same > >> results as you describe in your response below. I think that's what I need. > >> Cheers. > >> > >> > >> On Mon, 2015-08-03 at 09:13 -0400, Bill Burke wrote: > >>> If you're just using the admin client interfaces its: > >>> > >>> realm("realm").users().get("user-id").roles().realmLevel().add(List > >>> rolesToAdd) > >>> > >>> On 8/3/2015 9:07 AM, Edem Morny wrote: > >>>> Hi Bill, > >>>> > >>>> The adminClient.createUser is my modification of the code situated in > >>>> the AdminClient implementation of the "admin-access-app" in the > >>> examples. > >>>> > >>>> Could you point me in the direction of the API calls to do the addition > >>>> of the roles? I had a feeling it might be a subsequent step (like for > >>>> setting the password, which I actually implemented), but I'm struggling > >>>> to find any pointers as to how to do this particular one. > >>>> > >>>> > >>>> On Mon, 2015-08-03 at 08:36 -0400, Bill Burke wrote: > >>>>> Is adminClient.createUser(...) your own method? There is a different > >>>>> REST API for adding roles. > >>>>> > >>>>> create the user > >>>>> then add the roles > >>>>> > >>>>> On 8/3/2015 8:23 AM, Edem Morny wrote: > >>>>>> Hi, > >>>>>> > >>>>>> We're currently using Keycloak 1.2.0.Final. > >>>>>> > >>>>>> We are migrating users from an existing application with it's own > >>> user > >>>>>> management implementation to Keycloak, and have been making extensive > >>>>>> use of the Via the REST api to achieve this. I'm able to create a new > >>>>>> user, set their temporary password and so on. However, I'm > >>> finding that > >>>>>> all our attempts to add the roles to the created user seem not to be > >>>>>> taking effect when we observe the newly created user on the keycloak > >>>>>> side. Here's the code we are trying to use to do this > >>>>>> > >>>>>> UserRepresentation user = new UserRepresentation(); > >>>>>> user.setUsername(username); > >>>>>> user.setFirstName(employee.getFirstName()); > >>>>>> user.setLastName(employee.getLastName()); > >>>>>> user.setEmail(employee.getEmail()); > >>>>>> user.setEnabled(true); > >>>>>> user.setEmailVerified(false); > >>>>>> List requiredActions = new ArrayList<>(); > >>>>>> requiredActions.add(UserModel.RequiredAction.UPDATE_PASSWORD.name()); > >>>>>> *List userRoles = getMigrateRoles(employee);* > >>>>>> * user.setRealmRoles(userRoles);* > >>>>>> user.setRequiredActions(requiredActions); > >>>>>> adminClient.createUser(settings.getKeycloackUrl(), > >>>>> settings.getRealm(), access, user); > >>>>>> > >>>>>> It seams setting the list of roles to the Realm Roles isn't enough to > >>>>>> the user with these roles. The user gets created alright, but doesn't > >>>>>> come with any roles. Is there any other means by which we can specify > >>>>>> the user roles during the process of account creation? > >>>>>> > >>>>>> The migration will be very tedious if we ask the administrators to > >>>>>> manually do the assignment of the user to their roles after our > >>> current > >>>>>> implementation of being able to automatically migrate the user > >>> accounts > >>>>>> themselves to keycloak. > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> > >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/45b2a3ca/attachment-0001.html From mposolda at redhat.com Mon Aug 3 10:51:57 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 03 Aug 2015 16:51:57 +0200 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BE16EE.6070006@redhat.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> Message-ID: <55BF800D.4020905@redhat.com> Thanks for the detailed report. I've created JIRA for this and will be fixed for next release https://issues.jboss.org/browse/KEYCLOAK-1725 . Marek On 2.8.2015 15:11, Bill Burke wrote: > You probably have to export your database to json and re-import it until > we track this down. > > On 8/1/2015 11:19 AM, Stephen Flynn wrote: >> Hi all, >> >> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >> >> The liquibase db scripts are failing. The particular script that is >> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused >> by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to >> java.lang.Long'. More stack trace below. >> >> Any ideas as to why this might be happening ? Is there anything else I >> can provide to give more insight ? >> >> best rgds, >> >> Steve F. >> >> >> Environment is... >> >> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >> * jdk1.7.0_51 >> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >> >> >> Liquibase change log from the DB >> >> * 1.0.0.Final sthorger at redhat.com >> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >> 00:55:28.95072 1 EXECUTED >> * 1.1.0.Beta1 sthorger at redhat.com >> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >> 00:55:30.070692 2 EXECUTED >> * 1.1.0.Final sthorger at redhat.com >> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >> 00:55:27.065618 3 EXECUTED >> >> >> Error message in log... >> >> 15:12:31,238 INFO [org.keycloak.services.resources.KeycloakApplication] >> (ServerService Thread Pool -- 69) Load config from >> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >> 15:12:34,416 INFO >> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >> (ServerService Thread Pool -- 69) Updating database >> 15:12:35,982 ERROR >> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >> (ServerService Thread Pool -- 69) Change Set >> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >> failed. Error: liquibase.exception.CustomChangeException: Update >> 1.2.0.Beta1: Exception when updating data from previous version: >> liquibase.exception.UnexpectedLiquibaseException: >> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception >> when updating data from previous version >> at >> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >> at >> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >> at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >> at >> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >> at >> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >> at liquibase.Liquibase.update(Liquibase.java:200) >> at liquibase.Liquibase.update(Liquibase.java:181) >> at >> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> [rt.jar:1.7.0_51] >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >> [rt.jar:1.7.0_51] >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> [rt.jar:1.7.0_51] >> at >> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >> [rt.jar:1.7.0_51] >> at >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >> [resteasy-jaxrs-3.0.11.Final.jar:] >> at >> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >> [resteasy-jaxrs-3.0.11.Final.jar:] >> at >> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >> [resteasy-jaxrs-3.0.11.Final.jar:] >> at >> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >> [resteasy-jaxrs-3.0.11.Final.jar:] >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >> [resteasy-jaxrs-3.0.11.Final.jar:] >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >> [resteasy-jaxrs-3.0.11.Final.jar:] >> at >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >> at >> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >> at >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >> at >> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >> at >> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >> at >> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >> 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:471) >> [rt.jar:1.7.0_51] >> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >> [rt.jar:1.7.0_51] >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_51] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_51] >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> Caused by: liquibase.exception.CustomChangeException: Update >> 1.2.0.Beta1: Exception when updating data from previous version >> at >> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >> at >> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >> ... 44 more >> Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be >> cast to java.lang.Long >> at >> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >> at >> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >> ... 46 more >> >> -- >> =================================================== >> >> *Stephen Flynn* >> >> *Director, JF Technology (UK) Ltd* >> >> Cell (UK) : +44 7768 003 882 >> Phone : +44 20 7833 8346 >> IM : xmpp:stephen.flynn at jftechnology.com >> IM : aim:stephen.flynn at jftechnology.com >> Website : http://www.jftechnology.com >> Tech support : support at jftechnology.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 Aug 3 10:53:44 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 3 Aug 2015 10:53:44 -0400 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BF800D.4020905@redhat.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> <55BF800D.4020905@redhat.com> Message-ID: <55BF8078.9090908@redhat.com> I could do a 1.4.1 when you fix it. On 8/3/2015 10:51 AM, Marek Posolda wrote: > Thanks for the detailed report. I've created JIRA for this and will be > fixed for next release https://issues.jboss.org/browse/KEYCLOAK-1725 . > > Marek > > On 2.8.2015 15:11, Bill Burke wrote: >> You probably have to export your database to json and re-import it until >> we track this down. >> >> On 8/1/2015 11:19 AM, Stephen Flynn wrote: >>> Hi all, >>> >>> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >>> >>> The liquibase db scripts are failing. The particular script that is >>> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused >>> by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to >>> java.lang.Long'. More stack trace below. >>> >>> Any ideas as to why this might be happening ? Is there anything else I >>> can provide to give more insight ? >>> >>> best rgds, >>> >>> Steve F. >>> >>> >>> Environment is... >>> >>> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >>> * jdk1.7.0_51 >>> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >>> >>> >>> Liquibase change log from the DB >>> >>> * 1.0.0.Final sthorger at redhat.com >>> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >>> 00:55:28.95072 1 EXECUTED >>> * 1.1.0.Beta1 sthorger at redhat.com >>> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >>> 00:55:30.070692 2 EXECUTED >>> * 1.1.0.Final sthorger at redhat.com >>> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >>> 00:55:27.065618 3 EXECUTED >>> >>> >>> Error message in log... >>> >>> 15:12:31,238 INFO [org.keycloak.services.resources.KeycloakApplication] >>> (ServerService Thread Pool -- 69) Load config from >>> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >>> >>> 15:12:34,416 INFO >>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>> >>> (ServerService Thread Pool -- 69) Updating database >>> 15:12:35,982 ERROR >>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>> >>> (ServerService Thread Pool -- 69) Change Set >>> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >>> failed. Error: liquibase.exception.CustomChangeException: Update >>> 1.2.0.Beta1: Exception when updating data from previous version: >>> liquibase.exception.UnexpectedLiquibaseException: >>> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception >>> when updating data from previous version >>> at >>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >>> >>> at >>> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >>> >>> at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >>> at >>> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >>> at >>> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >>> at liquibase.Liquibase.update(Liquibase.java:200) >>> at liquibase.Liquibase.update(Liquibase.java:181) >>> at >>> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >>> >>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >>> >>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >>> >>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >>> >>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>> >>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >>> >>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >>> >>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>> >>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >>> >>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >>> >>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >>> >>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >>> >>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >>> >>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >>> >>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>> at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>> [rt.jar:1.7.0_51] >>> at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>> >>> [rt.jar:1.7.0_51] >>> at >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> >>> [rt.jar:1.7.0_51] >>> at >>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>> [rt.jar:1.7.0_51] >>> at >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >>> >>> [resteasy-jaxrs-3.0.11.Final.jar:] >>> at >>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >>> >>> [resteasy-jaxrs-3.0.11.Final.jar:] >>> at >>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >>> >>> [resteasy-jaxrs-3.0.11.Final.jar:] >>> at >>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >>> >>> [resteasy-jaxrs-3.0.11.Final.jar:] >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >>> >>> [resteasy-jaxrs-3.0.11.Final.jar:] >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>> >>> [resteasy-jaxrs-3.0.11.Final.jar:] >>> at >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>> >>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>> at >>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>> >>> at >>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>> >>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>> at >>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >>> >>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>> at >>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >>> >>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>> at >>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >>> >>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>> 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:471) >>> [rt.jar:1.7.0_51] >>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>> [rt.jar:1.7.0_51] >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> >>> [rt.jar:1.7.0_51] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> >>> [rt.jar:1.7.0_51] >>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>> Caused by: liquibase.exception.CustomChangeException: Update >>> 1.2.0.Beta1: Exception when updating data from previous version >>> at >>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >>> >>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >>> >>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>> at >>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >>> >>> ... 44 more >>> Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be >>> cast to java.lang.Long >>> at >>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >>> >>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>> at >>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >>> >>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>> ... 46 more >>> >>> -- >>> =================================================== >>> >>> *Stephen Flynn* >>> >>> *Director, JF Technology (UK) Ltd* >>> >>> Cell (UK) : +44 7768 003 882 >>> Phone : +44 20 7833 8346 >>> IM : xmpp:stephen.flynn at jftechnology.com >>> IM : aim:stephen.flynn at jftechnology.com >>> Website : http://www.jftechnology.com >>> Tech support : support at jftechnology.com >>> >>> >>> =================================================== >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Mon Aug 3 11:16:29 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 03 Aug 2015 17:16:29 +0200 Subject: [keycloak-user] Angular app, login on click and not on load. In-Reply-To: References: Message-ID: <55BF85CD.6000602@redhat.com> In that case, I would likely invoke the redirection to some suffixed URL when user click to your "Login" button. And the call to the keycloak.init() will be done only when URL ends with this suffix (or you can use the query parameter). For example in the onClick event called when your button is clicked you will have: var myLoginCallback = function() { if (auth.loggedIn) { // User is already logged in. Don't do anything or do whatever you want based on your app logic } else { // Redirect to the suffixed URL window.location = '/myapp/login'; } } The angular bootstrap can then look like this: angular.element(document).ready(function ($http) { var keycloakAuth = new Keycloak('keycloak.json'); auth.loggedIn = false; if (window.location.endsWith('/myapp/login')) { keycloakAuth.init({ onLoad: 'login-required' }).success(function () /// ... Use the code like in the example app } else { // Automatically bootstrap angular. Application would be in anonymous mode angular.bootstrap(document, ["product"]); } }); Marek On 29.7.2015 14:39, Fabio Monteiro wrote: > Hi , > > I'm looking for a simple way to login to keycloak with an AngularJS app. > If i use the example (angular-produt-app) one can find with the > keyCloak appliance, the js adapter redirects the user to the Keycloak > login pase "onload " (keycloakVar.init({onLoad: 'login-required'})...) > > But i want to login only when I specifically click on some button. > From what I can gatherthe method keycloakVar.login() > from the docs & JS reference is the way to go.. but replacing the > .init() method with the .login() method doesn't seem to work... > > Also, in the "normal" case, the init() regular example itself lets > me, after logging-in succesfully, with still empty Javasript objects > once I am successfully redirected to my app page. (the auth global > variable) > > > The official angular + js-adapter : > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js > > > Could you help me ? I must be missing something. > > > Thanks a lot > > Fabio M > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/d76a6639/attachment-0001.html From stephen.flynn at jftechnology.com Mon Aug 3 11:42:28 2015 From: stephen.flynn at jftechnology.com (Stephen Flynn) Date: Mon, 3 Aug 2015 16:42:28 +0100 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BF8078.9090908@redhat.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> <55BF800D.4020905@redhat.com> <55BF8078.9090908@redhat.com> Message-ID: <55BF8BE4.6040702@jftechnology.com> In case this helps... I had a quick peek at the source - there were two issues that made Oracle choke in my environment. First the BigDecimal issue in the custom change JpaUpdate1_2_0_Beta1.java as initially reported. Secondly in the custom change JpaUpdate1_2_0_CR1.java there was a prepared statement that Oracle 10 doesn't like as it expects a boolean 'TRUE' to be represented by the numerical value '1'. I hacked the following two lines and that appears to fix the upgrade to 1.2.0.Final (for Oracle10 at least). The remaining liquibase scripts then ran without issue. best rgds, Steve F. diff --git a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java index 89e7885..895a785 100644 --- a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java +++ b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java @@ -293,7 +293,7 @@ } Object acmObj = resultSet.getObject("ALLOWED_CLAIMS_MASK"); - long mask = (acmObj != null) ? (Long) acmObj : ClaimMask.ALL; + long mask = (acmObj != null) ? ((Number) acmObj).longValue() : ClaimMask.ALL; MigrationProvider migrationProvider = this.kcSession.getProvider(MigrationProvider.class); List protocolMappers = migrationProvider.getMappersForClaimMask(mask); diff --git a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java index 5c8a2eb..dbeedf7 100644 --- a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java +++ b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java @@ -17,7 +17,7 @@ String realmClientTableName = database.correctObjectName("REALM_CLIENT", Table.class); try { - PreparedStatement statement = jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID CLIENT_ID from CLIENT where CLIENT.CONSENT_REQUIRED = true"); + PreparedStatement statement = jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID CLIENT_ID from CLIENT where CLIENT.CONSENT_REQUIRED = 1"); try { ResultSet resultSet = statement.executeQuery(); try { =================================================== *Stephen Flynn* *Director, JF Technology (UK) Ltd* Cell (UK) : +44 7768 003 882 Phone : +44 20 7833 8346 IM : xmpp:stephen.flynn at jftechnology.com IM : aim:stephen.flynn at jftechnology.com Website : http://www.jftechnology.com Tech support : support at jftechnology.com =================================================== On 03/08/2015 15:53, Bill Burke wrote: > I could do a 1.4.1 when you fix it. > > On 8/3/2015 10:51 AM, Marek Posolda wrote: >> Thanks for the detailed report. I've created JIRA for this and will be >> fixed for next release https://issues.jboss.org/browse/KEYCLOAK-1725 . >> >> Marek >> >> On 2.8.2015 15:11, Bill Burke wrote: >>> You probably have to export your database to json and re-import it until >>> we track this down. >>> >>> On 8/1/2015 11:19 AM, Stephen Flynn wrote: >>>> Hi all, >>>> >>>> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >>>> >>>> The liquibase db scripts are failing. The particular script that is >>>> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused >>>> by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to >>>> java.lang.Long'. More stack trace below. >>>> >>>> Any ideas as to why this might be happening ? Is there anything else I >>>> can provide to give more insight ? >>>> >>>> best rgds, >>>> >>>> Steve F. >>>> >>>> >>>> Environment is... >>>> >>>> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >>>> * jdk1.7.0_51 >>>> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >>>> >>>> >>>> Liquibase change log from the DB >>>> >>>> * 1.0.0.Final sthorger at redhat.com >>>> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >>>> 00:55:28.95072 1 EXECUTED >>>> * 1.1.0.Beta1 sthorger at redhat.com >>>> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >>>> 00:55:30.070692 2 EXECUTED >>>> * 1.1.0.Final sthorger at redhat.com >>>> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >>>> 00:55:27.065618 3 EXECUTED >>>> >>>> >>>> Error message in log... >>>> >>>> 15:12:31,238 INFO [org.keycloak.services.resources.KeycloakApplication] >>>> (ServerService Thread Pool -- 69) Load config from >>>> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >>>> >>>> >>>> 15:12:34,416 INFO >>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>> >>>> (ServerService Thread Pool -- 69) Updating database >>>> 15:12:35,982 ERROR >>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>> >>>> (ServerService Thread Pool -- 69) Change Set >>>> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >>>> failed. Error: liquibase.exception.CustomChangeException: Update >>>> 1.2.0.Beta1: Exception when updating data from previous version: >>>> liquibase.exception.UnexpectedLiquibaseException: >>>> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception >>>> when updating data from previous version >>>> at >>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >>>> >>>> >>>> at >>>> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >>>> >>>> >>>> at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >>>> at >>>> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >>>> at >>>> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >>>> at liquibase.Liquibase.update(Liquibase.java:200) >>>> at liquibase.Liquibase.update(Liquibase.java:181) >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >>>> >>>> >>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >>>> >>>> >>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >>>> >>>> >>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >>>> >>>> >>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >>>> >>>> >>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >>>> >>>> >>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >>>> >>>> >>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>> [rt.jar:1.7.0_51] >>>> at >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at >>>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>>> [rt.jar:1.7.0_51] >>>> at >>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>>> >>>> >>>> at >>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> 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:471) >>>> [rt.jar:1.7.0_51] >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>>> [rt.jar:1.7.0_51] >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>>> Caused by: liquibase.exception.CustomChangeException: Update >>>> 1.2.0.Beta1: Exception when updating data from previous version >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >>>> >>>> >>>> ... 44 more >>>> Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be >>>> cast to java.lang.Long >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> ... 46 more >>>> >>>> -- >>>> =================================================== >>>> >>>> *Stephen Flynn* >>>> >>>> *Director, JF Technology (UK) Ltd* >>>> >>>> Cell (UK) : +44 7768 003 882 >>>> Phone : +44 20 7833 8346 >>>> IM : xmpp:stephen.flynn at jftechnology.com >>>> IM : aim:stephen.flynn at jftechnology.com >>>> Website : http://www.jftechnology.com >>>> Tech support : support at jftechnology.com >>>> >>>> >>>> =================================================== >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/3c05e222/attachment-0001.html From mposolda at redhat.com Mon Aug 3 11:58:31 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 03 Aug 2015 17:58:31 +0200 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BF8BE4.6040702@jftechnology.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> <55BF800D.4020905@redhat.com> <55BF8078.9090908@redhat.com> <55BF8BE4.6040702@jftechnology.com> Message-ID: <55BF8FA7.3000206@redhat.com> The second issue is already fixed in latest Keycloak master and in 1.4.0.Final sources. That leaves just the BigDecimal issue. So if you fix just the BigDecimal issue in JpaUpdate1_2_0_Beta1.java in 1.4 sources, are you able to upgrade from 1.1.0.Final to 1.4.0.Final ? Thanks, Marek On 3.8.2015 17:42, Stephen Flynn wrote: > > In case this helps... > > I had a quick peek at the source - there were two issues that made > Oracle choke in my environment. First the BigDecimal issue in the > custom change JpaUpdate1_2_0_Beta1.java as initially reported. > Secondly in the custom change JpaUpdate1_2_0_CR1.java there was a > prepared statement that Oracle 10 doesn't like as it expects a boolean > 'TRUE' to be represented by the numerical value '1'. > > I hacked the following two lines and that appears to fix the upgrade > to 1.2.0.Final (for Oracle10 at least). The remaining liquibase > scripts then ran without issue. > > best rgds, > > Steve F. > > > > diff --git > a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java > index 89e7885..895a785 100644 > --- > a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java > +++ > b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java > @@ -293,7 +293,7 @@ > } > > Object acmObj = > resultSet.getObject("ALLOWED_CLAIMS_MASK"); > - long mask = (acmObj != null) ? (Long) acmObj : > ClaimMask.ALL; > + long mask = (acmObj != null) ? ((Number) > acmObj).longValue() : ClaimMask.ALL; > > MigrationProvider migrationProvider = > this.kcSession.getProvider(MigrationProvider.class); > List > protocolMappers = migrationProvider.getMappersForClaimMask(mask); > > > diff --git > a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java > index 5c8a2eb..dbeedf7 100644 > --- > a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java > +++ > b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java > @@ -17,7 +17,7 @@ > String realmClientTableName = > database.correctObjectName("REALM_CLIENT", Table.class); > > try { > - PreparedStatement statement = > jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID > CLIENT_ID from CLIENT where CLIENT.CONSENT_REQUIRED = true"); > + PreparedStatement statement = > jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID > CLIENT_ID from CLIENT where CLIENT.CONSENT_REQUIRED = 1"); > try { > ResultSet resultSet = statement.executeQuery(); > try { > > > =================================================== > > *Stephen Flynn* > > *Director, JF Technology (UK) Ltd* > > Cell (UK) : +44 7768 003 882 > Phone : +44 20 7833 8346 > IM : xmpp:stephen.flynn at jftechnology.com > IM : aim:stephen.flynn at jftechnology.com > Website : http://www.jftechnology.com > Tech support : support at jftechnology.com > > > =================================================== > > On 03/08/2015 15:53, Bill Burke wrote: >> I could do a 1.4.1 when you fix it. >> >> On 8/3/2015 10:51 AM, Marek Posolda wrote: >>> Thanks for the detailed report. I've created JIRA for this and will be >>> fixed for next release https://issues.jboss.org/browse/KEYCLOAK-1725 . >>> >>> Marek >>> >>> On 2.8.2015 15:11, Bill Burke wrote: >>>> You probably have to export your database to json and re-import it >>>> until >>>> we track this down. >>>> >>>> On 8/1/2015 11:19 AM, Stephen Flynn wrote: >>>>> Hi all, >>>>> >>>>> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >>>>> >>>>> The liquibase db scripts are failing. The particular script that is >>>>> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused >>>>> by: java.lang.ClassCastException: java.math.BigDecimal cannot be >>>>> cast to >>>>> java.lang.Long'. More stack trace below. >>>>> >>>>> Any ideas as to why this might be happening ? Is there anything >>>>> else I >>>>> can provide to give more insight ? >>>>> >>>>> best rgds, >>>>> >>>>> Steve F. >>>>> >>>>> >>>>> Environment is... >>>>> >>>>> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >>>>> * jdk1.7.0_51 >>>>> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >>>>> >>>>> >>>>> Liquibase change log from the DB >>>>> >>>>> * 1.0.0.Final sthorger at redhat.com >>>>> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >>>>> 00:55:28.95072 1 EXECUTED >>>>> * 1.1.0.Beta1 sthorger at redhat.com >>>>> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >>>>> 00:55:30.070692 2 EXECUTED >>>>> * 1.1.0.Final sthorger at redhat.com >>>>> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >>>>> 00:55:27.065618 3 EXECUTED >>>>> >>>>> >>>>> Error message in log... >>>>> >>>>> 15:12:31,238 INFO >>>>> [org.keycloak.services.resources.KeycloakApplication] >>>>> (ServerService Thread Pool -- 69) Load config from >>>>> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >>>>> >>>>> >>>>> 15:12:34,416 INFO >>>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>>> >>>>> >>>>> (ServerService Thread Pool -- 69) Updating database >>>>> 15:12:35,982 ERROR >>>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>>> >>>>> >>>>> (ServerService Thread Pool -- 69) Change Set >>>>> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >>>>> >>>>> failed. Error: liquibase.exception.CustomChangeException: Update >>>>> 1.2.0.Beta1: Exception when updating data from previous version: >>>>> liquibase.exception.UnexpectedLiquibaseException: >>>>> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: >>>>> Exception >>>>> when updating data from previous version >>>>> at >>>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >>>>> >>>>> >>>>> at >>>>> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >>>>> >>>>> >>>>> at >>>>> liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >>>>> at >>>>> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >>>>> >>>>> at >>>>> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >>>>> at liquibase.Liquibase.update(Liquibase.java:200) >>>>> at liquibase.Liquibase.update(Liquibase.java:181) >>>>> at >>>>> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >>>>> >>>>> >>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >>>>> >>>>> >>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >>>>> >>>>> >>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >>>>> >>>>> >>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>>> >>>>> >>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >>>>> >>>>> >>>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >>>>> >>>>> >>>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>>> >>>>> >>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >>>>> >>>>> >>>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >>>>> >>>>> >>>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >>>>> >>>>> >>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >>>>> >>>>> >>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >>>>> >>>>> >>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >>>>> >>>>> >>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>>> [rt.jar:1.7.0_51] >>>>> at >>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>>>> >>>>> >>>>> [rt.jar:1.7.0_51] >>>>> at >>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>> >>>>> >>>>> [rt.jar:1.7.0_51] >>>>> at >>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>>>> [rt.jar:1.7.0_51] >>>>> at >>>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >>>>> >>>>> >>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>> at >>>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >>>>> >>>>> >>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>> at >>>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >>>>> >>>>> >>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>> at >>>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >>>>> >>>>> >>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >>>>> >>>>> >>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>>>> >>>>> >>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>> at >>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>>>> >>>>> >>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>> at >>>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>>>> >>>>> >>>>> at >>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>>>> >>>>> >>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>> at >>>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >>>>> >>>>> >>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>> at >>>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >>>>> >>>>> >>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>> at >>>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >>>>> >>>>> >>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>> 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:471) >>>>> >>>>> [rt.jar:1.7.0_51] >>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>>>> [rt.jar:1.7.0_51] >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>> >>>>> >>>>> [rt.jar:1.7.0_51] >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>> >>>>> >>>>> [rt.jar:1.7.0_51] >>>>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>>>> Caused by: liquibase.exception.CustomChangeException: Update >>>>> 1.2.0.Beta1: Exception when updating data from previous version >>>>> at >>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >>>>> >>>>> >>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >>>>> >>>>> >>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >>>>> >>>>> >>>>> ... 44 more >>>>> Caused by: java.lang.ClassCastException: java.math.BigDecimal >>>>> cannot be >>>>> cast to java.lang.Long >>>>> at >>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >>>>> >>>>> >>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>> at >>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >>>>> >>>>> >>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>> ... 46 more >>>>> >>>>> -- >>>>> =================================================== >>>>> >>>>> *Stephen Flynn* >>>>> >>>>> *Director, JF Technology (UK) Ltd* >>>>> >>>>> Cell (UK) : +44 7768 003 882 >>>>> Phone : +44 20 7833 8346 >>>>> IM : xmpp:stephen.flynn at jftechnology.com >>>>> IM : aim:stephen.flynn at jftechnology.com >>>>> Website : http://www.jftechnology.com >>>>> Tech support : support at jftechnology.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/3f9b5426/attachment-0001.html From stephen.flynn at jftechnology.com Mon Aug 3 12:22:01 2015 From: stephen.flynn at jftechnology.com (Stephen Flynn) Date: Mon, 3 Aug 2015 17:22:01 +0100 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BF8FA7.3000206@redhat.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> <55BF800D.4020905@redhat.com> <55BF8078.9090908@redhat.com> <55BF8BE4.6040702@jftechnology.com> <55BF8FA7.3000206@redhat.com> Message-ID: <55BF9529.7080308@jftechnology.com> Hi Marek, I ran the upgrades incrementally (1.1.0.Final to 1.2.0.Final, 1.2.0.Final to 1.3.1.Final,etc) and fixed both issues in the 1.2.0.Final source after which everything ran smoothly. So I can't say that I'm 100% sure that a single upgrade from 1.1.0.Final to 1.4.0.Final would work if you fixed the BigDecimal issue in the 1.4.0.Final source - but, without trying it out, I would be very surprised if it didn't work fine (assuming the second issue is fixed already). BTW - both issues will also break upgradesfrom 1.1.0.Final to 1.2.0.Final and 1.3.1.Final (against Oracle) and, though I haven't explicitly tested it, I would very surprised if the second issue doesn't break fresh installs of1.2.0.Final and 1.3.1.Final as well. best rgds, Steve F. =================================================== *Stephen Flynn* *Director, JF Technology (UK) Ltd* Cell (UK) : +44 7768 003 882 Phone : +44 20 7833 8346 IM : xmpp:stephen.flynn at jftechnology.com IM : aim:stephen.flynn at jftechnology.com Website : http://www.jftechnology.com Tech support : support at jftechnology.com =================================================== On 03/08/2015 16:58, Marek Posolda wrote: > The second issue is already fixed in latest Keycloak master and in 1.4.0.Final > sources. That leaves just the BigDecimal issue. So if you fix just the > BigDecimal issue in JpaUpdate1_2_0_Beta1.java in 1.4 sources, are you able to > upgrade from 1.1.0.Final to 1.4.0.Final ? > > Thanks, > Marek > > On 3.8.2015 17:42, Stephen Flynn wrote: >> >> In case this helps... >> >> I had a quick peek at the source - there were two issues that made Oracle >> choke in my environment. First the BigDecimal issue in the custom change >> JpaUpdate1_2_0_Beta1.java as initially reported. Secondly in the custom >> change JpaUpdate1_2_0_CR1.java there was a prepared statement that Oracle 10 >> doesn't like as it expects a boolean 'TRUE' to be represented by the >> numerical value '1'. >> >> I hacked the following two lines and that appears to fix the upgrade to >> 1.2.0.Final (for Oracle10 at least). The remaining liquibase scripts then ran >> without issue. >> >> best rgds, >> >> Steve F. >> >> >> >> diff --git >> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java >> index 89e7885..895a785 100644 >> --- >> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java >> +++ >> b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java >> @@ -293,7 +293,7 @@ >> } >> >> Object acmObj = resultSet.getObject("ALLOWED_CLAIMS_MASK"); >> - long mask = (acmObj != null) ? (Long) acmObj : >> ClaimMask.ALL; >> + long mask = (acmObj != null) ? ((Number) >> acmObj).longValue() : ClaimMask.ALL; >> >> MigrationProvider migrationProvider = >> this.kcSession.getProvider(MigrationProvider.class); >> List protocolMappers = >> migrationProvider.getMappersForClaimMask(mask); >> >> >> diff --git >> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java >> index 5c8a2eb..dbeedf7 100644 >> --- >> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java >> +++ >> b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java >> @@ -17,7 +17,7 @@ >> String realmClientTableName = >> database.correctObjectName("REALM_CLIENT", Table.class); >> >> try { >> - PreparedStatement statement = >> jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID CLIENT_ID >> from CLIENT where CLIENT.CONSENT_REQUIRED = true"); >> + PreparedStatement statement = >> jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID CLIENT_ID >> from CLIENT where CLIENT.CONSENT_REQUIRED = 1"); >> try { >> ResultSet resultSet = statement.executeQuery(); >> try { >> >> >> =================================================== >> >> *Stephen Flynn* >> >> *Director, JF Technology (UK) Ltd* >> >> Cell (UK) : +44 7768 003 882 >> Phone : +44 20 7833 8346 >> IM : xmpp:stephen.flynn at jftechnology.com >> IM : aim:stephen.flynn at jftechnology.com >> Website : http://www.jftechnology.com >> Tech support : support at jftechnology.com >> >> =================================================== >> >> On 03/08/2015 15:53, Bill Burke wrote: >>> I could do a 1.4.1 when you fix it. >>> >>> On 8/3/2015 10:51 AM, Marek Posolda wrote: >>>> Thanks for the detailed report. I've created JIRA for this and will be >>>> fixed for next release https://issues.jboss.org/browse/KEYCLOAK-1725 . >>>> >>>> Marek >>>> >>>> On 2.8.2015 15:11, Bill Burke wrote: >>>>> You probably have to export your database to json and re-import it until >>>>> we track this down. >>>>> >>>>> On 8/1/2015 11:19 AM, Stephen Flynn wrote: >>>>>> Hi all, >>>>>> >>>>>> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >>>>>> >>>>>> The liquibase db scripts are failing. The particular script that is >>>>>> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused >>>>>> by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to >>>>>> java.lang.Long'. More stack trace below. >>>>>> >>>>>> Any ideas as to why this might be happening ? Is there anything else I >>>>>> can provide to give more insight ? >>>>>> >>>>>> best rgds, >>>>>> >>>>>> Steve F. >>>>>> >>>>>> >>>>>> Environment is... >>>>>> >>>>>> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >>>>>> * jdk1.7.0_51 >>>>>> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >>>>>> >>>>>> >>>>>> Liquibase change log from the DB >>>>>> >>>>>> * 1.0.0.Final sthorger at redhat.com >>>>>> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >>>>>> 00:55:28.95072 1 EXECUTED >>>>>> * 1.1.0.Beta1 sthorger at redhat.com >>>>>> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >>>>>> 00:55:30.070692 2 EXECUTED >>>>>> * 1.1.0.Final sthorger at redhat.com >>>>>> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >>>>>> 00:55:27.065618 3 EXECUTED >>>>>> >>>>>> >>>>>> Error message in log... >>>>>> >>>>>> 15:12:31,238 INFO [org.keycloak.services.resources.KeycloakApplication] >>>>>> (ServerService Thread Pool -- 69) Load config from >>>>>> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >>>>>> >>>>>> >>>>>> 15:12:34,416 INFO >>>>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>>>> >>>>>> (ServerService Thread Pool -- 69) Updating database >>>>>> 15:12:35,982 ERROR >>>>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>>>> >>>>>> (ServerService Thread Pool -- 69) Change Set >>>>>> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >>>>>> failed. Error: liquibase.exception.CustomChangeException: Update >>>>>> 1.2.0.Beta1: Exception when updating data from previous version: >>>>>> liquibase.exception.UnexpectedLiquibaseException: >>>>>> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception >>>>>> when updating data from previous version >>>>>> at >>>>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >>>>>> >>>>>> >>>>>> at >>>>>> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >>>>>> >>>>>> >>>>>> at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >>>>>> at >>>>>> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >>>>>> at >>>>>> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >>>>>> at liquibase.Liquibase.update(Liquibase.java:200) >>>>>> at liquibase.Liquibase.update(Liquibase.java:181) >>>>>> at >>>>>> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>>>> >>>>>> >>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >>>>>> >>>>>> >>>>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >>>>>> >>>>>> >>>>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>>>> >>>>>> >>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >>>>>> >>>>>> >>>>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >>>>>> >>>>>> >>>>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >>>>>> >>>>>> >>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >>>>>> >>>>>> >>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >>>>>> >>>>>> >>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >>>>>> >>>>>> >>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>>>> [rt.jar:1.7.0_51] >>>>>> at >>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>>>>> >>>>>> >>>>>> [rt.jar:1.7.0_51] >>>>>> at >>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>>> >>>>>> >>>>>> [rt.jar:1.7.0_51] >>>>>> at >>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>>>>> [rt.jar:1.7.0_51] >>>>>> at >>>>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >>>>>> >>>>>> >>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>> at >>>>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >>>>>> >>>>>> >>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>> at >>>>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >>>>>> >>>>>> >>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>> at >>>>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >>>>>> >>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>> at >>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >>>>>> >>>>>> >>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>> at >>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>>>>> >>>>>> >>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>> at >>>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>>>>> >>>>>> >>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>> at >>>>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>>>>> >>>>>> >>>>>> at >>>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>>>>> >>>>>> >>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>> at >>>>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >>>>>> >>>>>> >>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>> at >>>>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >>>>>> >>>>>> >>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>> at >>>>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >>>>>> >>>>>> >>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>> 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:471) >>>>>> [rt.jar:1.7.0_51] >>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>>>>> [rt.jar:1.7.0_51] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>> >>>>>> >>>>>> [rt.jar:1.7.0_51] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>> >>>>>> >>>>>> [rt.jar:1.7.0_51] >>>>>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>>>>> Caused by: liquibase.exception.CustomChangeException: Update >>>>>> 1.2.0.Beta1: Exception when updating data from previous version >>>>>> at >>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >>>>>> >>>>>> >>>>>> ... 44 more >>>>>> Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be >>>>>> cast to java.lang.Long >>>>>> at >>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>> at >>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >>>>>> >>>>>> >>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>> ... 46 more >>>>>> >>>>>> -- >>>>>> =================================================== >>>>>> >>>>>> *Stephen Flynn* >>>>>> >>>>>> *Director, JF Technology (UK) Ltd* >>>>>> >>>>>> Cell (UK) : +44 7768 003 882 >>>>>> Phone : +44 20 7833 8346 >>>>>> IM : xmpp:stephen.flynn at jftechnology.com >>>>>> IM : aim:stephen.flynn at jftechnology.com >>>>>> Website : http://www.jftechnology.com >>>>>> Tech support : support at jftechnology.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/5fb46c56/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: stephen_flynn.vcf Type: text/x-vcard Size: 233 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150803/5fb46c56/attachment-0001.vcf From jayblanc at gmail.com Tue Aug 4 05:50:20 2015 From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=) Date: Tue, 04 Aug 2015 09:50:20 +0000 Subject: [keycloak-user] Docker Keycloak for version 1.4.1 not pushed to docker hub Message-ID: Hi, I'm trying to use keycloak in a docker and I'm facing an import realm problem. I have exported my keycloak realm from version 1.4.0.Final but it conflict in the docker when I import. If I run the docker container jboss/keycloak-postgres alone and ask for version information in the UI, it show 1.3.1.Final. Stian, did you pushed your new images to docker hub for the 1.4.1 ? I see your github push for this new version but it seems when I pull the docker image I still have an old version ? Best regards and congratulation for this great docker packaging which really helps us, J?r?me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150804/65c30868/attachment.html From mposolda at redhat.com Tue Aug 4 06:39:55 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 04 Aug 2015 12:39:55 +0200 Subject: [keycloak-user] Error during LDAP syncing on Keycloak 1.4.0 In-Reply-To: References: Message-ID: <55C0967B.7070500@redhat.com> Hi, this means that some of your LDAP user record doesn't have the attribute, which you mapped as "Username LDAP Attribute" in the admin console. For example if you configured "Username LDAP Attribute" as "cn" and some of your LDAP user doesn't have "cn" . I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-1728 and have a fix, which will be available in 1.5 . The fix will give you better error message and won't break whole sync process with NPE, but just won't import the incorrect user, which has missing attribute. Until that, you can either fix LDAP user records in your LDAP server to contain the missing attribute, or you can configure "Username LDAP Attribute" to different value. Marek On 29.7.2015 11:10, Nair, Rajat wrote: > > Hi, > > As part of testing another issue (Distributed Keycloak user sessions > using Infinispan), I upgraded my nodes to Keycloak 1.4.0 (grabbed > release from here - > http://central.maven.org/maven2/org/keycloak/keycloak-server-dist/1.4.0.Final/keycloak-server-dist-1.4.0.Final.tar.gz). > I wiped out our Keycloak database and recreated it. After configuring > our LDAP server (similar configuration which worked against Keycloak > 1.3.1 Final), when we try to sync users we get following exception ? > > 2015-07-29 09:00:42,062 ERROR [io.undertow.request] (default task-25) > UT005023: Exception handling request to > /auth/admin/realms/test/user-federation/instances/3ccbe831-2d9b-4253-8fe7-343d7ead505d/sync: > java.lang.RuntimeException: request path: > /auth/admin/realms/test/user-federation/instances/3ccbe831-2d9b-4253-8fe7-343d7ead505d/sync > > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:73) > > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > > 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:58) > > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > > 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:282) > > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > > at java.lang.Thread.run(Unknown Source) > > Caused by: org.jboss.resteasy.spi.UnhandledException: > java.lang.NullPointerException > > at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) > > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) > > 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:86) > > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) > > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:59) > > ... 29 more > > Caused by: java.lang.NullPointerException > > at > org.keycloak.models.cache.DefaultCacheUserProvider.getUserByUsername(DefaultCacheUserProvider.java:149) > > at > org.keycloak.federation.ldap.LDAPFederationProviderFactory$2.run(LDAPFederationProviderFactory.java:294) > > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:242) > > at > org.keycloak.federation.ldap.LDAPFederationProviderFactory.importLdapUsers(LDAPFederationProviderFactory.java:286) > > at > org.keycloak.federation.ldap.LDAPFederationProviderFactory.syncImpl(LDAPFederationProviderFactory.java:241) > > at > org.keycloak.federation.ldap.LDAPFederationProviderFactory.syncAllUsers(LDAPFederationProviderFactory.java:200) > > at > org.keycloak.services.managers.UsersSyncManager.syncAllUsers(UsersSyncManager.java:50) > > at > org.keycloak.services.resources.admin.UserFederationProviderResource.syncUsers(UserFederationProviderResource.java:143) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > > at java.lang.reflect.Method.invoke(Unknown Source) > > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) > > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) > > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) > > ... 37 more > > Could this be a regression? > > -- Rajat > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150804/e680a86d/attachment-0001.html From rajat.nair at hp.com Tue Aug 4 06:44:50 2015 From: rajat.nair at hp.com (Nair, Rajat) Date: Tue, 4 Aug 2015 10:44:50 +0000 Subject: [keycloak-user] Error during LDAP syncing on Keycloak 1.4.0 In-Reply-To: <55C0967B.7070500@redhat.com> References: <55C0967B.7070500@redhat.com> Message-ID: Thanks for the update Marek. We changed the LDAP attribute to another value and that got sync working. -- Rajat From: Marek Posolda [mailto:mposolda at redhat.com] Sent: 04 August 2015 16:10 To: Nair, Rajat; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Error during LDAP syncing on Keycloak 1.4.0 Hi, this means that some of your LDAP user record doesn't have the attribute, which you mapped as "Username LDAP Attribute" in the admin console. For example if you configured "Username LDAP Attribute" as "cn" and some of your LDAP user doesn't have "cn" . I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-1728 and have a fix, which will be available in 1.5 . The fix will give you better error message and won't break whole sync process with NPE, but just won't import the incorrect user, which has missing attribute. Until that, you can either fix LDAP user records in your LDAP server to contain the missing attribute, or you can configure "Username LDAP Attribute" to different value. Marek On 29.7.2015 11:10, Nair, Rajat wrote: Hi, As part of testing another issue (Distributed Keycloak user sessions using Infinispan), I upgraded my nodes to Keycloak 1.4.0 (grabbed release from here - http://central.maven.org/maven2/org/keycloak/keycloak-server-dist/1.4.0.Final/keycloak-server-dist-1.4.0.Final.tar.gz). I wiped out our Keycloak database and recreated it. After configuring our LDAP server (similar configuration which worked against Keycloak 1.3.1 Final), when we try to sync users we get following exception - 2015-07-29 09:00:42,062 ERROR [io.undertow.request] (default task-25) UT005023: Exception handling request to /auth/admin/realms/test/user-federation/instances/3ccbe831-2d9b-4253-8fe7-343d7ead505d/sync: java.lang.RuntimeException: request path: /auth/admin/realms/test/user-federation/instances/3ccbe831-2d9b-4253-8fe7-343d7ead505d/sync at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:73) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) 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:58) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) 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:282) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) 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:86) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:59) ... 29 more Caused by: java.lang.NullPointerException at org.keycloak.models.cache.DefaultCacheUserProvider.getUserByUsername(DefaultCacheUserProvider.java:149) at org.keycloak.federation.ldap.LDAPFederationProviderFactory$2.run(LDAPFederationProviderFactory.java:294) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:242) at org.keycloak.federation.ldap.LDAPFederationProviderFactory.importLdapUsers(LDAPFederationProviderFactory.java:286) at org.keycloak.federation.ldap.LDAPFederationProviderFactory.syncImpl(LDAPFederationProviderFactory.java:241) at org.keycloak.federation.ldap.LDAPFederationProviderFactory.syncAllUsers(LDAPFederationProviderFactory.java:200) at org.keycloak.services.managers.UsersSyncManager.syncAllUsers(UsersSyncManager.java:50) at org.keycloak.services.resources.admin.UserFederationProviderResource.syncUsers(UserFederationProviderResource.java:143) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) ... 37 more Could this be a regression? -- Rajat _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150804/db43d02b/attachment-0001.html From mposolda at redhat.com Tue Aug 4 08:20:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 04 Aug 2015 14:20:17 +0200 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BF9529.7080308@jftechnology.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> <55BF800D.4020905@redhat.com> <55BF8078.9090908@redhat.com> <55BF8BE4.6040702@jftechnology.com> <55BF8FA7.3000206@redhat.com> <55BF9529.7080308@jftechnology.com> Message-ID: <55C0AE01.5000104@redhat.com> On 3.8.2015 18:22, Stephen Flynn wrote: > > Hi Marek, > > I ran the upgrades incrementally (1.1.0.Final to 1.2.0.Final, > 1.2.0.Final to 1.3.1.Final,etc) and fixed both issues in the > 1.2.0.Final source after which everything ran smoothly. > > So I can't say that I'm 100% sure that a single upgrade from > 1.1.0.Final to 1.4.0.Final would work if you fixed the BigDecimal > issue in the 1.4.0.Final source - but, without trying it out, I would > be very surprised if it didn't work fine (assuming the second issue is > fixed already). Yeah, I agree. I've applied the fix, so migration from 1.1.0 to 1.5.0 will be hopefully fine without need to do patches and incremental upgrades etc. Thanks for nailing it down! > > BTW - both issues will also break upgradesfrom 1.1.0.Final to > 1.2.0.Final and 1.3.1.Final (against Oracle) and, though I haven't > explicitly tested it, I would very surprised if the second issue > doesn't break fresh installs of1.2.0.Final and 1.3.1.Final as well. Fresh install of 1.2.0 or 1.3.1 or 1.4.0 should be fine. We are testing Oracle during each release, but for this test we always start with the empty database. We don't have the migration test for Oracle (testing the DB correctly migrated from previous version during upgrade). Marek > > best rgds, > > Steve F. > > > > =================================================== > > *Stephen Flynn* > > *Director, JF Technology (UK) Ltd* > > Cell (UK) : +44 7768 003 882 > Phone : +44 20 7833 8346 > IM : xmpp:stephen.flynn at jftechnology.com > IM : aim:stephen.flynn at jftechnology.com > Website : http://www.jftechnology.com > Tech support : support at jftechnology.com > > > =================================================== > > On 03/08/2015 16:58, Marek Posolda wrote: >> The second issue is already fixed in latest Keycloak master and in >> 1.4.0.Final sources. That leaves just the BigDecimal issue. So if you >> fix just the BigDecimal issue in JpaUpdate1_2_0_Beta1.java in 1.4 >> sources, are you able to upgrade from 1.1.0.Final to 1.4.0.Final ? >> >> Thanks, >> Marek >> >> On 3.8.2015 17:42, Stephen Flynn wrote: >>> >>> In case this helps... >>> >>> I had a quick peek at the source - there were two issues that made >>> Oracle choke in my environment. First the BigDecimal issue in the >>> custom change JpaUpdate1_2_0_Beta1.java as initially reported. >>> Secondly in the custom change JpaUpdate1_2_0_CR1.java there was a >>> prepared statement that Oracle 10 doesn't like as it expects a >>> boolean 'TRUE' to be represented by the numerical value '1'. >>> >>> I hacked the following two lines and that appears to fix the upgrade >>> to 1.2.0.Final (for Oracle10 at least). The remaining liquibase >>> scripts then ran without issue. >>> >>> best rgds, >>> >>> Steve F. >>> >>> >>> >>> diff --git >>> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java >>> index 89e7885..895a785 100644 >>> --- >>> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java >>> +++ >>> b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_Beta1.java >>> @@ -293,7 +293,7 @@ >>> } >>> >>> Object acmObj = >>> resultSet.getObject("ALLOWED_CLAIMS_MASK"); >>> - long mask = (acmObj != null) ? (Long) acmObj : >>> ClaimMask.ALL; >>> + long mask = (acmObj != null) ? ((Number) >>> acmObj).longValue() : ClaimMask.ALL; >>> >>> MigrationProvider migrationProvider = >>> this.kcSession.getProvider(MigrationProvider.class); >>> List >>> protocolMappers = migrationProvider.getMappersForClaimMask(mask); >>> >>> >>> diff --git >>> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.javab/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java >>> index 5c8a2eb..dbeedf7 100644 >>> --- >>> a/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java >>> +++ >>> b/connections/jpa-liquibase/src/main/java/org/keycloak/connections/jpa/updater/liquibase/custom/JpaUpdate1_2_0_CR1.java >>> @@ -17,7 +17,7 @@ >>> String realmClientTableName = >>> database.correctObjectName("REALM_CLIENT", Table.class); >>> >>> try { >>> - PreparedStatement statement = >>> jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID >>> CLIENT_ID from CLIENT where CLIENT.CONSENT_REQUIRED = true"); >>> + PreparedStatement statement = >>> jdbcConnection.prepareStatement("select CLIENT.REALM_ID, CLIENT.ID >>> CLIENT_ID from CLIENT where CLIENT.CONSENT_REQUIRED = 1"); >>> try { >>> ResultSet resultSet = statement.executeQuery(); >>> try { >>> >>> >>> =================================================== >>> >>> *Stephen Flynn* >>> >>> *Director, JF Technology (UK) Ltd* >>> >>> Cell (UK) : +44 7768 003 882 >>> Phone : +44 20 7833 8346 >>> IM : xmpp:stephen.flynn at jftechnology.com >>> IM : aim:stephen.flynn at jftechnology.com >>> Website : http://www.jftechnology.com >>> Tech support : support at jftechnology.com >>> >>> >>> =================================================== >>> >>> On 03/08/2015 15:53, Bill Burke wrote: >>>> I could do a 1.4.1 when you fix it. >>>> >>>> On 8/3/2015 10:51 AM, Marek Posolda wrote: >>>>> Thanks for the detailed report. I've created JIRA for this and >>>>> will be >>>>> fixed for next release >>>>> https://issues.jboss.org/browse/KEYCLOAK-1725 . >>>>> >>>>> Marek >>>>> >>>>> On 2.8.2015 15:11, Bill Burke wrote: >>>>>> You probably have to export your database to json and re-import >>>>>> it until >>>>>> we track this down. >>>>>> >>>>>> On 8/1/2015 11:19 AM, Stephen Flynn wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >>>>>>> >>>>>>> The liquibase db scripts are failing. The particular script that is >>>>>>> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception >>>>>>> 'Caused >>>>>>> by: java.lang.ClassCastException: java.math.BigDecimal cannot be >>>>>>> cast to >>>>>>> java.lang.Long'. More stack trace below. >>>>>>> >>>>>>> Any ideas as to why this might be happening ? Is there anything >>>>>>> else I >>>>>>> can provide to give more insight ? >>>>>>> >>>>>>> best rgds, >>>>>>> >>>>>>> Steve F. >>>>>>> >>>>>>> >>>>>>> Environment is... >>>>>>> >>>>>>> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >>>>>>> * jdk1.7.0_51 >>>>>>> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >>>>>>> >>>>>>> >>>>>>> Liquibase change log from the DB >>>>>>> >>>>>>> * 1.0.0.Final sthorger at redhat.com >>>>>>> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >>>>>>> 00:55:28.95072 1 EXECUTED >>>>>>> * 1.1.0.Beta1 sthorger at redhat.com >>>>>>> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >>>>>>> 00:55:30.070692 2 EXECUTED >>>>>>> * 1.1.0.Final sthorger at redhat.com >>>>>>> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >>>>>>> 00:55:27.065618 3 EXECUTED >>>>>>> >>>>>>> >>>>>>> Error message in log... >>>>>>> >>>>>>> 15:12:31,238 INFO >>>>>>> [org.keycloak.services.resources.KeycloakApplication] >>>>>>> (ServerService Thread Pool -- 69) Load config from >>>>>>> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >>>>>>> >>>>>>> >>>>>>> 15:12:34,416 INFO >>>>>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>>>>> >>>>>>> >>>>>>> (ServerService Thread Pool -- 69) Updating database >>>>>>> 15:12:35,982 ERROR >>>>>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>>>>> >>>>>>> >>>>>>> (ServerService Thread Pool -- 69) Change Set >>>>>>> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >>>>>>> >>>>>>> failed. Error: liquibase.exception.CustomChangeException: Update >>>>>>> 1.2.0.Beta1: Exception when updating data from previous version: >>>>>>> liquibase.exception.UnexpectedLiquibaseException: >>>>>>> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: >>>>>>> Exception >>>>>>> when updating data from previous version >>>>>>> at >>>>>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >>>>>>> at >>>>>>> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >>>>>>> >>>>>>> at >>>>>>> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >>>>>>> >>>>>>> at liquibase.Liquibase.update(Liquibase.java:200) >>>>>>> at liquibase.Liquibase.update(Liquibase.java:181) >>>>>>> at >>>>>>> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>>>>> >>>>>>> >>>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >>>>>>> >>>>>>> >>>>>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >>>>>>> >>>>>>> >>>>>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>>>>> >>>>>>> >>>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >>>>>>> >>>>>>> >>>>>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >>>>>>> >>>>>>> >>>>>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >>>>>>> >>>>>>> >>>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >>>>>>> >>>>>>> >>>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >>>>>>> >>>>>>> >>>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >>>>>>> >>>>>>> >>>>>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>>>> Method) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>>>>>> >>>>>>> >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>>>> >>>>>>> >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >>>>>>> >>>>>>> >>>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>>> at >>>>>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >>>>>>> >>>>>>> >>>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>>> at >>>>>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >>>>>>> >>>>>>> >>>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>>> at >>>>>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >>>>>>> >>>>>>> >>>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>>> at >>>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >>>>>>> >>>>>>> >>>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>>> at >>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>>>>>> >>>>>>> >>>>>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>>>>> at >>>>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>>>>>> >>>>>>> >>>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>>> at >>>>>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>>>>>> >>>>>>> >>>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>>> at >>>>>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >>>>>>> >>>>>>> >>>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>>> at >>>>>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >>>>>>> >>>>>>> >>>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>>> at >>>>>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >>>>>>> >>>>>>> >>>>>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>>>>> 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:471) >>>>>>> >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> java.util.concurrent.FutureTask.run(FutureTask.java:262) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>>>>> >>>>>>> >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>>>>> >>>>>>> >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at java.lang.Thread.run(Thread.java:744) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at >>>>>>> org.jboss.threads.JBossThread.run(JBossThread.java:320) >>>>>>> Caused by: liquibase.exception.CustomChangeException: Update >>>>>>> 1.2.0.Beta1: Exception when updating data from previous version >>>>>>> at >>>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >>>>>>> >>>>>>> >>>>>>> ... 44 more >>>>>>> Caused by: java.lang.ClassCastException: java.math.BigDecimal >>>>>>> cannot be >>>>>>> cast to java.lang.Long >>>>>>> at >>>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>>> at >>>>>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >>>>>>> >>>>>>> >>>>>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>>>>> ... 46 more >>>>>>> >>>>>>> -- >>>>>>> =================================================== >>>>>>> >>>>>>> *Stephen Flynn* >>>>>>> >>>>>>> *Director, JF Technology (UK) Ltd* >>>>>>> >>>>>>> Cell (UK) : +44 7768 003 882 >>>>>>> Phone : +44 20 7833 8346 >>>>>>> IM : xmpp:stephen.flynn at jftechnology.com >>>>>>> IM : aim:stephen.flynn at jftechnology.com >>>>>>> Website : http://www.jftechnology.com >>>>>>> Tech support : support at jftechnology.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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150804/bd7c8f6f/attachment-0001.html From mposolda at redhat.com Tue Aug 4 08:36:47 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 04 Aug 2015 14:36:47 +0200 Subject: [keycloak-user] Upgrade from 1.1.0.Final to 1.4.0.Final - Liquibase script failing In-Reply-To: <55BF8078.9090908@redhat.com> References: <55BCE38C.5090805@jftechnology.com> <55BE16EE.6070006@redhat.com> <55BF800D.4020905@redhat.com> <55BF8078.9090908@redhat.com> Message-ID: <55C0B1DF.1040600@redhat.com> Fix is in master, but not sure if 1.4.1 release is still needed? Stephen managed to migrate his DB and I can see that master already contains quite a lot of other changes. Marek On 3.8.2015 16:53, Bill Burke wrote: > I could do a 1.4.1 when you fix it. > > On 8/3/2015 10:51 AM, Marek Posolda wrote: >> Thanks for the detailed report. I've created JIRA for this and will be >> fixed for next release https://issues.jboss.org/browse/KEYCLOAK-1725 . >> >> Marek >> >> On 2.8.2015 15:11, Bill Burke wrote: >>> You probably have to export your database to json and re-import it >>> until >>> we track this down. >>> >>> On 8/1/2015 11:19 AM, Stephen Flynn wrote: >>>> Hi all, >>>> >>>> I'm trying to upgrade Keycloak from 1.1.0.Final to 1.4.0.Final. >>>> >>>> The liquibase db scripts are failing. The particular script that is >>>> failing is 'jpa-changelog-1.2.0.Beta1.xml' with the exception 'Caused >>>> by: java.lang.ClassCastException: java.math.BigDecimal cannot be >>>> cast to >>>> java.lang.Long'. More stack trace below. >>>> >>>> Any ideas as to why this might be happening ? Is there anything else I >>>> can provide to give more insight ? >>>> >>>> best rgds, >>>> >>>> Steve F. >>>> >>>> >>>> Environment is... >>>> >>>> * wildfly-9.0.1.Final + keycloak-overlay-1.4.0.Final >>>> * jdk1.7.0_51 >>>> * Oracle 10 + odbcj6.jar (11.2.0.2.0) >>>> >>>> >>>> Liquibase change log from the DB >>>> >>>> * 1.0.0.Final sthorger at redhat.com >>>> META-INF/jpa-changelog-1.0.0.Final.xml 2014-12-04 >>>> 00:55:28.95072 1 EXECUTED >>>> * 1.1.0.Beta1 sthorger at redhat.com >>>> META-INF/jpa-changelog-1.1.0.Beta1.xml 2014-12-04 >>>> 00:55:30.070692 2 EXECUTED >>>> * 1.1.0.Final sthorger at redhat.com >>>> META-INF/jpa-changelog-1.1.0.Final.xml 2015-01-30 >>>> 00:55:27.065618 3 EXECUTED >>>> >>>> >>>> Error message in log... >>>> >>>> 15:12:31,238 INFO >>>> [org.keycloak.services.resources.KeycloakApplication] >>>> (ServerService Thread Pool -- 69) Load config from >>>> /apps/wildfly/wildfly-9.0.1.Final/standalone/configuration/keycloak-server.json >>>> >>>> >>>> 15:12:34,416 INFO >>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>> >>>> >>>> (ServerService Thread Pool -- 69) Updating database >>>> 15:12:35,982 ERROR >>>> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] >>>> >>>> >>>> (ServerService Thread Pool -- 69) Change Set >>>> META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com >>>> failed. Error: liquibase.exception.CustomChangeException: Update >>>> 1.2.0.Beta1: Exception when updating data from previous version: >>>> liquibase.exception.UnexpectedLiquibaseException: >>>> liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: >>>> Exception >>>> when updating data from previous version >>>> at >>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) >>>> >>>> >>>> at >>>> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) >>>> >>>> >>>> at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) >>>> at >>>> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) >>>> at >>>> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) >>>> at liquibase.Liquibase.update(Liquibase.java:200) >>>> at liquibase.Liquibase.update(Liquibase.java:181) >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:150) >>>> >>>> >>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:39) >>>> >>>> >>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:27) >>>> >>>> >>>> [keycloak-connections-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) >>>> >>>> >>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) >>>> >>>> >>>> [keycloak-model-jpa-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) >>>> >>>> >>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >>>> >>>> >>>> [keycloak-invalidation-cache-model-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) >>>> >>>> >>>> [keycloak-services-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>> [rt.jar:1.7.0_51] >>>> at >>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at >>>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>>> [rt.jar:1.7.0_51] >>>> at >>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>>> >>>> >>>> [resteasy-jaxrs-3.0.11.Final.jar:] >>>> at >>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) >>>> >>>> >>>> at >>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> at >>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) >>>> >>>> >>>> [undertow-servlet-1.2.9.Final.jar:1.2.9.Final] >>>> 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:471) >>>> >>>> [rt.jar:1.7.0_51] >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>>> [rt.jar:1.7.0_51] >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> >>>> >>>> [rt.jar:1.7.0_51] >>>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] >>>> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>>> Caused by: liquibase.exception.CustomChangeException: Update >>>> 1.2.0.Beta1: Exception when updating data from previous version >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) >>>> >>>> >>>> ... 44 more >>>> Caused by: java.lang.ClassCastException: java.math.BigDecimal >>>> cannot be >>>> cast to java.lang.Long >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> at >>>> org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) >>>> >>>> >>>> [keycloak-connections-jpa-liquibase-1.4.0.Final.jar:1.4.0.Final] >>>> ... 46 more >>>> >>>> -- >>>> =================================================== >>>> >>>> *Stephen Flynn* >>>> >>>> *Director, JF Technology (UK) Ltd* >>>> >>>> Cell (UK) : +44 7768 003 882 >>>> Phone : +44 20 7833 8346 >>>> IM : xmpp:stephen.flynn at jftechnology.com >>>> IM : aim:stephen.flynn at jftechnology.com >>>> Website : http://www.jftechnology.com >>>> Tech support : support at jftechnology.com >>>> >>>> >>>> =================================================== >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >> > From mstrukel at redhat.com Tue Aug 4 08:59:25 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Tue, 4 Aug 2015 08:59:25 -0400 (EDT) Subject: [keycloak-user] Docker Keycloak for version 1.4.1 not pushed to docker hub In-Reply-To: References: Message-ID: <887618838.6271039.1438693165047.JavaMail.zimbra@redhat.com> Keycloak 1.4.0.Final hasn't been published to Docker yet, but it will be shortly ... In the mean time you can try build docker images yourself: git clone https://github.com/jboss-dockerfiles/keycloak.git keycloak-docker cd keycloak-docker git checkout 1.4.0.Final cd server docker build --tag jboss/keycloak:1.4.0.Final . cd ../server-postgres docker build --tag jboss/keycloak-postgres:1.4.0.Final . You can then run it: docker run --name keycloak -ti --link postgres:postgres jboss/keycloak-postgres:1.4.0.Final ----- Original Message ----- > Hi, > I'm trying to use keycloak in a docker and I'm facing an import realm > problem. I have exported my keycloak realm from version 1.4.0.Final but it > conflict in the docker when I import. If I run the docker container > jboss/keycloak-postgres alone and ask for version information in the UI, it > show 1.3.1.Final. > Stian, did you pushed your new images to docker hub for the 1.4.1 ? > I see your github push for this new version but it seems when I pull the > docker image I still have an old version ? > > Best regards and congratulation for this great docker packaging which really > helps us, J?r?me. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From juraci at kroehling.de Tue Aug 4 10:44:53 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 4 Aug 2015 16:44:53 +0200 Subject: [keycloak-user] WebSockets Message-ID: <55C0CFE5.3080108@kroehling.de> I'm currently looking into the best way to perform authentication for WebSockets, and it seems that the best (only?) option so far is to handle this on the socket's endpoint itself. But before I start with some library for the other Hawkular components to consume, I'd like to ask if there's a best practices/recommendations for doing WebSocket authentication with Keycloak. My plan right now is to require the endpoints to inject a service that would accept a message and session, closing the session on this service if the login data is not provided (login data == token, send on the first message, at least at first). Ideas/thoughts? - Juca. From jayblanc at gmail.com Tue Aug 4 11:03:30 2015 From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=) Date: Tue, 04 Aug 2015 15:03:30 +0000 Subject: [keycloak-user] Docker Keycloak for version 1.4.1 not pushed to docker hub In-Reply-To: <887618838.6271039.1438693165047.JavaMail.zimbra@redhat.com> References: <887618838.6271039.1438693165047.JavaMail.zimbra@redhat.com> Message-ID: Hi, thanks for your rapid answer, that's what I've done for instance and it works like a charm. I'm going to wait for docker publication before pushing my images to my team. Best regards, J?r?me. Le mar. 4 ao?t 2015 ? 14:59, Marko Strukelj a ?crit : > Keycloak 1.4.0.Final hasn't been published to Docker yet, but it will be > shortly ... > > In the mean time you can try build docker images yourself: > > git clone https://github.com/jboss-dockerfiles/keycloak.git > keycloak-docker > cd keycloak-docker > git checkout 1.4.0.Final > cd server > docker build --tag jboss/keycloak:1.4.0.Final . > cd ../server-postgres > docker build --tag jboss/keycloak-postgres:1.4.0.Final . > > You can then run it: > > docker run --name keycloak -ti --link postgres:postgres > jboss/keycloak-postgres:1.4.0.Final > > > > ----- Original Message ----- > > Hi, > > I'm trying to use keycloak in a docker and I'm facing an import realm > > problem. I have exported my keycloak realm from version 1.4.0.Final but > it > > conflict in the docker when I import. If I run the docker container > > jboss/keycloak-postgres alone and ask for version information in the UI, > it > > show 1.3.1.Final. > > Stian, did you pushed your new images to docker hub for the 1.4.1 ? > > I see your github push for this new version but it seems when I pull the > > docker image I still have an old version ? > > > > Best regards and congratulation for this great docker packaging which > really > > helps us, J?r?me. > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150804/cf197df0/attachment.html From vvessia at katamail.com Tue Aug 4 12:00:18 2015 From: vvessia at katamail.com (Vito Vessia) Date: Tue, 4 Aug 2015 18:00:18 +0200 Subject: [keycloak-user] Roles for User Management Message-ID: Hi all, I'm trying to use KC for a suite of multitenant webapps. Each tenant/customer has a separated realm and I use a custom Federation Provider to map users and roles to my company's legacy custom ACL database. Customers also want to manage/create users by their own, but I don't want they manage other realm stuff like Federation Provider parameters, client apps, etc, so I have to provide to some users of each realm the only roles of "manage-user"/"view-users" from the app realm-management, so they can only view the Manage User option in the realm Console. The problem is that through the console they may promote themselves assigning to existing users or to new users the role of "manage-realm" and after a simple refresh they can manage the entire realm. Is there a way to avoid this or am I wrong to do this? One more question connected to this one: is there a way to localize also the realm console? If my customers have to manage their own users, they would read labels and messages in their own languages. Thank you very much for your time and for your great and versatile product. Best regards --Vito -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150804/595e563f/attachment-0001.html From bburke at redhat.com Tue Aug 4 12:57:04 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 4 Aug 2015 12:57:04 -0400 Subject: [keycloak-user] Would like to deprecate/remove JPA/Mongo UserSessions Message-ID: <55C0EEE0.9050307@redhat.com> Hi all, Keycloak team would like to deprecate and remove the JPA and Mongo stores for UserSessions and just provide an Infinispan one. It is a pain to maintain these, and in our opinion, users really shouldn't be using JPA or Mongo to store User Sessions. Infinispan has a wide variety of configuration options for internal, external, and cloud networks. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From pslegr at redhat.com Wed Aug 5 03:54:28 2015 From: pslegr at redhat.com (pslegr) Date: Wed, 05 Aug 2015 09:54:28 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C0CFE5.3080108@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> Message-ID: <55C1C134.8060408@redhat.com> Hello Juraci, maybe other Keycloak core devs might have having other recommendations, never-less I've put up an example for our project https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae946ec5 which uses Keycloak to secure the WS endpoint. The point is to intercept the initial HttpRequest and add an AuthorizationHeader into this one. ... List authHeader = new ArrayList(); authHeader.add("Bearer " + authenticate()); headers.put("Authorization", authHeader); ... This is done before protocol upgrade into WS/WSS. I don't see any other way doing this so far.... regards Pavel On 4.8.2015 16:44, Juraci Paix?o Kr?hling wrote: > I'm currently looking into the best way to perform authentication for > WebSockets, and it seems that the best (only?) option so far is to > handle this on the socket's endpoint itself. > > But before I start with some library for the other Hawkular components > to consume, I'd like to ask if there's a best practices/recommendations > for doing WebSocket authentication with Keycloak. > > My plan right now is to require the endpoints to inject a service that > would accept a message and session, closing the session on this service > if the login data is not provided (login data == token, send on the > first message, at least at first). > > Ideas/thoughts? > > - Juca. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/5a2164b8/attachment.html From mposolda at redhat.com Wed Aug 5 04:47:08 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Aug 2015 10:47:08 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1C134.8060408@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> Message-ID: <55C1CD8C.7070907@redhat.com> There is also another example https://github.com/secondsun/wildfly-secured-websocket , where client is javascript application . It's based on web.xml security and the client and server are both in same web application. Unfortunately I don't know if it can work if client and server are in different applications, as it seems that there is no way for add additional HTTP headers on client in javascript websockets API (at least according to http://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api ). So adding "Authorization: Bearer" looks like a challenge here. Marek On 5.8.2015 09:54, pslegr wrote: > Hello Juraci, > > maybe other Keycloak core devs might have having other recommendations, > never-less I've put up an example for our project > https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae946ec5 > which uses Keycloak to secure the WS endpoint. > The point is to intercept the initial HttpRequest and add an > AuthorizationHeader > into this one. > > ... > List authHeader = new ArrayList(); > authHeader.add("Bearer " + authenticate()); > headers.put("Authorization", authHeader); > > ... > > This is done before protocol upgrade into WS/WSS. > > I don't see any other way doing this so far.... > > regards > Pavel > > On 4.8.2015 16:44, Juraci Paix?o Kr?hling wrote: >> I'm currently looking into the best way to perform authentication for >> WebSockets, and it seems that the best (only?) option so far is to >> handle this on the socket's endpoint itself. >> >> But before I start with some library for the other Hawkular components >> to consume, I'd like to ask if there's a best practices/recommendations >> for doing WebSocket authentication with Keycloak. >> >> My plan right now is to require the endpoints to inject a service that >> would accept a message and session, closing the session on this service >> if the login data is not provided (login data == token, send on the >> first message, at least at first). >> >> Ideas/thoughts? >> >> - Juca. >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/3d2605ab/attachment.html From pslegr at redhat.com Wed Aug 5 04:50:52 2015 From: pslegr at redhat.com (pslegr) Date: Wed, 05 Aug 2015 10:50:52 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1CD8C.7070907@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> Message-ID: <55C1CE6C.9010703@redhat.com> On 5.8.2015 10:47, Marek Posolda wrote: > There is also another example > https://github.com/secondsun/wildfly-secured-websocket , where client > is javascript application . It's based on web.xml security and the > client and server are both in same web application. Unfortunately I > don't know if it can work if client and server are in different > applications, as it seems that there is no way for add additional HTTP > headers on client in javascript websockets API (at least according to > http://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api > ). So adding "Authorization: Bearer" looks like a challenge here. Exactly, same experience here ! I was not able to handle the JS api and intercept with Authorization header there On the Java client worked fine > > Marek > > On 5.8.2015 09:54, pslegr wrote: >> Hello Juraci, >> >> maybe other Keycloak core devs might have having other recommendations, >> never-less I've put up an example for our project >> https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae946ec5 >> which uses Keycloak to secure the WS endpoint. >> The point is to intercept the initial HttpRequest and add an >> AuthorizationHeader >> into this one. >> >> ... >> List authHeader = new ArrayList(); >> authHeader.add("Bearer " + authenticate()); >> headers.put("Authorization", authHeader); >> >> ... >> >> This is done before protocol upgrade into WS/WSS. >> >> I don't see any other way doing this so far.... >> >> regards >> Pavel >> >> On 4.8.2015 16:44, Juraci Paix?o Kr?hling wrote: >>> I'm currently looking into the best way to perform authentication for >>> WebSockets, and it seems that the best (only?) option so far is to >>> handle this on the socket's endpoint itself. >>> >>> But before I start with some library for the other Hawkular components >>> to consume, I'd like to ask if there's a best practices/recommendations >>> for doing WebSocket authentication with Keycloak. >>> >>> My plan right now is to require the endpoints to inject a service that >>> would accept a message and session, closing the session on this service >>> if the login data is not provided (login data == token, send on the >>> first message, at least at first). >>> >>> Ideas/thoughts? >>> >>> - Juca. >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/26f07365/attachment.html From mposolda at redhat.com Wed Aug 5 04:51:12 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Aug 2015 10:51:12 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1CD8C.7070907@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> Message-ID: <55C1CE80.8090802@redhat.com> It looks it's possible to add query parameters in Javscript Websocket client. But ATM our adapter supports authenticating requests where the token is sent only in "Authorization: Bearer" header. Maybe adding support for authentication tokens from query parameter is something we can support for adapters though (if someone has valid usecase for it) Marek On 5.8.2015 10:47, Marek Posolda wrote: > There is also another example > https://github.com/secondsun/wildfly-secured-websocket , where client > is javascript application . It's based on web.xml security and the > client and server are both in same web application. Unfortunately I > don't know if it can work if client and server are in different > applications, as it seems that there is no way for add additional HTTP > headers on client in javascript websockets API (at least according to > http://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api > ). So adding "Authorization: Bearer" looks like a challenge here. > > Marek > > On 5.8.2015 09:54, pslegr wrote: >> Hello Juraci, >> >> maybe other Keycloak core devs might have having other recommendations, >> never-less I've put up an example for our project >> https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae946ec5 >> which uses Keycloak to secure the WS endpoint. >> The point is to intercept the initial HttpRequest and add an >> AuthorizationHeader >> into this one. >> >> ... >> List authHeader = new ArrayList(); >> authHeader.add("Bearer " + authenticate()); >> headers.put("Authorization", authHeader); >> >> ... >> >> This is done before protocol upgrade into WS/WSS. >> >> I don't see any other way doing this so far.... >> >> regards >> Pavel >> >> On 4.8.2015 16:44, Juraci Paix?o Kr?hling wrote: >>> I'm currently looking into the best way to perform authentication for >>> WebSockets, and it seems that the best (only?) option so far is to >>> handle this on the socket's endpoint itself. >>> >>> But before I start with some library for the other Hawkular components >>> to consume, I'd like to ask if there's a best practices/recommendations >>> for doing WebSocket authentication with Keycloak. >>> >>> My plan right now is to require the endpoints to inject a service that >>> would accept a message and session, closing the session on this service >>> if the login data is not provided (login data == token, send on the >>> first message, at least at first). >>> >>> Ideas/thoughts? >>> >>> - Juca. >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/83c25934/attachment-0001.html From mposolda at redhat.com Wed Aug 5 04:59:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Aug 2015 10:59:36 +0200 Subject: [keycloak-user] Roles for User Management In-Reply-To: References: Message-ID: <55C1D078.6020107@redhat.com> On 4.8.2015 18:00, Vito Vessia wrote: > Hi all, > I'm trying to use KC for a suite of multitenant webapps. Each > tenant/customer has a separated realm and I use a custom Federation > Provider to map users and roles to my company's legacy custom ACL > database. Customers also want to manage/create users by their own, but > I don't want they manage other realm stuff like Federation Provider > parameters, client apps, etc, so I have to provide to some users of > each realm the only roles of "manage-user"/"view-users" from the app > realm-management, so they can only view the Manage User option in the > realm Console. > The problem is that through the console they may promote themselves > assigning to existing users or to new users the role of "manage-realm" > and after a simple refresh they can manage the entire realm. > Is there a way to avoid this or am I wrong to do this? Looks like not. Feel free to create JIRA for this. > One more question connected to this one: is there a way to localize > also the realm console? If my customers have to manage their own > users, they would read labels and messages in their own languages. > Thank you very much for your time and for your great and versatile > product. AFAIK Stan is looking at admin console localization. Maybe it will be in 1.5 release. Marek > > Best regards > --Vito > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/a64b28fb/attachment.html From juraci at kroehling.de Wed Aug 5 05:49:01 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 5 Aug 2015 11:49:01 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1CE80.8090802@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> Message-ID: <55C1DC0D.3080802@kroehling.de> Thanks for the comments! In our case, we'd need a "standards-compliant" WebSockets authentication, in the sense that we cannot depend on clients adding HTTP Headers (for instance). At first, I think our main client will be a Java agent, so, we _could_ add extra HTTP Headers, but our main API would be available for other developers to make their own agents. From what I've read, even messing with the protocol part of the connection could be seen as a violation of the spec, but it's a grey area (people *are* actually doing it). The remaining "generic" option seems to indeed be adding the token/user+pass details to the URL. After that, the only solution is to do it as part of the application protocol itself: either each message comes with a token that is validated as the first step in processing the message (a-la request-based authentication), or from time to time, or even just at the beginning of the connection (which is problematic, as the user might logout and the socket would not "notice" it). - Juca. On 08/05/2015 10:51 AM, Marek Posolda wrote: > It looks it's possible to add query parameters in Javscript Websocket > client. But ATM our adapter supports authenticating requests where the > token is sent only in "Authorization: Bearer" header. Maybe adding > support for authentication tokens from query parameter is something we > can support for adapters though (if someone has valid usecase for it) > > Marek > > On 5.8.2015 10:47, Marek Posolda wrote: >> There is also another example >> https://github.com/secondsun/wildfly-secured-websocket , where client >> is javascript application . It's based on web.xml security and the >> client and server are both in same web application. Unfortunately I >> don't know if it can work if client and server are in different >> applications, as it seems that there is no way for add additional HTTP >> headers on client in javascript websockets API (at least according to >> http://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api >> ). So adding "Authorization: Bearer" looks like a challenge here. >> >> Marek >> >> On 5.8.2015 09:54, pslegr wrote: >>> Hello Juraci, >>> >>> maybe other Keycloak core devs might have having other recommendations, >>> never-less I've put up an example for our project >>> https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae946ec5 >>> which uses Keycloak to secure the WS endpoint. >>> The point is to intercept the initial HttpRequest and add an >>> AuthorizationHeader >>> into this one. >>> >>> ... >>> List authHeader = new ArrayList(); >>> authHeader.add("Bearer " + authenticate()); >>> headers.put("Authorization", authHeader); >>> >>> ... >>> >>> This is done before protocol upgrade into WS/WSS. >>> >>> I don't see any other way doing this so far.... >>> >>> regards >>> Pavel >>> >>> On 4.8.2015 16:44, Juraci Paix?o Kr?hling wrote: >>>> I'm currently looking into the best way to perform authentication for >>>> WebSockets, and it seems that the best (only?) option so far is to >>>> handle this on the socket's endpoint itself. >>>> >>>> But before I start with some library for the other Hawkular components >>>> to consume, I'd like to ask if there's a best practices/recommendations >>>> for doing WebSocket authentication with Keycloak. >>>> >>>> My plan right now is to require the endpoints to inject a service that >>>> would accept a message and session, closing the session on this service >>>> if the login data is not provided (login data == token, send on the >>>> first message, at least at first). >>>> >>>> Ideas/thoughts? >>>> >>>> - Juca. >>>> _______________________________________________ >>>> 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 mposolda at redhat.com Wed Aug 5 07:52:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Aug 2015 13:52:43 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1DC0D.3080802@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> Message-ID: <55C1F90B.6060409@redhat.com> On 5.8.2015 11:49, Juraci Paix?o Kr?hling wrote: > Thanks for the comments! In our case, we'd need a > "standards-compliant" WebSockets authentication, in the sense that we > cannot depend on clients adding HTTP Headers (for instance). At first, > I think our main client will be a Java agent, so, we _could_ add extra > HTTP Headers, but our main API would be available for other developers > to make their own agents. > > From what I've read, even messing with the protocol part of the > connection could be seen as a violation of the spec, but it's a grey > area (people *are* actually doing it). > > The remaining "generic" option seems to indeed be adding the > token/user+pass details to the URL. > > After that, the only solution is to do it as part of the application > protocol itself: either each message comes with a token that is > validated as the first step in processing the message (a-la > request-based authentication), or from time to time, or even just at > the beginning of the connection (which is problematic, as the user > might logout and the socket would not "notice" it). Doing at the beginning of the connection might be easy. We may just need to add support to adapters for authentication via bearer token sent in URL query parameter or in the POST body. There is also specs for it http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param . Not sure if adapters should support it by default or just on demand as there are some security implications when access token is sent in URI as mentioned in the specs. Not sure about request-based authentication, I don't know much about websockets TBH so not sure what would be required to support this. Marek > > - Juca. > > > On 08/05/2015 10:51 AM, Marek Posolda wrote: >> It looks it's possible to add query parameters in Javscript Websocket >> client. But ATM our adapter supports authenticating requests where the >> token is sent only in "Authorization: Bearer" header. Maybe adding >> support for authentication tokens from query parameter is something we >> can support for adapters though (if someone has valid usecase for it) >> >> Marek >> >> On 5.8.2015 10:47, Marek Posolda wrote: >>> There is also another example >>> https://github.com/secondsun/wildfly-secured-websocket , where client >>> is javascript application . It's based on web.xml security and the >>> client and server are both in same web application. Unfortunately I >>> don't know if it can work if client and server are in different >>> applications, as it seems that there is no way for add additional HTTP >>> headers on client in javascript websockets API (at least according to >>> http://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api >>> >>> ). So adding "Authorization: Bearer" looks like a challenge here. >>> >>> Marek >>> >>> On 5.8.2015 09:54, pslegr wrote: >>>> Hello Juraci, >>>> >>>> maybe other Keycloak core devs might have having other >>>> recommendations, >>>> never-less I've put up an example for our project >>>> https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae946ec5 >>>> >>>> which uses Keycloak to secure the WS endpoint. >>>> The point is to intercept the initial HttpRequest and add an >>>> AuthorizationHeader >>>> into this one. >>>> >>>> ... >>>> List authHeader = new ArrayList(); >>>> authHeader.add("Bearer " + authenticate()); >>>> headers.put("Authorization", authHeader); >>>> >>>> ... >>>> >>>> This is done before protocol upgrade into WS/WSS. >>>> >>>> I don't see any other way doing this so far.... >>>> >>>> regards >>>> Pavel >>>> >>>> On 4.8.2015 16:44, Juraci Paix?o Kr?hling wrote: >>>>> I'm currently looking into the best way to perform authentication for >>>>> WebSockets, and it seems that the best (only?) option so far is to >>>>> handle this on the socket's endpoint itself. >>>>> >>>>> But before I start with some library for the other Hawkular >>>>> components >>>>> to consume, I'd like to ask if there's a best >>>>> practices/recommendations >>>>> for doing WebSocket authentication with Keycloak. >>>>> >>>>> My plan right now is to require the endpoints to inject a service >>>>> that >>>>> would accept a message and session, closing the session on this >>>>> service >>>>> if the login data is not provided (login data == token, send on the >>>>> first message, at least at first). >>>>> >>>>> Ideas/thoughts? >>>>> >>>>> - Juca. >>>>> _______________________________________________ >>>>> 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 rajat.nair at hp.com Wed Aug 5 08:14:57 2015 From: rajat.nair at hp.com (Nair, Rajat) Date: Wed, 5 Aug 2015 12:14:57 +0000 Subject: [keycloak-user] Distributed Keycloak user sessions using Infinispan References: <59651412.706872.1438003614393.JavaMail.zimbra@redhat.com> <1045151906.720245.1438004746473.JavaMail.zimbra@redhat.com> <1732913135.720424.1438004774275.JavaMail.zimbra@redhat.com> <1042060711.1068309.1438058940079.JavaMail.zimbra@redhat.com> <966246176.551354.1438190443054.JavaMail.zimbra@redhat.com> Message-ID: Some more information - Quick summary - I'm trying to test HA of Keycloak user sessions when one of the nodes goes down, users should not have to login again as their session information would be available on other node. Keycloak cluster is setup to store users session on Infinispan (testing using distributed-cache and replicated-cache). To see the cache information on Keycloak nodes, I setup hawtio on these node. Initial state of caches on both the nodes are captured in these images (see 110.DC.Start.png and 111.DC.Start.png) Then user logs into server 111. We can see the session entry value increasing (see 111.DC.Login.On.111.PNG). When we look at session entry on 110 server, we see that the count has increased there too. That means that they session is being successfully replicated (see 110.DC.Login.On.111.PNG). To verify if this works other way around, we logged into server 110, and its session entry count increased (see 110.DC.Login.On.110.And.111.PNG). When we check 111, we can see that session entry count increased on this server too. (see 111.DC.Login.On.110.And.111.png). We initially suspected that our sessions were not getting replicated. Using hawtio, we can see session entry count increasing on both servers. Could this mean that there is a bug in Keycloak's code while fetching user sessions? Is there any other way we can validate user sessions? -- Rajat -----Original Message----- From: Nair, Rajat Sent: 03 August 2015 12:43 To: 'Stian Thorgersen'; Marek Posolda Cc: keycloak-user at lists.jboss.org Subject: RE: [keycloak-user] Distributed Keycloak user sessions using Infinispan Hi, Some more info from log of test-server-110 server (server names are test-server-110 and test-server-111) - Infinispan subsystem initialized logs for sessions cache - [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 39) WFLYCLINF0001: Activating Infinispan subsystem. [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000078: Starting JGroups channel keycloak [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000094: Received new cluster view for channel keycloak: [test-server-111|0] (1) [test-server-111] [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000079: Channel keycloak local address is test-server-111, physical addresses are [XX.XX.XX.XX:7600] [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started sessions cache from keycloak container [org.infinispan.CLUSTER] (remote-thread--p3-t3) ISPN000310: Starting cluster-wide rebalance for cache sessions, topology CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.CLUSTER] (remote-thread--p3-t2) ISPN000336: Finished cluster-wide rebalance for cache sessions, topology id = 1 Session cache details - [org.infinispan.jmx.JmxUtil] (ServerService Thread Pool -- 63) Object name jboss.infinispan:type=Cache,name="sessions(dist_sync)",manager="keycloak",component=Cache already registered [org.infinispan.topology.LocalTopologyManagerImpl] (ServerService Thread Pool -- 63) Node test-server-110 joining cache sessions [org.infinispan.topology.LocalTopologyManagerImpl] (ServerService Thread Pool -- 63) Updating local topology for cache sessions: CacheTopology{id=0, rebalanceId=0, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=null, unionCH=null, actualMembers=[test-server-111]} [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t5) Updating local topology for cache sessions: CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t5) Starting local rebalance for cache sessions, topology = CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t5) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t5) Removing no longer owned entries for cache sessions [org.infinispan.statetransfer.InboundTransferTask] (stateTransferExecutor-thread--p5-t19) Finished receiving state for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions [org.infinispan.statetransfer.StateConsumerImpl] (stateTransferExecutor-thread--p5-t24) Finished receiving of segments for cache sessions for topology 1. [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t10) Updating local topology for cache sessions: CacheTopology{id=2, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, pendingCH=null, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t10) Removing no longer owned entries for cache sessions [org.infinispan.cache.impl.CacheImpl] (ServerService Thread Pool -- 63) Started cache sessions on test-server-110 [org.wildfly.clustering.infinispan.spi.service.CacheBuilder] (ServerService Thread Pool -- 63) sessions keycloak cache started Looks like the servers are talking to each other (setup on unicast) and session cache between the servers are shared, but we still cannot successfully fetch user info when token is generated by one server (test-server-110) and data from another (test-server-111). Any suggestions/debugging approaches appreciated. -- Rajat -----Original Message----- From: Stian Thorgersen [mailto:stian at redhat.com] Sent: 29 July 2015 22:51 To: Nair, Rajat; Marek Posolda Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Distributed Keycloak user sessions using Infinispan I'm away on holiday, Marek can you take a look at this? ----- Original Message ----- > From: "Rajat Nair" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Wednesday, 29 July, 2015 2:56:07 PM > Subject: RE: [keycloak-user] Distributed Keycloak user sessions using > Infinispan > > Follow up to our discussion - > > I upgrade my nodes to Keycloak 1.4 Final. Dropped and re-created > database Postgres database (shared between both the nodes) and tested > distributed user session using following commands - > - Fetch access token using following curl from one server > curl --write-out " %{http_code}" -s --request POST --header "Content-Type: > application/x-www-form-urlencoded; charset=UTF-8" --data > "username=user1 at email.com&password=testpassword@&client_id=admin-client&grant_type=password" > "http://test-server-110:8080/auth/realms/test/protocol/openid-connect/token" > > - Validated the token on different server using > curl --write-out " %{http_code}" -s --request GET --header "Content-Type: > application/json" --header "Authorization: Bearer > [ACCESS_TOKEN_FROM_PREVIOUS_CALL]" > "http://test-server-111:8081/auth/realms/test/protocol/openid-connect/userinfo" > > And we get this - {"error":"invalid_grant","error_description":"Token > invalid"} > No more NPE and internal server error. > > If we use the same token and try to fetch user details on server which > issued the token - we get the correct data. (Note - I have confirmed > that the token has not expired) > > > One thing you can try is to make sure user session replication is > > working > > properly: > > 1. Start two nodes > > 2. Open admin console directly on node 1 - login as admin/admin 3. > > Open admin console directly on node 2 from another machine/browser > > or use incognito mode - login as admin/admin 4. On node 1 go to > > users -> view all > > -> click on admin -> sessions - > > you should see two sessions 5. > > -> On node > > 2 do the same and check you can see two sessions there as well > Now this is where things get strange. I followed the steps described - > used 2 different browsers - and I can see 2 sessions listed! > > Are the process we use to validate the token incorrect? Or is master > console on the web doing something different (like get the data from > Postgres database used by both the nodes). > > -- Rajat > > -----Original Message----- > From: Stian Thorgersen [mailto:stian at redhat.com] > Sent: 28 July 2015 10:19 > To: Nair, Rajat > Cc: keycloak-user at lists.jboss.org > Subject: Re: [keycloak-user] Distributed Keycloak user sessions using > Infinispan > > > > ----- Original Message ----- > > From: "Rajat Nair" > > To: "Stian Thorgersen" > > Cc: keycloak-user at lists.jboss.org > > Sent: Monday, 27 July, 2015 7:33:25 PM > > Subject: RE: [keycloak-user] Distributed Keycloak user sessions > > using Infinispan > > > > > Can you send me your standalone-ha.xml and keycloak-server.json? > > Files attached. The service is started like - > > /opt/jboss/keycloak/bin/standalone.sh -c standalone-ha.xml > > -b=test-server-110 > > -bmanagement=test-server-110 -u 230.0.0.4 > > -Djboss.node.name=test-server-110 > > > > > Also, any chance you can try it out with master? I've been testing > > > with that as we're about to do 1.4 release soon > > Glad to give back to the community. Will build and deploy the master > > on my nodes. Will send findings tomorrow. > > > > Regarding a scenario I described earlier - Case 2 1. Start with 1 > > Node down. We bring it back up. We wait for some time so that > > Infinispan can sync. > > 2. Bring down other node. > > 3. Try to get user info using existing token. > > > > Is this a valid use-case? > > Yes - I've tried the same use-case and it works fine every time. One > caveat is that access token can expire, but in this case you should > get a 403 returned, not a NPE exception and 500. > > One thing you can try is to make sure user session replication is > working > properly: > > 1. Start two nodes > 2. Open admin console directly on node 1 - login as admin/admin 3. > Open admin console directly on node 2 from another machine/browser or > use incognito mode - login as admin/admin 4. On node 1 go to users -> > view all -> click on admin -> sessions - you should see two sessions > 5. On node 2 do the same and check you can see two sessions there as > well > > > > > -- Rajat > > > > -----Original Message----- > > From: Stian Thorgersen [mailto:stian at redhat.com] > > Sent: 27 July 2015 19:16 > > To: Nair, Rajat > > Cc: keycloak-user at lists.jboss.org > > Subject: Re: [keycloak-user] Distributed Keycloak user sessions > > using Infinispan > > > > Also, any chance you can try it out with master? I've been testing > > with that as we're about to do 1.4 release soon > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" > > > To: "Rajat Nair" > > > Cc: keycloak-user at lists.jboss.org > > > Sent: Monday, 27 July, 2015 3:45:46 PM > > > Subject: Re: [keycloak-user] Distributed Keycloak user sessions > > > using Infinispan > > > > > > Can you send me your standalone-ha.xml and keycloak-server.json? > > > > > > ----- Original Message ----- > > > > From: "Rajat Nair" > > > > To: "Stian Thorgersen" > > > > Cc: keycloak-user at lists.jboss.org > > > > Sent: Monday, 27 July, 2015 3:41:36 PM > > > > Subject: RE: [keycloak-user] Distributed Keycloak user sessions > > > > using Infinispan > > > > > > > > > Do you have both nodes fully up and running before you kill one node? > > > > Yes. > > > > This is what we tried - > > > > Case 1 > > > > 1. Two node cluster (both running Keycloak engines) - both up > > > > and running. > > > > Configured load balancing using mod_cluster. > > > > 2. Login and get token. > > > > 3. Bring down one node. > > > > 4. Get user info using existing token. This is when we get NPE. > > > > > > > > Case 2 > > > > 1. Start with 1 Node down. We bring it back up. We wait for some > > > > time so that Infinispan can sync. > > > > 2. Bring down other node. > > > > 3. Try to get user info using existing token. Again we see NPE. > > > > > > > > >It's a bug - if session is expired it should return an error > > > > >message, not a NPE (see > > > > >https://issues.jboss.org/browse/KEYCLOAK-1710) > > > > Thanks for tracking this. > > > > > > > > -- Rajat > > > > > > > > ----- Original Message ----- > > > > > From: "Rajat Nair" > > > > > To: "Stian Thorgersen" > > > > > Cc: keycloak-user at lists.jboss.org > > > > > Sent: Monday, 27 July, 2015 3:20:27 PM > > > > > Subject: RE: [keycloak-user] Distributed Keycloak user > > > > > sessions using Infinispan > > > > > > > > > > Thanks for quick reply Stian. > > > > > > > > > > > What version? > > > > > We are using Keycloak 1.3.1 Final. > > > > > > > > > > > Did you remember to change userSessions provider to > > > > > > infinispan in keycloak-server.json? > > > > > Yes. We got following in keycloak-server.json - > > > > > "userSessions": { > > > > > "provider": "infinispan" > > > > > } > > > > > > > > > > > Firstly owners="2" should work fine as long as only one node > > > > > > dies and the other remains active. Secondly it should return > > > > > > a NPE, but an error if user session is not found. > > > > > Could you elaborate on your 2nd point? > > > > > > > > Do you have both nodes fully up and running before you kill one node? > > > > > > > > It's a bug - if session is expired it should return an error > > > > message, not a NPE (see > > > > https://issues.jboss.org/browse/KEYCLOAK-1710) > > > > > > > > > > > > > > -- Rajat > > > > > > > > > > -----Original Message----- > > > > > From: Stian Thorgersen [mailto:stian at redhat.com] > > > > > Sent: 27 July 2015 18:07 > > > > > To: Nair, Rajat > > > > > Cc: keycloak-user at lists.jboss.org > > > > > Subject: Re: [keycloak-user] Distributed Keycloak user > > > > > sessions using Infinispan > > > > > > > > > > Did you remember to change userSessions provider to infinispan > > > > > in keycloak-server.json? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Stian Thorgersen" > > > > > > To: "Rajat Nair" > > > > > > Cc: keycloak-user at lists.jboss.org > > > > > > Sent: Monday, 27 July, 2015 2:24:17 PM > > > > > > Subject: Re: [keycloak-user] Distributed Keycloak user > > > > > > sessions using Infinispan > > > > > > > > > > > > What version? > > > > > > > > > > > > Firstly owners="2" should work fine as long as only one node > > > > > > dies and the other remains active. Secondly it should return > > > > > > a NPE, but an error if user session is not found. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajat Nair" > > > > > > > To: keycloak-user at lists.jboss.org > > > > > > > Sent: Monday, 27 July, 2015 2:03:47 PM > > > > > > > Subject: [keycloak-user] Distributed Keycloak user > > > > > > > sessions using Infinispan > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I?m in the process of setting up distributed user sessions > > > > > > > using Infinispan on my Keycloak cluster. This is the > > > > > > > configuration I use ? > > > > > > > > > > > > > > > > > > > > jndi-name="java:jboss/infinispan/Keycloak"> > > > > > > > lock-timeout="60000"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > owners="2"/> > > > > > > > > > > > > > > > > > > > > owners="1"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And in server.logs, I can see my servers communicate ? > > > > > > > > > > > > > > 2015-07-27 10:27:24,662 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t7) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > users, topology CacheTopology{id=57, rebalanceId=17, > > > > > > > currentCH=ReplicatedConsistentHash{ns > > > > > > > = > > > > > > > 60, owners = (1)[test-server-110: 60]}, > > > > > > > pendingCH=ReplicatedConsistentHash{ns = 60, owners = > > > > > > > (2)[test-server-110: > > > > > > > 30, test-server-111: 30]}, unionCH=null, > > > > > > > actualMembers=[test-server-110, test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t10) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > realms, topology CacheTopology{id=57, rebalanceId=17, > > > > > > > currentCH=ReplicatedConsistentHash{ns > > > > > > > = > > > > > > > 60, owners = (1)[test-server-110: 60]}, > > > > > > > pendingCH=ReplicatedConsistentHash{ns = 60, owners = > > > > > > > (2)[test-server-110: > > > > > > > 30, test-server-111: 30]}, unionCH=null, > > > > > > > actualMembers=[test-server-110, test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t8) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > loginFailures, topology CacheTopology{id=57, > > > > > > > rebalanceId=17, currentCH=DefaultConsistentHash{ns=80, > > > > > > > owners = > > > > > > > (1)[test-server-110: > > > > > > > 80+0]}, > > > > > > > pendingCH=DefaultConsistentHash{ns=80, owners = > > > > > > > (2)[test-server-110: > > > > > > > 40+0, > > > > > > > test-server-111: 40+0]}, unionCH=null, > > > > > > > actualMembers=[test-server-110, test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,669 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t9) > > > > > > > ISPN000310: Starting cluster-wide rebalance for cache > > > > > > > sessions, topology CacheTopology{id=56, rebalanceId=17, > > > > > > > currentCH=DefaultConsistentHash{ns=80, > > > > > > > owners = (1)[test-server-110: 80+0]}, > > > > > > > pendingCH=DefaultConsistentHash{ns=80, > > > > > > > owners = (2)[test-server-110: 40+0, test-server-111: > > > > > > > 40+0]}, unionCH=null, actualMembers=[test-server-110, > > > > > > > test-server-111]} > > > > > > > > > > > > > > 2015-07-27 10:27:24,808 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t9) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > loginFailures, topology id = 57 > > > > > > > > > > > > > > 2015-07-27 10:27:24,810 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t12) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > sessions, topology id = 56 > > > > > > > > > > > > > > 2015-07-27 10:27:24,988 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t12) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > realms, topology id = > > > > > > > 57 > > > > > > > > > > > > > > 2015-07-27 10:27:25,530 INFO [org.infinispan.CLUSTER] > > > > > > > (remote-thread--p3-t8) > > > > > > > ISPN000336: Finished cluster-wide rebalance for cache > > > > > > > users, topology id = > > > > > > > 57 > > > > > > > > > > > > > > > > > > > > > > > > > > > > I can successfully login, get a token and fetch user > > > > > > > details with this token. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Problem is, if one of the nodes on the cluster goes down > > > > > > > and if we try to reuse a token which was already issued > > > > > > > (so workflow is ? user logins in, get token, (a node in > > > > > > > the cluster goes down) and then fetch user details using > > > > > > > token) ? we see an internal server exception. From the > > > > > > > logs ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2015-07-27 10:24:25,714 ERROR [io.undertow.request] > > > > > > > (default > > > > > > > task-1) > > > > > > > UT005023: Exception handling request to > > > > > > > /auth/realms/scaletest/protocol/openid-connect/userinfo: > > > > > > > java.lang.RuntimeException: request path: > > > > > > > /auth/realms/scaletest/protocol/openid-connect/userinfo > > > > > > > > > > > > > > at > > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > KeycloakSessionServletFilter.java:54) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. > > > > > > > java > > > > > > > :6 > > > > > > > 0) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > FilterHandler.java:132) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler.handleRequest(F > > > > > > > il > > > > > > > te > > > > > > > rHan > > > > > > > dl > > > > > > > er.java:85) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.ServletSecurityRoleH > > > > > > > an > > > > > > > dl > > > > > > > er.h > > > > > > > an > > > > > > > dleRequest(ServletSecurityRoleHandler.java:62) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletDispatchingHandler.han > > > > > > > dl > > > > > > > eR > > > > > > > eque > > > > > > > st > > > > > > > (ServletDispatchingHandler.java:36) > > > > > > > > > > > > > > at > > > > > > > org.wildfly.extension.undertow.security.SecurityContextAss > > > > > > > oc > > > > > > > ia > > > > > > > tion > > > > > > > Ha > > > > > > > ndler.handleRequest(SecurityContextAssociationHandler.java > > > > > > > :7 > > > > > > > 8) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.SSLInformationAssoci > > > > > > > at > > > > > > > io > > > > > > > nHan > > > > > > > dl > > > > > > > er.handleRequest(SSLInformationAssociationHandler.java:131 > > > > > > > ) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.ServletAuthenticatio > > > > > > > nC > > > > > > > al > > > > > > > lHan > > > > > > > dl > > > > > > > er.handleRequest(ServletAuthenticationCallHandler.java:57) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.AbstractConfidentialityHandl > > > > > > > er > > > > > > > .h > > > > > > > andl > > > > > > > eR > > > > > > > equest(AbstractConfidentialityHandler.java:46) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.ServletConfidentiali > > > > > > > ty > > > > > > > Co > > > > > > > nstr > > > > > > > ai > > > > > > > ntHandler.handleRequest(ServletConfidentialityConstraintHa > > > > > > > nd > > > > > > > le > > > > > > > r.ja > > > > > > > va > > > > > > > :64) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.AuthenticationMechanismsHandler. > > > > > > > hand > > > > > > > le > > > > > > > Request(AuthenticationMechanismsHandler.java:58) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.security.CachedAuthenticatedS > > > > > > > es > > > > > > > si > > > > > > > onHa > > > > > > > nd > > > > > > > ler.handleRequest(CachedAuthenticatedSessionHandler.java:7 > > > > > > > 2) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.NotificationReceiverHandler. > > > > > > > ha > > > > > > > nd > > > > > > > leRe > > > > > > > qu > > > > > > > est(NotificationReceiverHandler.java:50) > > > > > > > > > > > > > > at > > > > > > > io.undertow.security.handlers.SecurityInitialHandler.handl > > > > > > > eR > > > > > > > eq > > > > > > > uest > > > > > > > (S > > > > > > > ecurityInitialHandler.java:76) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler. > > > > > > > ha > > > > > > > ndleRequest(JACCContextIdHandler.java:61) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest > > > > > > > (P > > > > > > > re > > > > > > > dica > > > > > > > te > > > > > > > Handler.java:43) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.handlers.MetricsHandler.handleRequest(M > > > > > > > et > > > > > > > ri > > > > > > > csHa > > > > > > > nd > > > > > > > ler.java:62) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.core.MetricsChainHandler.handleRequest > > > > > > > (M > > > > > > > et > > > > > > > rics > > > > > > > Ch > > > > > > > ainHandler.java:59) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.handleF > > > > > > > ir > > > > > > > st > > > > > > > Requ > > > > > > > es > > > > > > > t(ServletInitialHandler.java:274) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.dispatc > > > > > > > hR > > > > > > > eq > > > > > > > uest > > > > > > > (S > > > > > > > ervletInitialHandler.java:253) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.access$ > > > > > > > 00 > > > > > > > 0( > > > > > > > Serv > > > > > > > le > > > > > > > tInitialHandler.java:80) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletInitialHandler$1.handl > > > > > > > eR > > > > > > > eq > > > > > > > uest > > > > > > > (S > > > > > > > ervletInitialHandler.java:172) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.Connectors.executeRootHandler(Connectors. > > > > > > > ja > > > > > > > va:1 > > > > > > > 99 > > > > > > > ) > > > > > > > > > > > > > > at > > > > > > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java: > > > > > > > 774) > > > > > > > > > > > > > > at > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at java.lang.Thread.run(Unknown Source) > > > > > > > > > > > > > > Caused by: org.jboss.resteasy.spi.UnhandledException: > > > > > > > java.lang.NullPointerException > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ExceptionHandler.handleApplication > > > > > > > Ex > > > > > > > ce > > > > > > > ptio > > > > > > > n( > > > > > > > ExceptionHandler.java:76) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ExceptionHandler.handleException(E > > > > > > > xc > > > > > > > ep > > > > > > > tion > > > > > > > Ha > > > > > > > ndler.java:212) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.writeExcepti > > > > > > > on > > > > > > > (S > > > > > > > ynch > > > > > > > ro > > > > > > > nousDispatcher.java:149) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch > > > > > > > ro > > > > > > > no > > > > > > > usDi > > > > > > > sp > > > > > > > atcher.java:372) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch > > > > > > > ro > > > > > > > no > > > > > > > usDi > > > > > > > sp > > > > > > > atcher.java:179) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainer > > > > > > > Di > > > > > > > sp > > > > > > > atch > > > > > > > er > > > > > > > .service(ServletContainerDispatcher.java:220) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispa > > > > > > > tc > > > > > > > he > > > > > > > r.se > > > > > > > rv > > > > > > > ice(HttpServletDispatcher.java:56) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispa > > > > > > > tc > > > > > > > he > > > > > > > r.se > > > > > > > rv > > > > > > > ice(HttpServletDispatcher.java:51) > > > > > > > > > > > > > > at > > > > > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:79 > > > > > > > 0) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.ServletHandler.handleRequest( > > > > > > > Se > > > > > > > rv > > > > > > > letH > > > > > > > an > > > > > > > dler.java:86) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > FilterHandler.java:130) > > > > > > > > > > > > > > at > > > > > > > org.keycloak.services.filters.ClientConnectionFilter.doFil > > > > > > > te > > > > > > > r( > > > > > > > Clie > > > > > > > nt > > > > > > > ConnectionFilter.java:41) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. > > > > > > > java > > > > > > > :6 > > > > > > > 0) > > > > > > > > > > > > > > at > > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > FilterHandler.java:132) > > > > > > > > > > > > > > at > > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter > > > > > > > .d > > > > > > > oF > > > > > > > ilte > > > > > > > r( > > > > > > > KeycloakSessionServletFilter.java:40) > > > > > > > > > > > > > > ... 31 more > > > > > > > > > > > > > > Caused by: java.lang.NullPointerException > > > > > > > > > > > > > > at > > > > > > > org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu > > > > > > > eU > > > > > > > se > > > > > > > rInf > > > > > > > o( > > > > > > > UserInfoEndpoint.java:128) > > > > > > > > > > > > > > at > > > > > > > org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu > > > > > > > eU > > > > > > > se > > > > > > > rInf > > > > > > > oG > > > > > > > et(UserInfoEndpoint.java:101) > > > > > > > > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > > > > Method) > > > > > > > > > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > > > > > > > Source) > > > > > > > > > > > > > > at java.lang.reflect.Method.invoke(Unknown Source) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodIn > > > > > > > je > > > > > > > ct > > > > > > > orIm > > > > > > > pl > > > > > > > .java:137) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarg > > > > > > > et > > > > > > > (R > > > > > > > esou > > > > > > > rc > > > > > > > eMethodInvoker.java:296) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resou > > > > > > > rc > > > > > > > eM > > > > > > > etho > > > > > > > dI > > > > > > > nvoker.java:250) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar > > > > > > > ge > > > > > > > tO > > > > > > > bjec > > > > > > > t( > > > > > > > ResourceLocatorInvoker.java:140) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso > > > > > > > ur > > > > > > > ce > > > > > > > Loca > > > > > > > to > > > > > > > rInvoker.java:109) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar > > > > > > > ge > > > > > > > tO > > > > > > > bjec > > > > > > > t( > > > > > > > ResourceLocatorInvoker.java:135) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso > > > > > > > ur > > > > > > > ce > > > > > > > Loca > > > > > > > to > > > > > > > rInvoker.java:103) > > > > > > > > > > > > > > at > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch > > > > > > > ro > > > > > > > no > > > > > > > usDi > > > > > > > sp > > > > > > > atcher.java:356) > > > > > > > > > > > > > > ... 42 more > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The user guide says ? > > > > > > > > > > > > > > If you need to prevent node failures from requiring users > > > > > > > to log in again, set the owners attribute to 2 or more for > > > > > > > the sessions cache > > > > > > > > > > > > > > > > > > > > > > > > > > > > Questions - > > > > > > > > > > > > > > 1. Have we configured Infinispan incorrectly? We don?t > > > > > > > want the users to login again if any of the nodes in the > > > > > > > cluster go down. > > > > > > > > > > > > > > 2. Will changing distributed-cache to replicated-cache > > > > > > > help in this scenario? > > > > > > > > > > > > > > 3. Any way we can see the contents of the cache? > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Rajat > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 111.DC.Start.PNG Type: image/png Size: 23699 bytes Desc: 111.DC.Start.PNG Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/c6c579ba/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 110.DC.Start.PNG Type: image/png Size: 23878 bytes Desc: 110.DC.Start.PNG Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/c6c579ba/attachment-0007.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 111.DC.Login.On.111.PNG Type: image/png Size: 23672 bytes Desc: 111.DC.Login.On.111.PNG Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/c6c579ba/attachment-0008.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 110.DC.Login.On.111.PNG Type: image/png Size: 23820 bytes Desc: 110.DC.Login.On.111.PNG Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/c6c579ba/attachment-0009.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 110.DC.Login.On.110.And.111.PNG Type: image/png Size: 23707 bytes Desc: 110.DC.Login.On.110.And.111.PNG Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/c6c579ba/attachment-0010.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 111.DC.Login.On.110.And.111.PNG Type: image/png Size: 25720 bytes Desc: 111.DC.Login.On.110.And.111.PNG Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/c6c579ba/attachment-0011.png From bburke at redhat.com Wed Aug 5 08:49:07 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 5 Aug 2015 08:49:07 -0400 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1F90B.6060409@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> Message-ID: <55C20643.8040602@redhat.com> On 8/5/2015 7:52 AM, Marek Posolda wrote: > On 5.8.2015 11:49, Juraci Paix?o Kr?hling wrote: >> Thanks for the comments! In our case, we'd need a >> "standards-compliant" WebSockets authentication, in the sense that we >> cannot depend on clients adding HTTP Headers (for instance). At first, >> I think our main client will be a Java agent, so, we _could_ add extra >> HTTP Headers, but our main API would be available for other developers >> to make their own agents. >> >> From what I've read, even messing with the protocol part of the >> connection could be seen as a violation of the spec, but it's a grey >> area (people *are* actually doing it). >> >> The remaining "generic" option seems to indeed be adding the >> token/user+pass details to the URL. >> >> After that, the only solution is to do it as part of the application >> protocol itself: either each message comes with a token that is >> validated as the first step in processing the message (a-la >> request-based authentication), or from time to time, or even just at >> the beginning of the connection (which is problematic, as the user >> might logout and the socket would not "notice" it). > Doing at the beginning of the connection might be easy. We may just need > to add support to adapters for authentication via bearer token sent in > URL query parameter or in the POST body. There is also specs for it > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param > . Not sure if adapters should support it by default or just on demand as > there are some security implications when access token is sent in URI as > mentioned in the specs. > > Not sure about request-based authentication, I don't know much about > websockets TBH so not sure what would be required to support this. > Looks like something we need to support. Is it something we would only support with Servlet 3.1 (which has http upgrade support)? The way we could implement is that we only support query-param tokens when an HTTP Upgrade request is invoked. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From juraci at kroehling.de Wed Aug 5 09:04:30 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 5 Aug 2015 15:04:30 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C1F90B.6060409@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> Message-ID: <55C209DE.6080000@kroehling.de> On 08/05/2015 01:52 PM, Marek Posolda wrote: > Doing at the beginning of the connection might be easy. We may just need > to add support to adapters for authentication via bearer token sent in > URL query parameter or in the POST body. There is also specs for it > http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param The main problem with this is that a token might be valid at the time the connection is made, but might not be valid after some time, while the socket is still opened. So, a socket that was opened with a session that just expired would still be open. Perhaps undertow provides something that would allow the adapter to close sockets whose tokens are not valid anymore? - Juca. From mposolda at redhat.com Wed Aug 5 09:34:10 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Aug 2015 15:34:10 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C20643.8040602@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C20643.8040602@redhat.com> Message-ID: <55C210D2.8080408@redhat.com> On 5.8.2015 14:49, Bill Burke wrote: > > On 8/5/2015 7:52 AM, Marek Posolda wrote: >> On 5.8.2015 11:49, Juraci Paix?o Kr?hling wrote: >>> Thanks for the comments! In our case, we'd need a >>> "standards-compliant" WebSockets authentication, in the sense that we >>> cannot depend on clients adding HTTP Headers (for instance). At first, >>> I think our main client will be a Java agent, so, we _could_ add extra >>> HTTP Headers, but our main API would be available for other developers >>> to make their own agents. >>> >>> From what I've read, even messing with the protocol part of the >>> connection could be seen as a violation of the spec, but it's a grey >>> area (people *are* actually doing it). >>> >>> The remaining "generic" option seems to indeed be adding the >>> token/user+pass details to the URL. >>> >>> After that, the only solution is to do it as part of the application >>> protocol itself: either each message comes with a token that is >>> validated as the first step in processing the message (a-la >>> request-based authentication), or from time to time, or even just at >>> the beginning of the connection (which is problematic, as the user >>> might logout and the socket would not "notice" it). >> Doing at the beginning of the connection might be easy. We may just need >> to add support to adapters for authentication via bearer token sent in >> URL query parameter or in the POST body. There is also specs for it >> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param >> . Not sure if adapters should support it by default or just on demand as >> there are some security implications when access token is sent in URI as >> mentioned in the specs. >> >> Not sure about request-based authentication, I don't know much about >> websockets TBH so not sure what would be required to support this. >> > Looks like something we need to support. Is it something we would only > support with Servlet 3.1 (which has http upgrade support)? > > The way we could implement is that we only support query-param tokens > when an HTTP Upgrade request is invoked. I've created https://issues.jboss.org/browse/KEYCLOAK-1733 . Not sure if support just for HTTP Upgrade requests or for all, but likely Upgrade request is sufficient (until we have usecase for other HTTP methods). The thing is, that securing just HTTP Upgrade requests is ok for basic websocket support, but there is still the possible logout issue mentioned by Juca (Socket may not notice that session was logged out). Marek From mposolda at redhat.com Wed Aug 5 09:39:07 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 05 Aug 2015 15:39:07 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C209DE.6080000@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> Message-ID: <55C211FB.4070805@redhat.com> On 5.8.2015 15:04, Juraci Paix?o Kr?hling wrote: > On 08/05/2015 01:52 PM, Marek Posolda wrote: >> Doing at the beginning of the connection might be easy. We may just need >> to add support to adapters for authentication via bearer token sent in >> URL query parameter or in the POST body. There is also specs for it >> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param > > The main problem with this is that a token might be valid at the time > the connection is made, but might not be valid after some time, while > the socket is still opened. So, a socket that was opened with a > session that just expired would still be open. > > Perhaps undertow provides something that would allow the adapter to > close sockets whose tokens are not valid anymore? No idea, may require further investigation. It will be cool if we have something like our iframe in keycloak.js to easily detect logout and close the socket based on it. Maybe it's possible the server will poll the client socket and ask for updated token from the client periodically. I am not sure about the possible and best option TBH (not have deep websocket knowledge) Marek > - Juca. From juraci at kroehling.de Wed Aug 5 10:20:32 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 5 Aug 2015 16:20:32 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C211FB.4070805@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> Message-ID: <55C21BB0.4000706@kroehling.de> On 08/05/2015 03:39 PM, Marek Posolda wrote: > Maybe it's > possible the server will poll the client socket and ask for updated > token from the client periodically. I am not sure about the possible and > best option TBH (not have deep websocket knowledge) It is possible, but that goes into the "invasive" approach, as it can be done only with a message going from the server to the client. Doing this at the Keycloak level means that the application has to know how to handle (or discard) Keycloak-specific messages. Honestly, the more I think about it, the more I realize that the best solution would be to get an API from Keycloak that would allow me to validate tokens and extract a principal from it, like what the Request Authenticators do. Even better if this API could call me back from time to time, so that my server part could ask the client part for a renewed token. My client could then send this token in the next payload (not necessarily a payload *only* with the token). - Juca. From vvessia at katamail.com Wed Aug 5 10:35:37 2015 From: vvessia at katamail.com (Vito Vessia) Date: Wed, 5 Aug 2015 16:35:37 +0200 Subject: [keycloak-user] Roles for User Management In-Reply-To: <55C1D078.6020107@redhat.com> References: <55C1D078.6020107@redhat.com> Message-ID: Hi Marek, thank you very much for the answer. I have been created the issue KEYCLOAK-1735. Best regards --Vito 2015-08-05 10:59 GMT+02:00 Marek Posolda : > On 4.8.2015 18:00, Vito Vessia wrote: > > Hi all, > I'm trying to use KC for a suite of multitenant webapps. Each > tenant/customer has a separated realm and I use a custom Federation > Provider to map users and roles to my company's legacy custom ACL database. > Customers also want to manage/create users by their own, but I don't want > they manage other realm stuff like Federation Provider parameters, client > apps, etc, so I have to provide to some users of each realm the only roles > of "manage-user"/"view-users" from the app realm-management, so they can > only view the Manage User option in the realm Console. > The problem is that through the console they may promote themselves > assigning to existing users or to new users the role of "manage-realm" and > after a simple refresh they can manage the entire realm. > Is there a way to avoid this or am I wrong to do this? > > Looks like not. Feel free to create JIRA for this. > > One more question connected to this one: is there a way to localize also > the realm console? If my customers have to manage their own users, they > would read labels and messages in their own languages. > Thank you very much for your time and for your great and versatile product. > > AFAIK Stan is looking at admin console localization. Maybe it will be in > 1.5 release. > > Marek > > > Best regards > --Vito > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/04b768aa/attachment.html From bburke at redhat.com Wed Aug 5 11:27:39 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 5 Aug 2015 11:27:39 -0400 Subject: [keycloak-user] WebSockets In-Reply-To: <55C209DE.6080000@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> <55C1C134.8060408@redhat.com> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> Message-ID: <55C22B6B.5090704@redhat.com> On 8/5/2015 9:04 AM, Juraci Paix?o Kr?hling wrote: > On 08/05/2015 01:52 PM, Marek Posolda wrote: >> Doing at the beginning of the connection might be easy. We may just need >> to add support to adapters for authentication via bearer token sent in >> URL query parameter or in the POST body. There is also specs for it >> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param > > The main problem with this is that a token might be valid at the time > the connection is made, but might not be valid after some time, while > the socket is still opened. So, a socket that was opened with a session > that just expired would still be open. > > Perhaps undertow provides something that would allow the adapter to > close sockets whose tokens are not valid anymore? > In most cases, a logout can be covered in a browser app that uses keycloak.js. When the browser app detects a logout it just closes all websocket connections. Keycloak is not going to secure each individual websocket request as this communication is all proprietary. Its up to you guys to transmit and validate the token in your own protocol. Keycloak can only transmit and validate the token on the initial connect, as that is standardized. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From german.tejero at gmail.com Wed Aug 5 13:46:56 2015 From: german.tejero at gmail.com (Carlos German Tejero) Date: Wed, 5 Aug 2015 14:46:56 -0300 Subject: [keycloak-user] Upgrade Keycloak 1.3.1 to 1.4.0 Message-ID: I have installed Keycloak 1.3.1 as a subsystem, on a Wildfly 9.0.1. How is the procedure for upgrade it to 1.4.0? Tanks to all! -- Carlos Germ?n Tejero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150805/a2f70e9f/attachment-0001.html From chenkeong.yap at izeno.com Wed Aug 5 19:43:50 2015 From: chenkeong.yap at izeno.com (chenkeong.yap at izeno.com) Date: Thu, 6 Aug 2015 07:43:50 +0800 Subject: [keycloak-user] keycloak application or client role mapping Message-ID: hi, do you know where the role mapping for app or client is stored in which table? Regards, CK Yap From ed.hillmann at gmail.com Wed Aug 5 21:34:55 2015 From: ed.hillmann at gmail.com (Ed Hillmann) Date: Thu, 6 Aug 2015 11:34:55 +1000 Subject: [keycloak-user] Keycloak in Azure VM? Message-ID: Hi. Has anyone had luck accessing Keycloak in a VM in Azure? I've got it running, I believe. But I cannot access it all from my browser. What I have done - Created a VM in Azure (Ubuntu 15), and this created an equivalent Cloud Service in Azure - Installed a Java8 JDK to the VM - Installed Keycloak 1.4.0 Final, standalone - Created a self-signed certificate in a Keystore (as per the doco) - Configured the standalone config to use the keystore (as per the doco) - Started keycloak using standalone.sh At this point, the log file looks like instances I have run on my local PC. There's nothing in there that looks any difference. For the Azure VM, I've added the following endpoints public 80 maps to private 8080 public 443 maps to private 8443 public 9990 maps to private 9990 public 9993 maps to private 9993 Any attempt to access the instance from my browser, however, ends up pwith a connection refused error. I can't even get to the launching page, let alone the admin console. Are there additional ports that need to be opened? If anyone has done this and can point out a missing step, I'd be very happy to have the help. Thanks, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/5a5d5df6/attachment.html From gregj at thesoftwarecottage.com.au Wed Aug 5 21:45:53 2015 From: gregj at thesoftwarecottage.com.au (Greg Jones) Date: Thu, 6 Aug 2015 11:45:53 +1000 Subject: [keycloak-user] Keycloak in Azure VM? In-Reply-To: References: Message-ID: Hi Ed, Make sure the Keycloak server is running on your public IP address, not just localhost. This can be forced by using the -b flag on the standalone.sh command. You can use -b 0.0.0.0 to tell it to use all available IP addresses. Regards, Greg Jones > On 6 Aug 2015, at 11:34 am, Ed Hillmann wrote: > > Hi. Has anyone had luck accessing Keycloak in a VM in Azure? I've got it running, I believe. But I cannot access it all from my browser. What I have done > > - Created a VM in Azure (Ubuntu 15), and this created an equivalent Cloud Service in Azure > - Installed a Java8 JDK to the VM > - Installed Keycloak 1.4.0 Final, standalone > - Created a self-signed certificate in a Keystore (as per the doco) > - Configured the standalone config to use the keystore (as per the doco) > - Started keycloak using standalone.sh > > At this point, the log file looks like instances I have run on my local PC. There's nothing in there that looks any difference. > > For the Azure VM, I've added the following endpoints > > public 80 maps to private 8080 > public 443 maps to private 8443 > public 9990 maps to private 9990 > public 9993 maps to private 9993 > > Any attempt to access the instance from my browser, however, ends up pwith a connection refused error. I can't even get to the launching page, let alone the admin console. > > Are there additional ports that need to be opened? If anyone has done this and can point out a missing step, I'd be very happy to have the help. > > Thanks, > Ed > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From ed.hillmann at gmail.com Wed Aug 5 22:37:42 2015 From: ed.hillmann at gmail.com (Ed Hillmann) Date: Thu, 6 Aug 2015 12:37:42 +1000 Subject: [keycloak-user] Fwd: Keycloak in Azure VM? In-Reply-To: References:

Message-ID: That was it! I passed it -b 0.0.0.0 and I'm getting through. Thanks heaps! On Thu, Aug 6, 2015 at 11:45 AM, Greg Jones wrote: > Hi Ed, > > Make sure the Keycloak server is running on your public IP address, not > just localhost. This can be forced by using the -b flag on the > standalone.sh command. You can use -b 0.0.0.0 to tell it to use all > available IP addresses. > > Regards, > Greg Jones > > > > On 6 Aug 2015, at 11:34 am, Ed Hillmann wrote: > > > > Hi. Has anyone had luck accessing Keycloak in a VM in Azure? I've got > it running, I believe. But I cannot access it all from my browser. What I > have done > > > > - Created a VM in Azure (Ubuntu 15), and this created an equivalent > Cloud Service in Azure > > - Installed a Java8 JDK to the VM > > - Installed Keycloak 1.4.0 Final, standalone > > - Created a self-signed certificate in a Keystore (as per the doco) > > - Configured the standalone config to use the keystore (as per the doco) > > - Started keycloak using standalone.sh > > > > At this point, the log file looks like instances I have run on my local > PC. There's nothing in there that looks any difference. > > > > For the Azure VM, I've added the following endpoints > > > > public 80 maps to private 8080 > > public 443 maps to private 8443 > > public 9990 maps to private 9990 > > public 9993 maps to private 9993 > > > > Any attempt to access the instance from my browser, however, ends up > pwith a connection refused error. I can't even get to the launching page, > let alone the admin console. > > > > Are there additional ports that need to be opened? If anyone has done > this and can point out a missing step, I'd be very happy to have the help. > > > > Thanks, > > Ed > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/7ba406d1/attachment.html From mposolda at redhat.com Thu Aug 6 03:19:52 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 06 Aug 2015 09:19:52 +0200 Subject: [keycloak-user] Upgrade Keycloak 1.3.1 to 1.4.0 In-Reply-To: References: Message-ID: <55C30A98.4080309@redhat.com> Hi, you can just download 1.4.0 distribution and configure it with same DB, which you previously used for 1.3.1. If you use default H2 db, you may just need copy files from your previous 1.3.1 distribution from standalone/data directory to 1.4.0. Ideally, you can backup your DB before upgrade, so you won't lose the data if upgrade fails. But ideally upgrade DB should work fine unless there is bug... More info: http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html Marek On 5.8.2015 19:46, Carlos German Tejero wrote: > I have installed Keycloak 1.3.1 as a subsystem, on a Wildfly 9.0.1. > > How is the procedure for upgrade it to 1.4.0? > > Tanks to all! > > > -- > Carlos Germ?n Tejero > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/ef88e062/attachment.html From mposolda at redhat.com Thu Aug 6 03:22:10 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 06 Aug 2015 09:22:10 +0200 Subject: [keycloak-user] keycloak application or client role mapping In-Reply-To: References: Message-ID: <55C30B22.80901@redhat.com> If you use JPA model (default setup) it's USER_ROLE_MAPPING table. Marek On 6.8.2015 01:43, chenkeong.yap at izeno.com wrote: > hi, > > do you know where the role mapping for app or client is stored in which table? > > Regards, > CK Yap > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Thu Aug 6 03:44:23 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 06 Aug 2015 09:44:23 +0200 Subject: [keycloak-user] Distributed Keycloak user sessions using Infinispan In-Reply-To: References: <59651412.706872.1438003614393.JavaMail.zimbra@redhat.com> <1045151906.720245.1438004746473.JavaMail.zimbra@redhat.com> <1732913135.720424.1438004774275.JavaMail.zimbra@redhat.com> <1042060711.1068309.1438058940079.JavaMail.zimbra@redhat.com> <966246176.551354.1438190443054.JavaMail.zimbra@redhat.com> Message-ID: <55C31057.90801@redhat.com> I've finally reproduced the issue and looking at it. Will update you once I have fix. Marek On 5.8.2015 14:14, Nair, Rajat wrote: > Some more information - > > Quick summary - I'm trying to test HA of Keycloak user sessions when one of the nodes goes down, users should not have to login again as their session information would be available on other node. Keycloak cluster is setup to store users session on Infinispan (testing using distributed-cache and replicated-cache). > > To see the cache information on Keycloak nodes, I setup hawtio on these node. Initial state of caches on both the nodes are captured in these images (see 110.DC.Start.png and 111.DC.Start.png) > Then user logs into server 111. We can see the session entry value increasing (see 111.DC.Login.On.111.PNG). When we look at session entry on 110 server, we see that the count has increased there too. That means that they session is being successfully replicated (see 110.DC.Login.On.111.PNG). > > To verify if this works other way around, we logged into server 110, and its session entry count increased (see 110.DC.Login.On.110.And.111.PNG). When we check 111, we can see that session entry count increased on this server too. (see 111.DC.Login.On.110.And.111.png). > > We initially suspected that our sessions were not getting replicated. Using hawtio, we can see session entry count increasing on both servers. Could this mean that there is a bug in Keycloak's code while fetching user sessions? Is there any other way we can validate user sessions? > > -- Rajat > > -----Original Message----- > From: Nair, Rajat > Sent: 03 August 2015 12:43 > To: 'Stian Thorgersen'; Marek Posolda > Cc: keycloak-user at lists.jboss.org > Subject: RE: [keycloak-user] Distributed Keycloak user sessions using Infinispan > > Hi, > > Some more info from log of test-server-110 server (server names are test-server-110 and test-server-111) - Infinispan subsystem initialized logs for sessions cache - [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 39) WFLYCLINF0001: Activating Infinispan subsystem. > [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000078: Starting JGroups channel keycloak [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000094: Received new cluster view for channel keycloak: [test-server-111|0] (1) [test-server-111] [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 62) ISPN000079: Channel keycloak local address is test-server-111, physical addresses are [XX.XX.XX.XX:7600] [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0002: Started sessions cache from keycloak container [org.infinispan.CLUSTER] (remote-thread--p3-t3) ISPN000310: Starting cluster-wide rebalance for cache sessions, topology CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.CLUSTER] (remote-thread--p3-t2) ISPN000336: Finished cluster-wide rebalance for cache sessions, topology id = 1 > > Session cache details - > [org.infinispan.jmx.JmxUtil] (ServerService Thread Pool -- 63) Object name jboss.infinispan:type=Cache,name="sessions(dist_sync)",manager="keycloak",component=Cache already registered [org.infinispan.topology.LocalTopologyManagerImpl] (ServerService Thread Pool -- 63) Node test-server-110 joining cache sessions [org.infinispan.topology.LocalTopologyManagerImpl] (ServerService Thread Pool -- 63) Updating local topology for cache sessions: CacheTopology{id=0, rebalanceId=0, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=null, unionCH=null, actualMembers=[test-server-111]} [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t5) Updating local topology for cache sessions: CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t5) Starting local rebalance for cache sessions, topology = CacheTopology{id=1, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t5) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t5) Removing no longer owned entries for cache sessions [org.infinispan.statetransfer.InboundTransferTask] (stateTransferExecutor-thread--p5-t19) Finished receiving state for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions [org.infinispan.statetransfer.StateConsumerImpl] (stateTransferExecutor-thread--p5-t24) Finished receiving of segments for cache sessions for topology 1. > [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t10) Updating local topology for cache sessions: CacheTopology{id=2, rebalanceId=1, currentCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: 40+40, test-server-110: 40+40]}, pendingCH=null, unionCH=null, actualMembers=[test-server-111, test-server-110]} [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread--p2-t10) Removing no longer owned entries for cache sessions [org.infinispan.cache.impl.CacheImpl] (ServerService Thread Pool -- 63) Started cache sessions on test-server-110 [org.wildfly.clustering.infinispan.spi.service.CacheBuilder] (ServerService Thread Pool -- 63) sessions keycloak cache started > > > Looks like the servers are talking to each other (setup on unicast) and session cache between the servers are shared, but we still cannot successfully fetch user info when token is generated by one server (test-server-110) and data from another (test-server-111). > > Any suggestions/debugging approaches appreciated. > > -- Rajat > > -----Original Message----- > From: Stian Thorgersen [mailto:stian at redhat.com] > Sent: 29 July 2015 22:51 > To: Nair, Rajat; Marek Posolda > Cc: keycloak-user at lists.jboss.org > Subject: Re: [keycloak-user] Distributed Keycloak user sessions using Infinispan > > I'm away on holiday, Marek can you take a look at this? > > ----- Original Message ----- >> From: "Rajat Nair" >> To: "Stian Thorgersen" >> Cc: keycloak-user at lists.jboss.org >> Sent: Wednesday, 29 July, 2015 2:56:07 PM >> Subject: RE: [keycloak-user] Distributed Keycloak user sessions using >> Infinispan >> >> Follow up to our discussion - >> >> I upgrade my nodes to Keycloak 1.4 Final. Dropped and re-created >> database Postgres database (shared between both the nodes) and tested >> distributed user session using following commands - >> - Fetch access token using following curl from one server >> curl --write-out " %{http_code}" -s --request POST --header "Content-Type: >> application/x-www-form-urlencoded; charset=UTF-8" --data >> "username=user1 at email.com&password=testpassword@&client_id=admin-client&grant_type=password" >> "http://test-server-110:8080/auth/realms/test/protocol/openid-connect/token" >> >> - Validated the token on different server using >> curl --write-out " %{http_code}" -s --request GET --header "Content-Type: >> application/json" --header "Authorization: Bearer >> [ACCESS_TOKEN_FROM_PREVIOUS_CALL]" >> "http://test-server-111:8081/auth/realms/test/protocol/openid-connect/userinfo" >> >> And we get this - {"error":"invalid_grant","error_description":"Token >> invalid"} >> No more NPE and internal server error. >> >> If we use the same token and try to fetch user details on server which >> issued the token - we get the correct data. (Note - I have confirmed >> that the token has not expired) >> >>> One thing you can try is to make sure user session replication is >>> working >>> properly: >>> 1. Start two nodes >>> 2. Open admin console directly on node 1 - login as admin/admin 3. >>> Open admin console directly on node 2 from another machine/browser >>> or use incognito mode - login as admin/admin 4. On node 1 go to >>> users -> view all >>> -> click on admin -> sessions - > > you should see two sessions 5. >>> -> On node >>> 2 do the same and check you can see two sessions there as well >> Now this is where things get strange. I followed the steps described - >> used 2 different browsers - and I can see 2 sessions listed! >> >> Are the process we use to validate the token incorrect? Or is master >> console on the web doing something different (like get the data from >> Postgres database used by both the nodes). >> >> -- Rajat >> >> -----Original Message----- >> From: Stian Thorgersen [mailto:stian at redhat.com] >> Sent: 28 July 2015 10:19 >> To: Nair, Rajat >> Cc: keycloak-user at lists.jboss.org >> Subject: Re: [keycloak-user] Distributed Keycloak user sessions using >> Infinispan >> >> >> >> ----- Original Message ----- >>> From: "Rajat Nair" >>> To: "Stian Thorgersen" >>> Cc: keycloak-user at lists.jboss.org >>> Sent: Monday, 27 July, 2015 7:33:25 PM >>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>> using Infinispan >>> >>>> Can you send me your standalone-ha.xml and keycloak-server.json? >>> Files attached. The service is started like - >>> /opt/jboss/keycloak/bin/standalone.sh -c standalone-ha.xml >>> -b=test-server-110 >>> -bmanagement=test-server-110 -u 230.0.0.4 >>> -Djboss.node.name=test-server-110 >>> >>>> Also, any chance you can try it out with master? I've been testing >>>> with that as we're about to do 1.4 release soon >>> Glad to give back to the community. Will build and deploy the master >>> on my nodes. Will send findings tomorrow. >>> >>> Regarding a scenario I described earlier - Case 2 1. Start with 1 >>> Node down. We bring it back up. We wait for some time so that >>> Infinispan can sync. >>> 2. Bring down other node. >>> 3. Try to get user info using existing token. >>> >>> Is this a valid use-case? >> Yes - I've tried the same use-case and it works fine every time. One >> caveat is that access token can expire, but in this case you should >> get a 403 returned, not a NPE exception and 500. >> >> One thing you can try is to make sure user session replication is >> working >> properly: >> >> 1. Start two nodes >> 2. Open admin console directly on node 1 - login as admin/admin 3. >> Open admin console directly on node 2 from another machine/browser or >> use incognito mode - login as admin/admin 4. On node 1 go to users -> >> view all -> click on admin -> sessions - you should see two sessions >> 5. On node 2 do the same and check you can see two sessions there as >> well >> >>> -- Rajat >>> >>> -----Original Message----- >>> From: Stian Thorgersen [mailto:stian at redhat.com] >>> Sent: 27 July 2015 19:16 >>> To: Nair, Rajat >>> Cc: keycloak-user at lists.jboss.org >>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>> using Infinispan >>> >>> Also, any chance you can try it out with master? I've been testing >>> with that as we're about to do 1.4 release soon >>> >>> ----- Original Message ----- >>>> From: "Stian Thorgersen" >>>> To: "Rajat Nair" >>>> Cc: keycloak-user at lists.jboss.org >>>> Sent: Monday, 27 July, 2015 3:45:46 PM >>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>> using Infinispan >>>> >>>> Can you send me your standalone-ha.xml and keycloak-server.json? >>>> >>>> ----- Original Message ----- >>>>> From: "Rajat Nair" >>>>> To: "Stian Thorgersen" >>>>> Cc: keycloak-user at lists.jboss.org >>>>> Sent: Monday, 27 July, 2015 3:41:36 PM >>>>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>>>> using Infinispan >>>>> >>>>>> Do you have both nodes fully up and running before you kill one node? >>>>> Yes. >>>>> This is what we tried - >>>>> Case 1 >>>>> 1. Two node cluster (both running Keycloak engines) - both up >>>>> and running. >>>>> Configured load balancing using mod_cluster. >>>>> 2. Login and get token. >>>>> 3. Bring down one node. >>>>> 4. Get user info using existing token. This is when we get NPE. >>>>> >>>>> Case 2 >>>>> 1. Start with 1 Node down. We bring it back up. We wait for some >>>>> time so that Infinispan can sync. >>>>> 2. Bring down other node. >>>>> 3. Try to get user info using existing token. Again we see NPE. >>>>> >>>>>> It's a bug - if session is expired it should return an error >>>>>> message, not a NPE (see >>>>>> https://issues.jboss.org/browse/KEYCLOAK-1710) >>>>> Thanks for tracking this. >>>>> >>>>> -- Rajat >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Rajat Nair" >>>>>> To: "Stian Thorgersen" >>>>>> Cc: keycloak-user at lists.jboss.org >>>>>> Sent: Monday, 27 July, 2015 3:20:27 PM >>>>>> Subject: RE: [keycloak-user] Distributed Keycloak user >>>>>> sessions using Infinispan >>>>>> >>>>>> Thanks for quick reply Stian. >>>>>> >>>>>>> What version? >>>>>> We are using Keycloak 1.3.1 Final. >>>>>> >>>>>>> Did you remember to change userSessions provider to >>>>>>> infinispan in keycloak-server.json? >>>>>> Yes. We got following in keycloak-server.json - >>>>>> "userSessions": { >>>>>> "provider": "infinispan" >>>>>> } >>>>>> >>>>>>> Firstly owners="2" should work fine as long as only one node >>>>>>> dies and the other remains active. Secondly it should return >>>>>>> a NPE, but an error if user session is not found. >>>>>> Could you elaborate on your 2nd point? >>>>> Do you have both nodes fully up and running before you kill one node? >>>>> >>>>> It's a bug - if session is expired it should return an error >>>>> message, not a NPE (see >>>>> https://issues.jboss.org/browse/KEYCLOAK-1710) >>>>> >>>>>> -- Rajat >>>>>> >>>>>> -----Original Message----- >>>>>> From: Stian Thorgersen [mailto:stian at redhat.com] >>>>>> Sent: 27 July 2015 18:07 >>>>>> To: Nair, Rajat >>>>>> Cc: keycloak-user at lists.jboss.org >>>>>> Subject: Re: [keycloak-user] Distributed Keycloak user >>>>>> sessions using Infinispan >>>>>> >>>>>> Did you remember to change userSessions provider to infinispan >>>>>> in keycloak-server.json? >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Stian Thorgersen" >>>>>>> To: "Rajat Nair" >>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>> Sent: Monday, 27 July, 2015 2:24:17 PM >>>>>>> Subject: Re: [keycloak-user] Distributed Keycloak user >>>>>>> sessions using Infinispan >>>>>>> >>>>>>> What version? >>>>>>> >>>>>>> Firstly owners="2" should work fine as long as only one node >>>>>>> dies and the other remains active. Secondly it should return >>>>>>> a NPE, but an error if user session is not found. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Rajat Nair" >>>>>>>> To: keycloak-user at lists.jboss.org >>>>>>>> Sent: Monday, 27 July, 2015 2:03:47 PM >>>>>>>> Subject: [keycloak-user] Distributed Keycloak user >>>>>>>> sessions using Infinispan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I?m in the process of setting up distributed user sessions >>>>>>>> using Infinispan on my Keycloak cluster. This is the >>>>>>>> configuration I use ? >>>>>>>> >>>>>>>> >>>>>>> jndi-name="java:jboss/infinispan/Keycloak"> >>>>>>>> lock-timeout="60000"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> owners="2"/> >>>>>>>> >>>>>>>> >>>>>>> owners="1"/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> And in server.logs, I can see my servers communicate ? >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,662 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t7) >>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>> users, topology CacheTopology{id=57, rebalanceId=17, >>>>>>>> currentCH=ReplicatedConsistentHash{ns >>>>>>>> = >>>>>>>> 60, owners = (1)[test-server-110: 60]}, >>>>>>>> pendingCH=ReplicatedConsistentHash{ns = 60, owners = >>>>>>>> (2)[test-server-110: >>>>>>>> 30, test-server-111: 30]}, unionCH=null, >>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t10) >>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>> realms, topology CacheTopology{id=57, rebalanceId=17, >>>>>>>> currentCH=ReplicatedConsistentHash{ns >>>>>>>> = >>>>>>>> 60, owners = (1)[test-server-110: 60]}, >>>>>>>> pendingCH=ReplicatedConsistentHash{ns = 60, owners = >>>>>>>> (2)[test-server-110: >>>>>>>> 30, test-server-111: 30]}, unionCH=null, >>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t8) >>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>> loginFailures, topology CacheTopology{id=57, >>>>>>>> rebalanceId=17, currentCH=DefaultConsistentHash{ns=80, >>>>>>>> owners = >>>>>>>> (1)[test-server-110: >>>>>>>> 80+0]}, >>>>>>>> pendingCH=DefaultConsistentHash{ns=80, owners = >>>>>>>> (2)[test-server-110: >>>>>>>> 40+0, >>>>>>>> test-server-111: 40+0]}, unionCH=null, >>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,669 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t9) >>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>> sessions, topology CacheTopology{id=56, rebalanceId=17, >>>>>>>> currentCH=DefaultConsistentHash{ns=80, >>>>>>>> owners = (1)[test-server-110: 80+0]}, >>>>>>>> pendingCH=DefaultConsistentHash{ns=80, >>>>>>>> owners = (2)[test-server-110: 40+0, test-server-111: >>>>>>>> 40+0]}, unionCH=null, actualMembers=[test-server-110, >>>>>>>> test-server-111]} >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,808 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t9) >>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>> loginFailures, topology id = 57 >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,810 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t12) >>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>> sessions, topology id = 56 >>>>>>>> >>>>>>>> 2015-07-27 10:27:24,988 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t12) >>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>> realms, topology id = >>>>>>>> 57 >>>>>>>> >>>>>>>> 2015-07-27 10:27:25,530 INFO [org.infinispan.CLUSTER] >>>>>>>> (remote-thread--p3-t8) >>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>> users, topology id = >>>>>>>> 57 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I can successfully login, get a token and fetch user >>>>>>>> details with this token. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Problem is, if one of the nodes on the cluster goes down >>>>>>>> and if we try to reuse a token which was already issued >>>>>>>> (so workflow is ? user logins in, get token, (a node in >>>>>>>> the cluster goes down) and then fetch user details using >>>>>>>> token) ? we see an internal server exception. From the >>>>>>>> logs ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-07-27 10:24:25,714 ERROR [io.undertow.request] >>>>>>>> (default >>>>>>>> task-1) >>>>>>>> UT005023: Exception handling request to >>>>>>>> /auth/realms/scaletest/protocol/openid-connect/userinfo: >>>>>>>> java.lang.RuntimeException: request path: >>>>>>>> /auth/realms/scaletest/protocol/openid-connect/userinfo >>>>>>>> >>>>>>>> at >>>>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter >>>>>>>> .d >>>>>>>> oF >>>>>>>> ilte >>>>>>>> r( >>>>>>>> KeycloakSessionServletFilter.java:54) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. >>>>>>>> java >>>>>>>> :6 >>>>>>>> 0) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>> .d >>>>>>>> oF >>>>>>>> ilte >>>>>>>> r( >>>>>>>> FilterHandler.java:132) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(F >>>>>>>> il >>>>>>>> te >>>>>>>> rHan >>>>>>>> dl >>>>>>>> er.java:85) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleH >>>>>>>> an >>>>>>>> dl >>>>>>>> er.h >>>>>>>> an >>>>>>>> dleRequest(ServletSecurityRoleHandler.java:62) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.han >>>>>>>> dl >>>>>>>> eR >>>>>>>> eque >>>>>>>> st >>>>>>>> (ServletDispatchingHandler.java:36) >>>>>>>> >>>>>>>> at >>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAss >>>>>>>> oc >>>>>>>> ia >>>>>>>> tion >>>>>>>> Ha >>>>>>>> ndler.handleRequest(SecurityContextAssociationHandler.java >>>>>>>> :7 >>>>>>>> 8) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>> (P >>>>>>>> re >>>>>>>> dica >>>>>>>> te >>>>>>>> Handler.java:43) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssoci >>>>>>>> at >>>>>>>> io >>>>>>>> nHan >>>>>>>> dl >>>>>>>> er.handleRequest(SSLInformationAssociationHandler.java:131 >>>>>>>> ) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticatio >>>>>>>> nC >>>>>>>> al >>>>>>>> lHan >>>>>>>> dl >>>>>>>> er.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>> (P >>>>>>>> re >>>>>>>> dica >>>>>>>> te >>>>>>>> Handler.java:43) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandl >>>>>>>> er >>>>>>>> .h >>>>>>>> andl >>>>>>>> eR >>>>>>>> equest(AbstractConfidentialityHandler.java:46) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.security.ServletConfidentiali >>>>>>>> ty >>>>>>>> Co >>>>>>>> nstr >>>>>>>> ai >>>>>>>> ntHandler.handleRequest(ServletConfidentialityConstraintHa >>>>>>>> nd >>>>>>>> le >>>>>>>> r.ja >>>>>>>> va >>>>>>>> :64) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler. >>>>>>>> hand >>>>>>>> le >>>>>>>> Request(AuthenticationMechanismsHandler.java:58) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedS >>>>>>>> es >>>>>>>> si >>>>>>>> onHa >>>>>>>> nd >>>>>>>> ler.handleRequest(CachedAuthenticatedSessionHandler.java:7 >>>>>>>> 2) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.security.handlers.NotificationReceiverHandler. >>>>>>>> ha >>>>>>>> nd >>>>>>>> leRe >>>>>>>> qu >>>>>>>> est(NotificationReceiverHandler.java:50) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handl >>>>>>>> eR >>>>>>>> eq >>>>>>>> uest >>>>>>>> (S >>>>>>>> ecurityInitialHandler.java:76) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>> (P >>>>>>>> re >>>>>>>> dica >>>>>>>> te >>>>>>>> Handler.java:43) >>>>>>>> >>>>>>>> at >>>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler. >>>>>>>> ha >>>>>>>> ndleRequest(JACCContextIdHandler.java:61) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>> (P >>>>>>>> re >>>>>>>> dica >>>>>>>> te >>>>>>>> Handler.java:43) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>> (P >>>>>>>> re >>>>>>>> dica >>>>>>>> te >>>>>>>> Handler.java:43) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.handlers.MetricsHandler.handleRequest(M >>>>>>>> et >>>>>>>> ri >>>>>>>> csHa >>>>>>>> nd >>>>>>>> ler.java:62) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.core.MetricsChainHandler.handleRequest >>>>>>>> (M >>>>>>>> et >>>>>>>> rics >>>>>>>> Ch >>>>>>>> ainHandler.java:59) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleF >>>>>>>> ir >>>>>>>> st >>>>>>>> Requ >>>>>>>> es >>>>>>>> t(ServletInitialHandler.java:274) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatc >>>>>>>> hR >>>>>>>> eq >>>>>>>> uest >>>>>>>> (S >>>>>>>> ervletInitialHandler.java:253) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$ >>>>>>>> 00 >>>>>>>> 0( >>>>>>>> Serv >>>>>>>> le >>>>>>>> tInitialHandler.java:80) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handl >>>>>>>> eR >>>>>>>> eq >>>>>>>> uest >>>>>>>> (S >>>>>>>> ervletInitialHandler.java:172) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors. >>>>>>>> ja >>>>>>>> va:1 >>>>>>>> 99 >>>>>>>> ) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java: >>>>>>>> 774) >>>>>>>> >>>>>>>> at >>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>>>>> Source) >>>>>>>> >>>>>>>> at >>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>>>>> Source) >>>>>>>> >>>>>>>> at java.lang.Thread.run(Unknown Source) >>>>>>>> >>>>>>>> Caused by: org.jboss.resteasy.spi.UnhandledException: >>>>>>>> java.lang.NullPointerException >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ExceptionHandler.handleApplication >>>>>>>> Ex >>>>>>>> ce >>>>>>>> ptio >>>>>>>> n( >>>>>>>> ExceptionHandler.java:76) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ExceptionHandler.handleException(E >>>>>>>> xc >>>>>>>> ep >>>>>>>> tion >>>>>>>> Ha >>>>>>>> ndler.java:212) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.writeExcepti >>>>>>>> on >>>>>>>> (S >>>>>>>> ynch >>>>>>>> ro >>>>>>>> nousDispatcher.java:149) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>> ro >>>>>>>> no >>>>>>>> usDi >>>>>>>> sp >>>>>>>> atcher.java:372) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>> ro >>>>>>>> no >>>>>>>> usDi >>>>>>>> sp >>>>>>>> atcher.java:179) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainer >>>>>>>> Di >>>>>>>> sp >>>>>>>> atch >>>>>>>> er >>>>>>>> .service(ServletContainerDispatcher.java:220) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispa >>>>>>>> tc >>>>>>>> he >>>>>>>> r.se >>>>>>>> rv >>>>>>>> ice(HttpServletDispatcher.java:56) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispa >>>>>>>> tc >>>>>>>> he >>>>>>>> r.se >>>>>>>> rv >>>>>>>> ice(HttpServletDispatcher.java:51) >>>>>>>> >>>>>>>> at >>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:79 >>>>>>>> 0) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest( >>>>>>>> Se >>>>>>>> rv >>>>>>>> letH >>>>>>>> an >>>>>>>> dler.java:86) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>> .d >>>>>>>> oF >>>>>>>> ilte >>>>>>>> r( >>>>>>>> FilterHandler.java:130) >>>>>>>> >>>>>>>> at >>>>>>>> org.keycloak.services.filters.ClientConnectionFilter.doFil >>>>>>>> te >>>>>>>> r( >>>>>>>> Clie >>>>>>>> nt >>>>>>>> ConnectionFilter.java:41) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. >>>>>>>> java >>>>>>>> :6 >>>>>>>> 0) >>>>>>>> >>>>>>>> at >>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>> .d >>>>>>>> oF >>>>>>>> ilte >>>>>>>> r( >>>>>>>> FilterHandler.java:132) >>>>>>>> >>>>>>>> at >>>>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter >>>>>>>> .d >>>>>>>> oF >>>>>>>> ilte >>>>>>>> r( >>>>>>>> KeycloakSessionServletFilter.java:40) >>>>>>>> >>>>>>>> ... 31 more >>>>>>>> >>>>>>>> Caused by: java.lang.NullPointerException >>>>>>>> >>>>>>>> at >>>>>>>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu >>>>>>>> eU >>>>>>>> se >>>>>>>> rInf >>>>>>>> o( >>>>>>>> UserInfoEndpoint.java:128) >>>>>>>> >>>>>>>> at >>>>>>>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu >>>>>>>> eU >>>>>>>> se >>>>>>>> rInf >>>>>>>> oG >>>>>>>> et(UserInfoEndpoint.java:101) >>>>>>>> >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method) >>>>>>>> >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown >>>>>>>> Source) >>>>>>>> >>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown >>>>>>>> Source) >>>>>>>> >>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodIn >>>>>>>> je >>>>>>>> ct >>>>>>>> orIm >>>>>>>> pl >>>>>>>> .java:137) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarg >>>>>>>> et >>>>>>>> (R >>>>>>>> esou >>>>>>>> rc >>>>>>>> eMethodInvoker.java:296) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resou >>>>>>>> rc >>>>>>>> eM >>>>>>>> etho >>>>>>>> dI >>>>>>>> nvoker.java:250) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar >>>>>>>> ge >>>>>>>> tO >>>>>>>> bjec >>>>>>>> t( >>>>>>>> ResourceLocatorInvoker.java:140) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso >>>>>>>> ur >>>>>>>> ce >>>>>>>> Loca >>>>>>>> to >>>>>>>> rInvoker.java:109) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar >>>>>>>> ge >>>>>>>> tO >>>>>>>> bjec >>>>>>>> t( >>>>>>>> ResourceLocatorInvoker.java:135) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso >>>>>>>> ur >>>>>>>> ce >>>>>>>> Loca >>>>>>>> to >>>>>>>> rInvoker.java:103) >>>>>>>> >>>>>>>> at >>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>> ro >>>>>>>> no >>>>>>>> usDi >>>>>>>> sp >>>>>>>> atcher.java:356) >>>>>>>> >>>>>>>> ... 42 more >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The user guide says ? >>>>>>>> >>>>>>>> If you need to prevent node failures from requiring users >>>>>>>> to log in again, set the owners attribute to 2 or more for >>>>>>>> the sessions cache >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Questions - >>>>>>>> >>>>>>>> 1. Have we configured Infinispan incorrectly? We don?t >>>>>>>> want the users to login again if any of the nodes in the >>>>>>>> cluster go down. >>>>>>>> >>>>>>>> 2. Will changing distributed-cache to replicated-cache >>>>>>>> help in this scenario? >>>>>>>> >>>>>>>> 3. Any way we can see the contents of the cache? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- Rajat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 tair.sabirgaliev at bee.kz Thu Aug 6 03:52:29 2015 From: tair.sabirgaliev at bee.kz (Tair Sabirgaliev) Date: Thu, 6 Aug 2015 13:52:29 +0600 Subject: [keycloak-user] Custom Authentication and Registration flow Message-ID: Hi, 2 questions here: - How can we add custom authentication mechanisms? - How to customize registration flow? Are they pluggable now? Do you plan to implement SPIs? Thanks! --? Tair Sabirgaliev Bee Software, LLP -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/fe772711/attachment.html From emil.posmyk at gmail.com Thu Aug 6 06:31:13 2015 From: emil.posmyk at gmail.com (Emil Posmyk) Date: Thu, 6 Aug 2015 12:31:13 +0200 Subject: [keycloak-user] Keycloak 1.4.0.Final - new schema (defined in file keycloak-server.json) Message-ID: Hi all I did upgrade from keycloak 1.1.0.Final to 1.4.0.Final, but I had some issue. When I tried to add "schema": "security" in section "connectionsJpa" to file keycloak-server.json and run first time server to create everything on database. I recived an error related with liquibase, "REALM" etc. Second time i solved it becouse I created default schema and after it I changed to schema "security" manually on database and later in file keycloak-server.json. It is possible to change the schema without changing manually schema on database ? *thanks* *--* *Emil Posmyk* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/e519e9ae/attachment.html From german.tejero at gmail.com Thu Aug 6 07:08:30 2015 From: german.tejero at gmail.com (Carlos German Tejero) Date: Thu, 6 Aug 2015 08:08:30 -0300 Subject: [keycloak-user] Upgrade Keycloak 1.3.1 to 1.4.0 In-Reply-To: <55C30A98.4080309@redhat.com> References: <55C30A98.4080309@redhat.com> Message-ID: Thanks Marek! But, can i upgrade the keycloak 1.3.1 subsystem to 1.4.0 in the same wildfly installation? 2015-08-06 4:19 GMT-03:00 Marek Posolda : > Hi, > > you can just download 1.4.0 distribution and configure it with same DB, > which you previously used for 1.3.1. If you use default H2 db, you may just > need copy files from your previous 1.3.1 distribution from standalone/data > directory to 1.4.0. Ideally, you can backup your DB before upgrade, so you > won't lose the data if upgrade fails. But ideally upgrade DB should work > fine unless there is bug... > > More info: > http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html > > Marek > > > On 5.8.2015 19:46, Carlos German Tejero wrote: > > I have installed Keycloak 1.3.1 as a subsystem, on a Wildfly 9.0.1. > > How is the procedure for upgrade it to 1.4.0? > > Tanks to all! > > > -- > Carlos Germ?n Tejero > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- Carlos Germ?n Tejero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/5b366bbe/attachment.html From bburke at redhat.com Thu Aug 6 08:45:26 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 6 Aug 2015 08:45:26 -0400 Subject: [keycloak-user] Custom Authentication and Registration flow In-Reply-To: References: Message-ID: <55C356E6.9090705@redhat.com> We have SPIs but they are not fully pluggable yet. We wanted to let them bake under the covers for a full release to catch any bugs we may have missed. "master" should have full ability through admin consle to create new flows and bind them in the next few days. Creation/editing is done, I just have to code the binding stuff... I took a small detour to implement HOTP. On 8/6/2015 3:52 AM, Tair Sabirgaliev wrote: > Hi, > > 2 questions here: > - How can we add custom authentication mechanisms? > - How to customize registration flow? > > Are they pluggable now? Do you plan to implement SPIs? > > Thanks! > > -- > Tair Sabirgaliev > Bee Software, LLP > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From emil.posmyk at gmail.com Thu Aug 6 11:40:17 2015 From: emil.posmyk at gmail.com (Emil Posmyk) Date: Thu, 6 Aug 2015 17:40:17 +0200 Subject: [keycloak-user] Direct access (keycloak migration from 1.1.0 to 1.4.0) Message-ID: Hi all I have a problem with direct access. I try to use similar code like is on page: http://keycloak.github.io/docs/userguide/html/direct-access-grants.html but every time I'm reciving bad request: status 400. There is one change comparing version 1.4.0.Final with version 1.1.0.Final: formparams.add(new BasicNameValuePair(OAuth2Constants.GRANT_TYPE, passwordValue)); I added into passwordValue password for user which was created in auth app before (not "secret"). My code looks like this: HttpPost post = new HttpPost(KeycloakUriBuilder.fromUri(" http://IPIPIPIP:8080/auth ").path(ServiceUrlConstants.TOKEN_PATH).build(realmName)); List formparams = new ArrayList (); formparams.add(new BasicNameValuePair(OAuth2Constants.GRANT_TYPE, passwordValue)); formparams.add(new BasicNameValuePair("username", "userName")); formparams.add(new BasicNameValuePair("password", passwordValue)); try { /*String authorization = BasicAuthHelper.createHeader("appNameId", secretAppName);//secretAppName post.setHeader("Authorization", authorization);*/ formparams.add(new BasicNameValuePair(OAuth2Constants.CLIENT_ID, "appNameId")); UrlEncodedFormEntity form = new UrlEncodedFormEntity(formparams, "UTF-8"); post.setEntity(form); final HttpClient client = new HttpClientBuilder().disableTrustManager().build(); HttpResponse response = client.execute(post); int status = response.getStatusLine().getStatusCode(); HttpEntity entity = response.getEntity(); if (status != 200) { throw new IOException("Bad status: " + status); } Any ideas how to solve it ? *thanks* *regards* *--* *Emil Posmyk* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150806/9face888/attachment.html From bburke at redhat.com Thu Aug 6 11:57:55 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 6 Aug 2015 11:57:55 -0400 Subject: [keycloak-user] Direct access (keycloak migration from 1.1.0 to 1.4.0) In-Reply-To: References: Message-ID: <55C38403.8050709@redhat.com> GRANT_TYPE should be "password" On 8/6/2015 11:40 AM, Emil Posmyk wrote: > Hi all > > I have a problem with direct access. I try to use similar code like is > on page: > http://keycloak.github.io/docs/userguide/html/direct-access-grants.html > but every time I'm reciving bad request: status 400. > > There is one change comparing version 1.4.0.Final with version 1.1.0.Final: > formparams.add(new BasicNameValuePair(OAuth2Constants.GRANT_TYPE, > passwordValue)); > I added into passwordValue password for user which was created in auth > app before (not "secret"). > > My code looks like this: > > HttpPost post = new > HttpPost(KeycloakUriBuilder.fromUri("http://IPIPIPIP:8080/auth").path(ServiceUrlConstants.TOKEN_PATH).build(realmName)); > List formparams = new ArrayList (); > formparams.add(new > BasicNameValuePair(OAuth2Constants.GRANT_TYPE, passwordValue)); > formparams.add(new BasicNameValuePair("username", "userName")); > formparams.add(new BasicNameValuePair("password", passwordValue)); > > try { > /*String authorization = > BasicAuthHelper.createHeader("appNameId", secretAppName);//secretAppName > post.setHeader("Authorization", authorization);*/ > formparams.add(new > BasicNameValuePair(OAuth2Constants.CLIENT_ID, "appNameId")); > UrlEncodedFormEntity form = new > UrlEncodedFormEntity(formparams, "UTF-8"); > post.setEntity(form); > > final HttpClient client = new > HttpClientBuilder().disableTrustManager().build(); > HttpResponse response = client.execute(post); > int status = response.getStatusLine().getStatusCode(); > HttpEntity entity = response.getEntity(); > if (status != 200) { > throw new IOException("Bad status: " + status); > } > > Any ideas how to solve it ? > > /thanks > > / > /regards > / > /--/ > /Emil Posmyk > / > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Thu Aug 6 12:05:47 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 06 Aug 2015 18:05:47 +0200 Subject: [keycloak-user] Distributed Keycloak user sessions using Infinispan In-Reply-To: <55C31057.90801@redhat.com> References: <59651412.706872.1438003614393.JavaMail.zimbra@redhat.com> <1045151906.720245.1438004746473.JavaMail.zimbra@redhat.com> <1732913135.720424.1438004774275.JavaMail.zimbra@redhat.com> <1042060711.1068309.1438058940079.JavaMail.zimbra@redhat.com> <966246176.551354.1438190443054.JavaMail.zimbra@redhat.com> <55C31057.90801@redhat.com> Message-ID: <55C385DB.6090705@redhat.com> It's clear that your infinispan cluster works as expected. I think the issue is, that you are sending curl requests directly to individual cluster nodes instead of loadbalancer. At least I saw it as an issue during my testing and I suspect that in your case it will be the same. Like in your example you first retrieved the token by curl request to http://test-server-110:8080 and then used this token to retrieve UserInfo by accessing on http://test-server-111:8081 . In this case, it doesn't work as issuer (iss field) in access token starts with URL "http://test-server-110:8080" , which means that this access token will be rejected on "http://test-server-111:8081" when sending request to UserInfo endpoint here. I've added a bit more info about error into UserInfo endpoint, so in latest master you can see additional details (I suspect that you will really see the error message about invalid issuer URL). So the solution is, that you will need to send requests to loadbalancer instead of individual cluster nodes. Like if your curl request to retrieve access token will be send to "http://loadbalancer:8080" and the UserInfo will be also accessed through loadbalancer, it will work because the issuer in access token will be "http://loadbalancer:8080" . You can try this and then add or remove cluster nodes as you wish. It will work as long as at least one cluster node is available behind loadbalancer (no matter which one). Maybe we can relax a bit on validation and validate just realm name instead of the full URL during issuer validation (we already had it like this few months back AFAIR). But not sure if it's really needed as in production, you will likely access your nodes always via loadbalancer . Is it correct? Marek On 6.8.2015 09:44, Marek Posolda wrote: > I've finally reproduced the issue and looking at it. Will update you > once I have fix. > > Marek > > On 5.8.2015 14:14, Nair, Rajat wrote: >> Some more information - >> >> Quick summary - I'm trying to test HA of Keycloak user sessions when >> one of the nodes goes down, users should not have to login again as >> their session information would be available on other node. Keycloak >> cluster is setup to store users session on Infinispan (testing using >> distributed-cache and replicated-cache). >> >> To see the cache information on Keycloak nodes, I setup hawtio on >> these node. Initial state of caches on both the nodes are captured in >> these images (see 110.DC.Start.png and 111.DC.Start.png) >> Then user logs into server 111. We can see the session entry value >> increasing (see 111.DC.Login.On.111.PNG). When we look at session >> entry on 110 server, we see that the count has increased there too. >> That means that they session is being successfully replicated (see >> 110.DC.Login.On.111.PNG). >> >> To verify if this works other way around, we logged into server 110, >> and its session entry count increased (see >> 110.DC.Login.On.110.And.111.PNG). When we check 111, we can see that >> session entry count increased on this server too. (see >> 111.DC.Login.On.110.And.111.png). >> >> We initially suspected that our sessions were not getting replicated. >> Using hawtio, we can see session entry count increasing on both >> servers. Could this mean that there is a bug in Keycloak's code while >> fetching user sessions? Is there any other way we can validate user >> sessions? >> >> -- Rajat >> >> -----Original Message----- >> From: Nair, Rajat >> Sent: 03 August 2015 12:43 >> To: 'Stian Thorgersen'; Marek Posolda >> Cc: keycloak-user at lists.jboss.org >> Subject: RE: [keycloak-user] Distributed Keycloak user sessions using >> Infinispan >> >> Hi, >> >> Some more info from log of test-server-110 server (server names are >> test-server-110 and test-server-111) - Infinispan subsystem >> initialized logs for sessions cache - >> [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- >> 39) WFLYCLINF0001: Activating Infinispan subsystem. >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] >> (ServerService Thread Pool -- 62) ISPN000078: Starting JGroups >> channel keycloak >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] >> (ServerService Thread Pool -- 62) ISPN000094: Received new cluster >> view for channel keycloak: [test-server-111|0] (1) [test-server-111] >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] >> (ServerService Thread Pool -- 62) ISPN000079: Channel keycloak local >> address is test-server-111, physical addresses are [XX.XX.XX.XX:7600] >> [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- >> 63) WFLYCLINF0002: Started sessions cache from keycloak container >> [org.infinispan.CLUSTER] (remote-thread--p3-t3) ISPN000310: Starting >> cluster-wide rebalance for cache sessions, topology >> CacheTopology{id=1, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = >> (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.CLUSTER] (remote-thread--p3-t2) ISPN000336: Finished >> cluster-wide rebalance for cache sessions, topology id = 1 >> >> Session cache details - >> [org.infinispan.jmx.JmxUtil] (ServerService Thread Pool -- 63) Object >> name >> jboss.infinispan:type=Cache,name="sessions(dist_sync)",manager="keycloak",component=Cache >> already registered [org.infinispan.topology.LocalTopologyManagerImpl] >> (ServerService Thread Pool -- 63) Node test-server-110 joining cache >> sessions [org.infinispan.topology.LocalTopologyManagerImpl] >> (ServerService Thread Pool -- 63) Updating local topology for cache >> sessions: CacheTopology{id=0, rebalanceId=0, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=null, unionCH=null, >> actualMembers=[test-server-111]} >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (transport-thread--p2-t5) Updating local topology for cache sessions: >> CacheTopology{id=1, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = >> (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (transport-thread--p2-t5) Starting local rebalance for cache >> sessions, topology = CacheTopology{id=1, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = >> (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.statetransfer.StateConsumerImpl] >> (transport-thread--p2-t5) Adding inbound state transfer for segments >> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, >> 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, >> 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, >> 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, >> 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions >> [org.infinispan.statetransfer.StateConsumerImpl] >> (transport-thread--p2-t5) Removing no longer owned entries for cache >> sessions [org.infinispan.statetransfer.InboundTransferTask] >> (stateTransferExecutor-thread--p5-t19) Finished receiving state for >> segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, >> 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, >> 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, >> 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, >> 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions >> [org.infinispan.statetransfer.StateConsumerImpl] >> (stateTransferExecutor-thread--p5-t24) Finished receiving of segments >> for cache sessions for topology 1. >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (transport-thread--p2-t10) Updating local topology for cache >> sessions: CacheTopology{id=2, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: >> 40+40, test-server-110: 40+40]}, pendingCH=null, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.statetransfer.StateConsumerImpl] >> (transport-thread--p2-t10) Removing no longer owned entries for cache >> sessions [org.infinispan.cache.impl.CacheImpl] (ServerService Thread >> Pool -- 63) Started cache sessions on test-server-110 >> [org.wildfly.clustering.infinispan.spi.service.CacheBuilder] >> (ServerService Thread Pool -- 63) sessions keycloak cache started >> >> >> Looks like the servers are talking to each other (setup on unicast) >> and session cache between the servers are shared, but we still cannot >> successfully fetch user info when token is generated by one server >> (test-server-110) and data from another (test-server-111). >> >> Any suggestions/debugging approaches appreciated. >> >> -- Rajat >> >> -----Original Message----- >> From: Stian Thorgersen [mailto:stian at redhat.com] >> Sent: 29 July 2015 22:51 >> To: Nair, Rajat; Marek Posolda >> Cc: keycloak-user at lists.jboss.org >> Subject: Re: [keycloak-user] Distributed Keycloak user sessions using >> Infinispan >> >> I'm away on holiday, Marek can you take a look at this? >> >> ----- Original Message ----- >>> From: "Rajat Nair" >>> To: "Stian Thorgersen" >>> Cc: keycloak-user at lists.jboss.org >>> Sent: Wednesday, 29 July, 2015 2:56:07 PM >>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions using >>> Infinispan >>> >>> Follow up to our discussion - >>> >>> I upgrade my nodes to Keycloak 1.4 Final. Dropped and re-created >>> database Postgres database (shared between both the nodes) and tested >>> distributed user session using following commands - >>> - Fetch access token using following curl from one server >>> curl --write-out " %{http_code}" -s --request POST --header >>> "Content-Type: >>> application/x-www-form-urlencoded; charset=UTF-8" --data >>> "username=user1 at email.com&password=testpassword@&client_id=admin-client&grant_type=password" >>> >>> "http://test-server-110:8080/auth/realms/test/protocol/openid-connect/token" >>> >>> >>> - Validated the token on different server using >>> curl --write-out " %{http_code}" -s --request GET --header >>> "Content-Type: >>> application/json" --header "Authorization: Bearer >>> [ACCESS_TOKEN_FROM_PREVIOUS_CALL]" >>> "http://test-server-111:8081/auth/realms/test/protocol/openid-connect/userinfo" >>> >>> >>> And we get this - {"error":"invalid_grant","error_description":"Token >>> invalid"} >>> No more NPE and internal server error. >>> >>> If we use the same token and try to fetch user details on server which >>> issued the token - we get the correct data. (Note - I have confirmed >>> that the token has not expired) >>> >>>> One thing you can try is to make sure user session replication is >>>> working >>>> properly: >>>> 1. Start two nodes >>>> 2. Open admin console directly on node 1 - login as admin/admin 3. >>>> Open admin console directly on node 2 from another machine/browser >>>> or use incognito mode - login as admin/admin 4. On node 1 go to >>>> users -> view all >>>> -> click on admin -> sessions - > > you should see two sessions 5. >>>> -> On node >>>> 2 do the same and check you can see two sessions there as well >>> Now this is where things get strange. I followed the steps described - >>> used 2 different browsers - and I can see 2 sessions listed! >>> >>> Are the process we use to validate the token incorrect? Or is master >>> console on the web doing something different (like get the data from >>> Postgres database used by both the nodes). >>> >>> -- Rajat >>> >>> -----Original Message----- >>> From: Stian Thorgersen [mailto:stian at redhat.com] >>> Sent: 28 July 2015 10:19 >>> To: Nair, Rajat >>> Cc: keycloak-user at lists.jboss.org >>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions using >>> Infinispan >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Rajat Nair" >>>> To: "Stian Thorgersen" >>>> Cc: keycloak-user at lists.jboss.org >>>> Sent: Monday, 27 July, 2015 7:33:25 PM >>>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>>> using Infinispan >>>> >>>>> Can you send me your standalone-ha.xml and keycloak-server.json? >>>> Files attached. The service is started like - >>>> /opt/jboss/keycloak/bin/standalone.sh -c standalone-ha.xml >>>> -b=test-server-110 >>>> -bmanagement=test-server-110 -u 230.0.0.4 >>>> -Djboss.node.name=test-server-110 >>>> >>>>> Also, any chance you can try it out with master? I've been testing >>>>> with that as we're about to do 1.4 release soon >>>> Glad to give back to the community. Will build and deploy the master >>>> on my nodes. Will send findings tomorrow. >>>> >>>> Regarding a scenario I described earlier - Case 2 1. Start with 1 >>>> Node down. We bring it back up. We wait for some time so that >>>> Infinispan can sync. >>>> 2. Bring down other node. >>>> 3. Try to get user info using existing token. >>>> >>>> Is this a valid use-case? >>> Yes - I've tried the same use-case and it works fine every time. One >>> caveat is that access token can expire, but in this case you should >>> get a 403 returned, not a NPE exception and 500. >>> >>> One thing you can try is to make sure user session replication is >>> working >>> properly: >>> >>> 1. Start two nodes >>> 2. Open admin console directly on node 1 - login as admin/admin 3. >>> Open admin console directly on node 2 from another machine/browser or >>> use incognito mode - login as admin/admin 4. On node 1 go to users -> >>> view all -> click on admin -> sessions - you should see two sessions >>> 5. On node 2 do the same and check you can see two sessions there as >>> well >>> >>>> -- Rajat >>>> >>>> -----Original Message----- >>>> From: Stian Thorgersen [mailto:stian at redhat.com] >>>> Sent: 27 July 2015 19:16 >>>> To: Nair, Rajat >>>> Cc: keycloak-user at lists.jboss.org >>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>> using Infinispan >>>> >>>> Also, any chance you can try it out with master? I've been testing >>>> with that as we're about to do 1.4 release soon >>>> >>>> ----- Original Message ----- >>>>> From: "Stian Thorgersen" >>>>> To: "Rajat Nair" >>>>> Cc: keycloak-user at lists.jboss.org >>>>> Sent: Monday, 27 July, 2015 3:45:46 PM >>>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>>> using Infinispan >>>>> >>>>> Can you send me your standalone-ha.xml and keycloak-server.json? >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Rajat Nair" >>>>>> To: "Stian Thorgersen" >>>>>> Cc: keycloak-user at lists.jboss.org >>>>>> Sent: Monday, 27 July, 2015 3:41:36 PM >>>>>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>>>>> using Infinispan >>>>>> >>>>>>> Do you have both nodes fully up and running before you kill one >>>>>>> node? >>>>>> Yes. >>>>>> This is what we tried - >>>>>> Case 1 >>>>>> 1. Two node cluster (both running Keycloak engines) - both up >>>>>> and running. >>>>>> Configured load balancing using mod_cluster. >>>>>> 2. Login and get token. >>>>>> 3. Bring down one node. >>>>>> 4. Get user info using existing token. This is when we get NPE. >>>>>> >>>>>> Case 2 >>>>>> 1. Start with 1 Node down. We bring it back up. We wait for some >>>>>> time so that Infinispan can sync. >>>>>> 2. Bring down other node. >>>>>> 3. Try to get user info using existing token. Again we see NPE. >>>>>> >>>>>>> It's a bug - if session is expired it should return an error >>>>>>> message, not a NPE (see >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-1710) >>>>>> Thanks for tracking this. >>>>>> >>>>>> -- Rajat >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Rajat Nair" >>>>>>> To: "Stian Thorgersen" >>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>> Sent: Monday, 27 July, 2015 3:20:27 PM >>>>>>> Subject: RE: [keycloak-user] Distributed Keycloak user >>>>>>> sessions using Infinispan >>>>>>> >>>>>>> Thanks for quick reply Stian. >>>>>>> >>>>>>>> What version? >>>>>>> We are using Keycloak 1.3.1 Final. >>>>>>>> Did you remember to change userSessions provider to >>>>>>>> infinispan in keycloak-server.json? >>>>>>> Yes. We got following in keycloak-server.json - >>>>>>> "userSessions": { >>>>>>> "provider": "infinispan" >>>>>>> } >>>>>>> >>>>>>>> Firstly owners="2" should work fine as long as only one node >>>>>>>> dies and the other remains active. Secondly it should return >>>>>>>> a NPE, but an error if user session is not found. >>>>>>> Could you elaborate on your 2nd point? >>>>>> Do you have both nodes fully up and running before you kill one >>>>>> node? >>>>>> >>>>>> It's a bug - if session is expired it should return an error >>>>>> message, not a NPE (see >>>>>> https://issues.jboss.org/browse/KEYCLOAK-1710) >>>>>> >>>>>>> -- Rajat >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stian Thorgersen [mailto:stian at redhat.com] >>>>>>> Sent: 27 July 2015 18:07 >>>>>>> To: Nair, Rajat >>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>> Subject: Re: [keycloak-user] Distributed Keycloak user >>>>>>> sessions using Infinispan >>>>>>> >>>>>>> Did you remember to change userSessions provider to infinispan >>>>>>> in keycloak-server.json? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Stian Thorgersen" >>>>>>>> To: "Rajat Nair" >>>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>>> Sent: Monday, 27 July, 2015 2:24:17 PM >>>>>>>> Subject: Re: [keycloak-user] Distributed Keycloak user >>>>>>>> sessions using Infinispan >>>>>>>> >>>>>>>> What version? >>>>>>>> >>>>>>>> Firstly owners="2" should work fine as long as only one node >>>>>>>> dies and the other remains active. Secondly it should return >>>>>>>> a NPE, but an error if user session is not found. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Rajat Nair" >>>>>>>>> To: keycloak-user at lists.jboss.org >>>>>>>>> Sent: Monday, 27 July, 2015 2:03:47 PM >>>>>>>>> Subject: [keycloak-user] Distributed Keycloak user >>>>>>>>> sessions using Infinispan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I?m in the process of setting up distributed user sessions >>>>>>>>> using Infinispan on my Keycloak cluster. This is the >>>>>>>>> configuration I use ? >>>>>>>>> >>>>>>>>> >>>>>>>> jndi-name="java:jboss/infinispan/Keycloak"> >>>>>>>>> lock-timeout="60000"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> owners="2"/> >>>>>>>>> >>>>>>>>> >>>>>>>> owners="1"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> And in server.logs, I can see my servers communicate ? >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,662 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t7) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>>> users, topology CacheTopology{id=57, rebalanceId=17, >>>>>>>>> currentCH=ReplicatedConsistentHash{ns >>>>>>>>> = >>>>>>>>> 60, owners = (1)[test-server-110: 60]}, >>>>>>>>> pendingCH=ReplicatedConsistentHash{ns = 60, owners = >>>>>>>>> (2)[test-server-110: >>>>>>>>> 30, test-server-111: 30]}, unionCH=null, >>>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t10) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>>> realms, topology CacheTopology{id=57, rebalanceId=17, >>>>>>>>> currentCH=ReplicatedConsistentHash{ns >>>>>>>>> = >>>>>>>>> 60, owners = (1)[test-server-110: 60]}, >>>>>>>>> pendingCH=ReplicatedConsistentHash{ns = 60, owners = >>>>>>>>> (2)[test-server-110: >>>>>>>>> 30, test-server-111: 30]}, unionCH=null, >>>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t8) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>>> loginFailures, topology CacheTopology{id=57, >>>>>>>>> rebalanceId=17, currentCH=DefaultConsistentHash{ns=80, >>>>>>>>> owners = >>>>>>>>> (1)[test-server-110: >>>>>>>>> 80+0]}, >>>>>>>>> pendingCH=DefaultConsistentHash{ns=80, owners = >>>>>>>>> (2)[test-server-110: >>>>>>>>> 40+0, >>>>>>>>> test-server-111: 40+0]}, unionCH=null, >>>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,669 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t9) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>>> sessions, topology CacheTopology{id=56, rebalanceId=17, >>>>>>>>> currentCH=DefaultConsistentHash{ns=80, >>>>>>>>> owners = (1)[test-server-110: 80+0]}, >>>>>>>>> pendingCH=DefaultConsistentHash{ns=80, >>>>>>>>> owners = (2)[test-server-110: 40+0, test-server-111: >>>>>>>>> 40+0]}, unionCH=null, actualMembers=[test-server-110, >>>>>>>>> test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,808 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t9) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>>> loginFailures, topology id = 57 >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,810 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t12) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>>> sessions, topology id = 56 >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,988 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t12) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>>> realms, topology id = >>>>>>>>> 57 >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:25,530 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t8) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>>> users, topology id = >>>>>>>>> 57 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I can successfully login, get a token and fetch user >>>>>>>>> details with this token. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem is, if one of the nodes on the cluster goes down >>>>>>>>> and if we try to reuse a token which was already issued >>>>>>>>> (so workflow is ? user logins in, get token, (a node in >>>>>>>>> the cluster goes down) and then fetch user details using >>>>>>>>> token) ? we see an internal server exception. From the >>>>>>>>> logs ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-07-27 10:24:25,714 ERROR [io.undertow.request] >>>>>>>>> (default >>>>>>>>> task-1) >>>>>>>>> UT005023: Exception handling request to >>>>>>>>> /auth/realms/scaletest/protocol/openid-connect/userinfo: >>>>>>>>> java.lang.RuntimeException: request path: >>>>>>>>> /auth/realms/scaletest/protocol/openid-connect/userinfo >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> KeycloakSessionServletFilter.java:54) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. >>>>>>>>> java >>>>>>>>> :6 >>>>>>>>> 0) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> FilterHandler.java:132) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(F >>>>>>>>> il >>>>>>>>> te >>>>>>>>> rHan >>>>>>>>> dl >>>>>>>>> er.java:85) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er.h >>>>>>>>> an >>>>>>>>> dleRequest(ServletSecurityRoleHandler.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.han >>>>>>>>> dl >>>>>>>>> eR >>>>>>>>> eque >>>>>>>>> st >>>>>>>>> (ServletDispatchingHandler.java:36) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAss >>>>>>>>> oc >>>>>>>>> ia >>>>>>>>> tion >>>>>>>>> Ha >>>>>>>>> ndler.handleRequest(SecurityContextAssociationHandler.java >>>>>>>>> :7 >>>>>>>>> 8) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssoci >>>>>>>>> at >>>>>>>>> io >>>>>>>>> nHan >>>>>>>>> dl >>>>>>>>> er.handleRequest(SSLInformationAssociationHandler.java:131 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticatio >>>>>>>>> nC >>>>>>>>> al >>>>>>>>> lHan >>>>>>>>> dl >>>>>>>>> er.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandl >>>>>>>>> er >>>>>>>>> .h >>>>>>>>> andl >>>>>>>>> eR >>>>>>>>> equest(AbstractConfidentialityHandler.java:46) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.ServletConfidentiali >>>>>>>>> ty >>>>>>>>> Co >>>>>>>>> nstr >>>>>>>>> ai >>>>>>>>> ntHandler.handleRequest(ServletConfidentialityConstraintHa >>>>>>>>> nd >>>>>>>>> le >>>>>>>>> r.ja >>>>>>>>> va >>>>>>>>> :64) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler. >>>>>>>>> hand >>>>>>>>> le >>>>>>>>> Request(AuthenticationMechanismsHandler.java:58) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedS >>>>>>>>> es >>>>>>>>> si >>>>>>>>> onHa >>>>>>>>> nd >>>>>>>>> ler.handleRequest(CachedAuthenticatedSessionHandler.java:7 >>>>>>>>> 2) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.NotificationReceiverHandler. >>>>>>>>> ha >>>>>>>>> nd >>>>>>>>> leRe >>>>>>>>> qu >>>>>>>>> est(NotificationReceiverHandler.java:50) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uest >>>>>>>>> (S >>>>>>>>> ecurityInitialHandler.java:76) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler. >>>>>>>>> >>>>>>>>> ha >>>>>>>>> ndleRequest(JACCContextIdHandler.java:61) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.MetricsHandler.handleRequest(M >>>>>>>>> et >>>>>>>>> ri >>>>>>>>> csHa >>>>>>>>> nd >>>>>>>>> ler.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.core.MetricsChainHandler.handleRequest >>>>>>>>> (M >>>>>>>>> et >>>>>>>>> rics >>>>>>>>> Ch >>>>>>>>> ainHandler.java:59) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleF >>>>>>>>> ir >>>>>>>>> st >>>>>>>>> Requ >>>>>>>>> es >>>>>>>>> t(ServletInitialHandler.java:274) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatc >>>>>>>>> hR >>>>>>>>> eq >>>>>>>>> uest >>>>>>>>> (S >>>>>>>>> ervletInitialHandler.java:253) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$ >>>>>>>>> 00 >>>>>>>>> 0( >>>>>>>>> Serv >>>>>>>>> le >>>>>>>>> tInitialHandler.java:80) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uest >>>>>>>>> (S >>>>>>>>> ervletInitialHandler.java:172) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors. >>>>>>>>> ja >>>>>>>>> va:1 >>>>>>>>> 99 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java: >>>>>>>>> >>>>>>>>> 774) >>>>>>>>> >>>>>>>>> at >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at >>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at java.lang.Thread.run(Unknown Source) >>>>>>>>> >>>>>>>>> Caused by: org.jboss.resteasy.spi.UnhandledException: >>>>>>>>> java.lang.NullPointerException >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ExceptionHandler.handleApplication >>>>>>>>> Ex >>>>>>>>> ce >>>>>>>>> ptio >>>>>>>>> n( >>>>>>>>> ExceptionHandler.java:76) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ExceptionHandler.handleException(E >>>>>>>>> xc >>>>>>>>> ep >>>>>>>>> tion >>>>>>>>> Ha >>>>>>>>> ndler.java:212) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.writeExcepti >>>>>>>>> on >>>>>>>>> (S >>>>>>>>> ynch >>>>>>>>> ro >>>>>>>>> nousDispatcher.java:149) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>>> ro >>>>>>>>> no >>>>>>>>> usDi >>>>>>>>> sp >>>>>>>>> atcher.java:372) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>>> ro >>>>>>>>> no >>>>>>>>> usDi >>>>>>>>> sp >>>>>>>>> atcher.java:179) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainer >>>>>>>>> Di >>>>>>>>> sp >>>>>>>>> atch >>>>>>>>> er >>>>>>>>> .service(ServletContainerDispatcher.java:220) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispa >>>>>>>>> tc >>>>>>>>> he >>>>>>>>> r.se >>>>>>>>> rv >>>>>>>>> ice(HttpServletDispatcher.java:56) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispa >>>>>>>>> tc >>>>>>>>> he >>>>>>>>> r.se >>>>>>>>> rv >>>>>>>>> ice(HttpServletDispatcher.java:51) >>>>>>>>> >>>>>>>>> at >>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:79 >>>>>>>>> 0) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> letH >>>>>>>>> an >>>>>>>>> dler.java:86) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> FilterHandler.java:130) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.services.filters.ClientConnectionFilter.doFil >>>>>>>>> te >>>>>>>>> r( >>>>>>>>> Clie >>>>>>>>> nt >>>>>>>>> ConnectionFilter.java:41) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. >>>>>>>>> java >>>>>>>>> :6 >>>>>>>>> 0) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> FilterHandler.java:132) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> KeycloakSessionServletFilter.java:40) >>>>>>>>> >>>>>>>>> ... 31 more >>>>>>>>> >>>>>>>>> Caused by: java.lang.NullPointerException >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu >>>>>>>>> eU >>>>>>>>> se >>>>>>>>> rInf >>>>>>>>> o( >>>>>>>>> UserInfoEndpoint.java:128) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu >>>>>>>>> eU >>>>>>>>> se >>>>>>>>> rInf >>>>>>>>> oG >>>>>>>>> et(UserInfoEndpoint.java:101) >>>>>>>>> >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>> Method) >>>>>>>>> >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodIn >>>>>>>>> je >>>>>>>>> ct >>>>>>>>> orIm >>>>>>>>> pl >>>>>>>>> .java:137) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarg >>>>>>>>> et >>>>>>>>> (R >>>>>>>>> esou >>>>>>>>> rc >>>>>>>>> eMethodInvoker.java:296) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resou >>>>>>>>> rc >>>>>>>>> eM >>>>>>>>> etho >>>>>>>>> dI >>>>>>>>> nvoker.java:250) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar >>>>>>>>> ge >>>>>>>>> tO >>>>>>>>> bjec >>>>>>>>> t( >>>>>>>>> ResourceLocatorInvoker.java:140) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso >>>>>>>>> ur >>>>>>>>> ce >>>>>>>>> Loca >>>>>>>>> to >>>>>>>>> rInvoker.java:109) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar >>>>>>>>> ge >>>>>>>>> tO >>>>>>>>> bjec >>>>>>>>> t( >>>>>>>>> ResourceLocatorInvoker.java:135) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso >>>>>>>>> ur >>>>>>>>> ce >>>>>>>>> Loca >>>>>>>>> to >>>>>>>>> rInvoker.java:103) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>>> ro >>>>>>>>> no >>>>>>>>> usDi >>>>>>>>> sp >>>>>>>>> atcher.java:356) >>>>>>>>> >>>>>>>>> ... 42 more >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The user guide says ? >>>>>>>>> >>>>>>>>> If you need to prevent node failures from requiring users >>>>>>>>> to log in again, set the owners attribute to 2 or more for >>>>>>>>> the sessions cache >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Questions - >>>>>>>>> >>>>>>>>> 1. Have we configured Infinispan incorrectly? We don?t >>>>>>>>> want the users to login again if any of the nodes in the >>>>>>>>> cluster go down. >>>>>>>>> >>>>>>>>> 2. Will changing distributed-cache to replicated-cache >>>>>>>>> help in this scenario? >>>>>>>>> >>>>>>>>> 3. Any way we can see the contents of the cache? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Rajat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 Fri Aug 7 04:18:11 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 07 Aug 2015 10:18:11 +0200 Subject: [keycloak-user] Upgrade Keycloak 1.3.1 to 1.4.0 In-Reply-To: References: <55C30A98.4080309@redhat.com> Message-ID: <55C469C3.4090903@redhat.com> I don't think it's good option. The version of various modules changed etc and especially 1.4.0 is supposed to run on latest Wildfly 9.0.1 when 1.3.1 used older version. It's better to start with 1.4.0 server distribution and just migrate your database. Or if you want to use the same Wildfly server for Keycloak and your apps, then use keycloak server-overlay distribution and apply it to Wildfly 9.0.1 server and then deploy your applications on this server. Marek On 6.8.2015 13:08, Carlos German Tejero wrote: > Thanks Marek! > But, can i upgrade the keycloak 1.3.1 subsystem to 1.4.0 in the same > wildfly installation? > > 2015-08-06 4:19 GMT-03:00 Marek Posolda >: > > Hi, > > you can just download 1.4.0 distribution and configure it with > same DB, which you previously used for 1.3.1. If you use default > H2 db, you may just need copy files from your previous 1.3.1 > distribution from standalone/data directory to 1.4.0. Ideally, you > can backup your DB before upgrade, so you won't lose the data if > upgrade fails. But ideally upgrade DB should work fine unless > there is bug... > > More info: > http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html > > Marek > > > On 5.8.2015 19:46, Carlos German Tejero wrote: >> I have installed Keycloak 1.3.1 as a subsystem, on a Wildfly 9.0.1. >> >> How is the procedure for upgrade it to 1.4.0? >> >> Tanks to all! >> >> >> -- >> Carlos Germ?n Tejero >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > -- > Carlos Germ?n Tejero > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150807/0c522643/attachment.html From german.tejero at gmail.com Fri Aug 7 07:05:08 2015 From: german.tejero at gmail.com (Carlos German Tejero) Date: Fri, 7 Aug 2015 08:05:08 -0300 Subject: [keycloak-user] Upgrade Keycloak 1.3.1 to 1.4.0 In-Reply-To: <55C469C3.4090903@redhat.com> References: <55C30A98.4080309@redhat.com> <55C469C3.4090903@redhat.com> Message-ID: Thanks Marek!! 2015-08-07 5:18 GMT-03:00 Marek Posolda : > I don't think it's good option. The version of various modules changed etc > and especially 1.4.0 is supposed to run on latest Wildfly 9.0.1 when 1.3.1 > used older version. > > It's better to start with 1.4.0 server distribution and just migrate your > database. Or if you want to use the same Wildfly server for Keycloak and > your apps, then use keycloak server-overlay distribution and apply it to > Wildfly 9.0.1 server and then deploy your applications on this server. > > Marek > > > On 6.8.2015 13:08, Carlos German Tejero wrote: > > Thanks Marek! > But, can i upgrade the keycloak 1.3.1 subsystem to 1.4.0 in the same > wildfly installation? > > 2015-08-06 4:19 GMT-03:00 Marek Posolda : > >> Hi, >> >> you can just download 1.4.0 distribution and configure it with same DB, >> which you previously used for 1.3.1. If you use default H2 db, you may just >> need copy files from your previous 1.3.1 distribution from standalone/data >> directory to 1.4.0. Ideally, you can backup your DB before upgrade, so you >> won't lose the data if upgrade fails. But ideally upgrade DB should work >> fine unless there is bug... >> >> More info: >> http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html >> >> Marek >> >> >> On 5.8.2015 19:46, Carlos German Tejero wrote: >> >> I have installed Keycloak 1.3.1 as a subsystem, on a Wildfly 9.0.1. >> >> How is the procedure for upgrade it to 1.4.0? >> >> Tanks to all! >> >> >> -- >> Carlos Germ?n Tejero >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> > > > -- > Carlos Germ?n Tejero > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- Carlos Germ?n Tejero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150807/8366480d/attachment.html From srossillo at smartling.com Fri Aug 7 10:03:20 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 7 Aug 2015 10:03:20 -0400 Subject: [keycloak-user] User attributes as custom claims? Message-ID: <4289D25C-FCE7-4ABD-8D77-13B0C8ABE784@smartling.com> Hi, Is there a way to get user attributes returned from Keycloak by requesting it as a claim or some other method? The only way I can get user attributes right now is via an admin api call for a user resource. Am I missing something? Thanks, Scott From bburke at redhat.com Fri Aug 7 10:36:32 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 7 Aug 2015 10:36:32 -0400 Subject: [keycloak-user] User attributes as custom claims? In-Reply-To: <4289D25C-FCE7-4ABD-8D77-13B0C8ABE784@smartling.com> References: <4289D25C-FCE7-4ABD-8D77-13B0C8ABE784@smartling.com> Message-ID: <55C4C270.2090708@redhat.com> Define a mapper to map the user attribute to a claim. Look in the Client "mapper" tab. On 8/7/2015 10:03 AM, Scott Rossillo wrote: > Hi, > > Is there a way to get user attributes returned from Keycloak by requesting it as a claim or some other method? The only way I can get user attributes right now is via an admin api call for a user resource. Am I missing something? > > Thanks, > Scott > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From rajat.nair at hp.com Fri Aug 7 11:49:33 2015 From: rajat.nair at hp.com (Nair, Rajat) Date: Fri, 7 Aug 2015 15:49:33 +0000 Subject: [keycloak-user] Distributed Keycloak user sessions using Infinispan In-Reply-To: <55C385DB.6090705@redhat.com> References: <59651412.706872.1438003614393.JavaMail.zimbra@redhat.com> <1045151906.720245.1438004746473.JavaMail.zimbra@redhat.com> <1732913135.720424.1438004774275.JavaMail.zimbra@redhat.com> <1042060711.1068309.1438058940079.JavaMail.zimbra@redhat.com> <966246176.551354.1438190443054.JavaMail.zimbra@redhat.com> <55C31057.90801@redhat.com> <55C385DB.6090705@redhat.com> Message-ID: Hi Marek, Thanks for the clarification. Yes, we will always be using Keycloak behind a load balancer. I've updated all my nodes with master and everything seems to be working as expected. I need to try out few more fail-over scenarios and will get back with my findings. -- Rajat -----Original Message----- From: Marek Posolda [mailto:mposolda at redhat.com] Sent: 06 August 2015 21:36 To: Nair, Rajat; Stian Thorgersen Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Distributed Keycloak user sessions using Infinispan It's clear that your infinispan cluster works as expected. I think the issue is, that you are sending curl requests directly to individual cluster nodes instead of loadbalancer. At least I saw it as an issue during my testing and I suspect that in your case it will be the same. Like in your example you first retrieved the token by curl request to http://test-server-110:8080 and then used this token to retrieve UserInfo by accessing on http://test-server-111:8081 . In this case, it doesn't work as issuer (iss field) in access token starts with URL "http://test-server-110:8080" , which means that this access token will be rejected on "http://test-server-111:8081" when sending request to UserInfo endpoint here. I've added a bit more info about error into UserInfo endpoint, so in latest master you can see additional details (I suspect that you will really see the error message about invalid issuer URL). So the solution is, that you will need to send requests to loadbalancer instead of individual cluster nodes. Like if your curl request to retrieve access token will be send to "http://loadbalancer:8080" and the UserInfo will be also accessed through loadbalancer, it will work because the issuer in access token will be "http://loadbalancer:8080" . You can try this and then add or remove cluster nodes as you wish. It will work as long as at least one cluster node is available behind loadbalancer (no matter which one). Maybe we can relax a bit on validation and validate just realm name instead of the full URL during issuer validation (we already had it like this few months back AFAIR). But not sure if it's really needed as in production, you will likely access your nodes always via loadbalancer . Is it correct? Marek On 6.8.2015 09:44, Marek Posolda wrote: > I've finally reproduced the issue and looking at it. Will update you > once I have fix. > > Marek > > On 5.8.2015 14:14, Nair, Rajat wrote: >> Some more information - >> >> Quick summary - I'm trying to test HA of Keycloak user sessions when >> one of the nodes goes down, users should not have to login again as >> their session information would be available on other node. Keycloak >> cluster is setup to store users session on Infinispan (testing using >> distributed-cache and replicated-cache). >> >> To see the cache information on Keycloak nodes, I setup hawtio on >> these node. Initial state of caches on both the nodes are captured in >> these images (see 110.DC.Start.png and 111.DC.Start.png) Then user >> logs into server 111. We can see the session entry value increasing >> (see 111.DC.Login.On.111.PNG). When we look at session entry on 110 >> server, we see that the count has increased there too. >> That means that they session is being successfully replicated (see >> 110.DC.Login.On.111.PNG). >> >> To verify if this works other way around, we logged into server 110, >> and its session entry count increased (see >> 110.DC.Login.On.110.And.111.PNG). When we check 111, we can see that >> session entry count increased on this server too. (see >> 111.DC.Login.On.110.And.111.png). >> >> We initially suspected that our sessions were not getting replicated. >> Using hawtio, we can see session entry count increasing on both >> servers. Could this mean that there is a bug in Keycloak's code while >> fetching user sessions? Is there any other way we can validate user >> sessions? >> >> -- Rajat >> >> -----Original Message----- >> From: Nair, Rajat >> Sent: 03 August 2015 12:43 >> To: 'Stian Thorgersen'; Marek Posolda >> Cc: keycloak-user at lists.jboss.org >> Subject: RE: [keycloak-user] Distributed Keycloak user sessions using >> Infinispan >> >> Hi, >> >> Some more info from log of test-server-110 server (server names are >> test-server-110 and test-server-111) - Infinispan subsystem >> initialized logs for sessions cache - >> [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- >> 39) WFLYCLINF0001: Activating Infinispan subsystem. >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] >> (ServerService Thread Pool -- 62) ISPN000078: Starting JGroups >> channel keycloak >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] >> (ServerService Thread Pool -- 62) ISPN000094: Received new cluster >> view for channel keycloak: [test-server-111|0] (1) [test-server-111] >> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] >> (ServerService Thread Pool -- 62) ISPN000079: Channel keycloak local >> address is test-server-111, physical addresses are [XX.XX.XX.XX:7600] >> [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- >> 63) WFLYCLINF0002: Started sessions cache from keycloak container >> [org.infinispan.CLUSTER] (remote-thread--p3-t3) ISPN000310: Starting >> cluster-wide rebalance for cache sessions, topology >> CacheTopology{id=1, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = >> (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.CLUSTER] (remote-thread--p3-t2) ISPN000336: Finished >> cluster-wide rebalance for cache sessions, topology id = 1 >> >> Session cache details - >> [org.infinispan.jmx.JmxUtil] (ServerService Thread Pool -- 63) Object >> name >> jboss.infinispan:type=Cache,name="sessions(dist_sync)",manager="keycl >> oak",component=Cache already registered >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (ServerService Thread Pool -- 63) Node test-server-110 joining cache >> sessions [org.infinispan.topology.LocalTopologyManagerImpl] >> (ServerService Thread Pool -- 63) Updating local topology for cache >> sessions: CacheTopology{id=0, rebalanceId=0, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=null, unionCH=null, >> actualMembers=[test-server-111]} >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (transport-thread--p2-t5) Updating local topology for cache sessions: >> CacheTopology{id=1, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = >> (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (transport-thread--p2-t5) Starting local rebalance for cache >> sessions, topology = CacheTopology{id=1, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (1)[test-server-111: >> 80+0]}, pendingCH=DefaultConsistentHash{ns=80, owners = >> (2)[test-server-111: 40+40, test-server-110: 40+40]}, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.statetransfer.StateConsumerImpl] >> (transport-thread--p2-t5) Adding inbound state transfer for segments >> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, >> 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, >> 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, >> 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, 64, 65, >> 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions >> [org.infinispan.statetransfer.StateConsumerImpl] >> (transport-thread--p2-t5) Removing no longer owned entries for cache >> sessions [org.infinispan.statetransfer.InboundTransferTask] >> (stateTransferExecutor-thread--p5-t19) Finished receiving state for >> segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, >> 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, >> 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, >> 48, 55, 54, 53, 52, 59, 58, 57, 56, 63, 62, 61, 60, 68, 69, 70, 71, >> 64, 65, 66, 67, 76, 77, 78, 79, 72, 73, 74, 75] of cache sessions >> [org.infinispan.statetransfer.StateConsumerImpl] >> (stateTransferExecutor-thread--p5-t24) Finished receiving of segments >> for cache sessions for topology 1. >> [org.infinispan.topology.LocalTopologyManagerImpl] >> (transport-thread--p2-t10) Updating local topology for cache >> sessions: CacheTopology{id=2, rebalanceId=1, >> currentCH=DefaultConsistentHash{ns=80, owners = (2)[test-server-111: >> 40+40, test-server-110: 40+40]}, pendingCH=null, unionCH=null, >> actualMembers=[test-server-111, test-server-110]} >> [org.infinispan.statetransfer.StateConsumerImpl] >> (transport-thread--p2-t10) Removing no longer owned entries for cache >> sessions [org.infinispan.cache.impl.CacheImpl] (ServerService Thread >> Pool -- 63) Started cache sessions on test-server-110 >> [org.wildfly.clustering.infinispan.spi.service.CacheBuilder] >> (ServerService Thread Pool -- 63) sessions keycloak cache started >> >> >> Looks like the servers are talking to each other (setup on unicast) >> and session cache between the servers are shared, but we still cannot >> successfully fetch user info when token is generated by one server >> (test-server-110) and data from another (test-server-111). >> >> Any suggestions/debugging approaches appreciated. >> >> -- Rajat >> >> -----Original Message----- >> From: Stian Thorgersen [mailto:stian at redhat.com] >> Sent: 29 July 2015 22:51 >> To: Nair, Rajat; Marek Posolda >> Cc: keycloak-user at lists.jboss.org >> Subject: Re: [keycloak-user] Distributed Keycloak user sessions using >> Infinispan >> >> I'm away on holiday, Marek can you take a look at this? >> >> ----- Original Message ----- >>> From: "Rajat Nair" >>> To: "Stian Thorgersen" >>> Cc: keycloak-user at lists.jboss.org >>> Sent: Wednesday, 29 July, 2015 2:56:07 PM >>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>> using Infinispan >>> >>> Follow up to our discussion - >>> >>> I upgrade my nodes to Keycloak 1.4 Final. Dropped and re-created >>> database Postgres database (shared between both the nodes) and >>> tested distributed user session using following commands - >>> - Fetch access token using following curl from one server >>> curl --write-out " %{http_code}" -s --request POST --header >>> "Content-Type: >>> application/x-www-form-urlencoded; charset=UTF-8" --data >>> "username=user1 at email.com&password=testpassword@&client_id=admin-client&grant_type=password" >>> >>> "http://test-server-110:8080/auth/realms/test/protocol/openid-connect/token" >>> >>> >>> - Validated the token on different server using >>> curl --write-out " %{http_code}" -s --request GET --header >>> "Content-Type: >>> application/json" --header "Authorization: Bearer >>> [ACCESS_TOKEN_FROM_PREVIOUS_CALL]" >>> "http://test-server-111:8081/auth/realms/test/protocol/openid-connect/userinfo" >>> >>> >>> And we get this - >>> {"error":"invalid_grant","error_description":"Token >>> invalid"} >>> No more NPE and internal server error. >>> >>> If we use the same token and try to fetch user details on server >>> which issued the token - we get the correct data. (Note - I have >>> confirmed that the token has not expired) >>> >>>> One thing you can try is to make sure user session replication is >>>> working >>>> properly: >>>> 1. Start two nodes >>>> 2. Open admin console directly on node 1 - login as admin/admin 3. >>>> Open admin console directly on node 2 from another machine/browser >>>> or use incognito mode - login as admin/admin 4. On node 1 go to >>>> users -> view all >>>> -> click on admin -> sessions - > > you should see two sessions 5. >>>> -> On node >>>> 2 do the same and check you can see two sessions there as well >>> Now this is where things get strange. I followed the steps described >>> - used 2 different browsers - and I can see 2 sessions listed! >>> >>> Are the process we use to validate the token incorrect? Or is master >>> console on the web doing something different (like get the data from >>> Postgres database used by both the nodes). >>> >>> -- Rajat >>> >>> -----Original Message----- >>> From: Stian Thorgersen [mailto:stian at redhat.com] >>> Sent: 28 July 2015 10:19 >>> To: Nair, Rajat >>> Cc: keycloak-user at lists.jboss.org >>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>> using Infinispan >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Rajat Nair" >>>> To: "Stian Thorgersen" >>>> Cc: keycloak-user at lists.jboss.org >>>> Sent: Monday, 27 July, 2015 7:33:25 PM >>>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>>> using Infinispan >>>> >>>>> Can you send me your standalone-ha.xml and keycloak-server.json? >>>> Files attached. The service is started like - >>>> /opt/jboss/keycloak/bin/standalone.sh -c standalone-ha.xml >>>> -b=test-server-110 >>>> -bmanagement=test-server-110 -u 230.0.0.4 >>>> -Djboss.node.name=test-server-110 >>>> >>>>> Also, any chance you can try it out with master? I've been testing >>>>> with that as we're about to do 1.4 release soon >>>> Glad to give back to the community. Will build and deploy the >>>> master on my nodes. Will send findings tomorrow. >>>> >>>> Regarding a scenario I described earlier - Case 2 1. Start with 1 >>>> Node down. We bring it back up. We wait for some time so that >>>> Infinispan can sync. >>>> 2. Bring down other node. >>>> 3. Try to get user info using existing token. >>>> >>>> Is this a valid use-case? >>> Yes - I've tried the same use-case and it works fine every time. One >>> caveat is that access token can expire, but in this case you should >>> get a 403 returned, not a NPE exception and 500. >>> >>> One thing you can try is to make sure user session replication is >>> working >>> properly: >>> >>> 1. Start two nodes >>> 2. Open admin console directly on node 1 - login as admin/admin 3. >>> Open admin console directly on node 2 from another machine/browser >>> or use incognito mode - login as admin/admin 4. On node 1 go to >>> users -> view all -> click on admin -> sessions - you should see two >>> sessions 5. On node 2 do the same and check you can see two sessions >>> there as well >>> >>>> -- Rajat >>>> >>>> -----Original Message----- >>>> From: Stian Thorgersen [mailto:stian at redhat.com] >>>> Sent: 27 July 2015 19:16 >>>> To: Nair, Rajat >>>> Cc: keycloak-user at lists.jboss.org >>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>> using Infinispan >>>> >>>> Also, any chance you can try it out with master? I've been testing >>>> with that as we're about to do 1.4 release soon >>>> >>>> ----- Original Message ----- >>>>> From: "Stian Thorgersen" >>>>> To: "Rajat Nair" >>>>> Cc: keycloak-user at lists.jboss.org >>>>> Sent: Monday, 27 July, 2015 3:45:46 PM >>>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>>> using Infinispan >>>>> >>>>> Can you send me your standalone-ha.xml and keycloak-server.json? >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Rajat Nair" >>>>>> To: "Stian Thorgersen" >>>>>> Cc: keycloak-user at lists.jboss.org >>>>>> Sent: Monday, 27 July, 2015 3:41:36 PM >>>>>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>>>>> using Infinispan >>>>>> >>>>>>> Do you have both nodes fully up and running before you kill one >>>>>>> node? >>>>>> Yes. >>>>>> This is what we tried - >>>>>> Case 1 >>>>>> 1. Two node cluster (both running Keycloak engines) - both up and >>>>>> running. >>>>>> Configured load balancing using mod_cluster. >>>>>> 2. Login and get token. >>>>>> 3. Bring down one node. >>>>>> 4. Get user info using existing token. This is when we get NPE. >>>>>> >>>>>> Case 2 >>>>>> 1. Start with 1 Node down. We bring it back up. We wait for some >>>>>> time so that Infinispan can sync. >>>>>> 2. Bring down other node. >>>>>> 3. Try to get user info using existing token. Again we see NPE. >>>>>> >>>>>>> It's a bug - if session is expired it should return an error >>>>>>> message, not a NPE (see >>>>>>> https://issues.jboss.org/browse/KEYCLOAK-1710) >>>>>> Thanks for tracking this. >>>>>> >>>>>> -- Rajat >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Rajat Nair" >>>>>>> To: "Stian Thorgersen" >>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>> Sent: Monday, 27 July, 2015 3:20:27 PM >>>>>>> Subject: RE: [keycloak-user] Distributed Keycloak user sessions >>>>>>> using Infinispan >>>>>>> >>>>>>> Thanks for quick reply Stian. >>>>>>> >>>>>>>> What version? >>>>>>> We are using Keycloak 1.3.1 Final. >>>>>>>> Did you remember to change userSessions provider to infinispan >>>>>>>> in keycloak-server.json? >>>>>>> Yes. We got following in keycloak-server.json - >>>>>>> "userSessions": { >>>>>>> "provider": "infinispan" >>>>>>> } >>>>>>> >>>>>>>> Firstly owners="2" should work fine as long as only one node >>>>>>>> dies and the other remains active. Secondly it should return a >>>>>>>> NPE, but an error if user session is not found. >>>>>>> Could you elaborate on your 2nd point? >>>>>> Do you have both nodes fully up and running before you kill one >>>>>> node? >>>>>> >>>>>> It's a bug - if session is expired it should return an error >>>>>> message, not a NPE (see >>>>>> https://issues.jboss.org/browse/KEYCLOAK-1710) >>>>>> >>>>>>> -- Rajat >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stian Thorgersen [mailto:stian at redhat.com] >>>>>>> Sent: 27 July 2015 18:07 >>>>>>> To: Nair, Rajat >>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>>>>> using Infinispan >>>>>>> >>>>>>> Did you remember to change userSessions provider to infinispan >>>>>>> in keycloak-server.json? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Stian Thorgersen" >>>>>>>> To: "Rajat Nair" >>>>>>>> Cc: keycloak-user at lists.jboss.org >>>>>>>> Sent: Monday, 27 July, 2015 2:24:17 PM >>>>>>>> Subject: Re: [keycloak-user] Distributed Keycloak user sessions >>>>>>>> using Infinispan >>>>>>>> >>>>>>>> What version? >>>>>>>> >>>>>>>> Firstly owners="2" should work fine as long as only one node >>>>>>>> dies and the other remains active. Secondly it should return a >>>>>>>> NPE, but an error if user session is not found. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Rajat Nair" >>>>>>>>> To: keycloak-user at lists.jboss.org >>>>>>>>> Sent: Monday, 27 July, 2015 2:03:47 PM >>>>>>>>> Subject: [keycloak-user] Distributed Keycloak user sessions >>>>>>>>> using Infinispan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I?m in the process of setting up distributed user sessions >>>>>>>>> using Infinispan on my Keycloak cluster. This is the >>>>>>>>> configuration I use ? >>>>>>>>> >>>>>>>>> >>>>>>>> jndi-name="java:jboss/infinispan/Keycloak"> >>>>>>>>> lock-timeout="60000"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> owners="2"/> >>>>>>>>> >>>>>>>>> >>>>>>>> owners="1"/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> And in server.logs, I can see my servers communicate ? >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,662 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t7) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache users, >>>>>>>>> topology CacheTopology{id=57, rebalanceId=17, >>>>>>>>> currentCH=ReplicatedConsistentHash{ns >>>>>>>>> = >>>>>>>>> 60, owners = (1)[test-server-110: 60]}, >>>>>>>>> pendingCH=ReplicatedConsistentHash{ns = 60, owners = >>>>>>>>> (2)[test-server-110: >>>>>>>>> 30, test-server-111: 30]}, unionCH=null, >>>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t10) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache realms, >>>>>>>>> topology CacheTopology{id=57, rebalanceId=17, >>>>>>>>> currentCH=ReplicatedConsistentHash{ns >>>>>>>>> = >>>>>>>>> 60, owners = (1)[test-server-110: 60]}, >>>>>>>>> pendingCH=ReplicatedConsistentHash{ns = 60, owners = >>>>>>>>> (2)[test-server-110: >>>>>>>>> 30, test-server-111: 30]}, unionCH=null, >>>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t8) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>>> loginFailures, topology CacheTopology{id=57, rebalanceId=17, >>>>>>>>> currentCH=DefaultConsistentHash{ns=80, >>>>>>>>> owners = >>>>>>>>> (1)[test-server-110: >>>>>>>>> 80+0]}, >>>>>>>>> pendingCH=DefaultConsistentHash{ns=80, owners = >>>>>>>>> (2)[test-server-110: >>>>>>>>> 40+0, >>>>>>>>> test-server-111: 40+0]}, unionCH=null, >>>>>>>>> actualMembers=[test-server-110, test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,669 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t9) >>>>>>>>> ISPN000310: Starting cluster-wide rebalance for cache >>>>>>>>> sessions, topology CacheTopology{id=56, rebalanceId=17, >>>>>>>>> currentCH=DefaultConsistentHash{ns=80, >>>>>>>>> owners = (1)[test-server-110: 80+0]}, >>>>>>>>> pendingCH=DefaultConsistentHash{ns=80, >>>>>>>>> owners = (2)[test-server-110: 40+0, test-server-111: >>>>>>>>> 40+0]}, unionCH=null, actualMembers=[test-server-110, >>>>>>>>> test-server-111]} >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,808 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t9) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>>> loginFailures, topology id = 57 >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,810 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t12) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache >>>>>>>>> sessions, topology id = 56 >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:24,988 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t12) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache realms, >>>>>>>>> topology id = >>>>>>>>> 57 >>>>>>>>> >>>>>>>>> 2015-07-27 10:27:25,530 INFO [org.infinispan.CLUSTER] >>>>>>>>> (remote-thread--p3-t8) >>>>>>>>> ISPN000336: Finished cluster-wide rebalance for cache users, >>>>>>>>> topology id = >>>>>>>>> 57 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I can successfully login, get a token and fetch user details >>>>>>>>> with this token. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem is, if one of the nodes on the cluster goes down and >>>>>>>>> if we try to reuse a token which was already issued (so >>>>>>>>> workflow is ? user logins in, get token, (a node in the >>>>>>>>> cluster goes down) and then fetch user details using >>>>>>>>> token) ? we see an internal server exception. From the logs ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-07-27 10:24:25,714 ERROR [io.undertow.request] (default >>>>>>>>> task-1) >>>>>>>>> UT005023: Exception handling request to >>>>>>>>> /auth/realms/scaletest/protocol/openid-connect/userinfo: >>>>>>>>> java.lang.RuntimeException: request path: >>>>>>>>> /auth/realms/scaletest/protocol/openid-connect/userinfo >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> KeycloakSessionServletFilter.java:54) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. >>>>>>>>> java >>>>>>>>> :6 >>>>>>>>> 0) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> FilterHandler.java:132) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(F >>>>>>>>> il >>>>>>>>> te >>>>>>>>> rHan >>>>>>>>> dl >>>>>>>>> er.java:85) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleH >>>>>>>>> an >>>>>>>>> dl >>>>>>>>> er.h >>>>>>>>> an >>>>>>>>> dleRequest(ServletSecurityRoleHandler.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.han >>>>>>>>> dl >>>>>>>>> eR >>>>>>>>> eque >>>>>>>>> st >>>>>>>>> (ServletDispatchingHandler.java:36) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAss >>>>>>>>> oc >>>>>>>>> ia >>>>>>>>> tion >>>>>>>>> Ha >>>>>>>>> ndler.handleRequest(SecurityContextAssociationHandler.java >>>>>>>>> :7 >>>>>>>>> 8) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssoci >>>>>>>>> at >>>>>>>>> io >>>>>>>>> nHan >>>>>>>>> dl >>>>>>>>> er.handleRequest(SSLInformationAssociationHandler.java:131 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.ServletAuthenticatio >>>>>>>>> nC >>>>>>>>> al >>>>>>>>> lHan >>>>>>>>> dl >>>>>>>>> er.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.AbstractConfidentialityHandl >>>>>>>>> er >>>>>>>>> .h >>>>>>>>> andl >>>>>>>>> eR >>>>>>>>> equest(AbstractConfidentialityHandler.java:46) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.ServletConfidentiali >>>>>>>>> ty >>>>>>>>> Co >>>>>>>>> nstr >>>>>>>>> ai >>>>>>>>> ntHandler.handleRequest(ServletConfidentialityConstraintHa >>>>>>>>> nd >>>>>>>>> le >>>>>>>>> r.ja >>>>>>>>> va >>>>>>>>> :64) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler. >>>>>>>>> hand >>>>>>>>> le >>>>>>>>> Request(AuthenticationMechanismsHandler.java:58) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedS >>>>>>>>> es >>>>>>>>> si >>>>>>>>> onHa >>>>>>>>> nd >>>>>>>>> ler.handleRequest(CachedAuthenticatedSessionHandler.java:7 >>>>>>>>> 2) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.NotificationReceiverHandler. >>>>>>>>> ha >>>>>>>>> nd >>>>>>>>> leRe >>>>>>>>> qu >>>>>>>>> est(NotificationReceiverHandler.java:50) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.security.handlers.SecurityInitialHandler.handl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uest >>>>>>>>> (S >>>>>>>>> ecurityInitialHandler.java:76) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler. >>>>>>>>> >>>>>>>>> ha >>>>>>>>> ndleRequest(JACCContextIdHandler.java:61) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest >>>>>>>>> (P >>>>>>>>> re >>>>>>>>> dica >>>>>>>>> te >>>>>>>>> Handler.java:43) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.handlers.MetricsHandler.handleRequest(M >>>>>>>>> et >>>>>>>>> ri >>>>>>>>> csHa >>>>>>>>> nd >>>>>>>>> ler.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.core.MetricsChainHandler.handleRequest >>>>>>>>> (M >>>>>>>>> et >>>>>>>>> rics >>>>>>>>> Ch >>>>>>>>> ainHandler.java:59) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleF >>>>>>>>> ir >>>>>>>>> st >>>>>>>>> Requ >>>>>>>>> es >>>>>>>>> t(ServletInitialHandler.java:274) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatc >>>>>>>>> hR >>>>>>>>> eq >>>>>>>>> uest >>>>>>>>> (S >>>>>>>>> ervletInitialHandler.java:253) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$ >>>>>>>>> 00 >>>>>>>>> 0( >>>>>>>>> Serv >>>>>>>>> le >>>>>>>>> tInitialHandler.java:80) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handl >>>>>>>>> eR >>>>>>>>> eq >>>>>>>>> uest >>>>>>>>> (S >>>>>>>>> ervletInitialHandler.java:172) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.Connectors.executeRootHandler(Connectors. >>>>>>>>> ja >>>>>>>>> va:1 >>>>>>>>> 99 >>>>>>>>> ) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java: >>>>>>>>> >>>>>>>>> 774) >>>>>>>>> >>>>>>>>> at >>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at >>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at java.lang.Thread.run(Unknown Source) >>>>>>>>> >>>>>>>>> Caused by: org.jboss.resteasy.spi.UnhandledException: >>>>>>>>> java.lang.NullPointerException >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ExceptionHandler.handleApplication >>>>>>>>> Ex >>>>>>>>> ce >>>>>>>>> ptio >>>>>>>>> n( >>>>>>>>> ExceptionHandler.java:76) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ExceptionHandler.handleException(E >>>>>>>>> xc >>>>>>>>> ep >>>>>>>>> tion >>>>>>>>> Ha >>>>>>>>> ndler.java:212) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.writeExcepti >>>>>>>>> on >>>>>>>>> (S >>>>>>>>> ynch >>>>>>>>> ro >>>>>>>>> nousDispatcher.java:149) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>>> ro >>>>>>>>> no >>>>>>>>> usDi >>>>>>>>> sp >>>>>>>>> atcher.java:372) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>>> ro >>>>>>>>> no >>>>>>>>> usDi >>>>>>>>> sp >>>>>>>>> atcher.java:179) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainer >>>>>>>>> Di >>>>>>>>> sp >>>>>>>>> atch >>>>>>>>> er >>>>>>>>> .service(ServletContainerDispatcher.java:220) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispa >>>>>>>>> tc >>>>>>>>> he >>>>>>>>> r.se >>>>>>>>> rv >>>>>>>>> ice(HttpServletDispatcher.java:56) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispa >>>>>>>>> tc >>>>>>>>> he >>>>>>>>> r.se >>>>>>>>> rv >>>>>>>>> ice(HttpServletDispatcher.java:51) >>>>>>>>> >>>>>>>>> at >>>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:79 >>>>>>>>> 0) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest( >>>>>>>>> Se >>>>>>>>> rv >>>>>>>>> letH >>>>>>>>> an >>>>>>>>> dler.java:86) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> FilterHandler.java:130) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.services.filters.ClientConnectionFilter.doFil >>>>>>>>> te >>>>>>>>> r( >>>>>>>>> Clie >>>>>>>>> nt >>>>>>>>> ConnectionFilter.java:41) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter. >>>>>>>>> java >>>>>>>>> :6 >>>>>>>>> 0) >>>>>>>>> >>>>>>>>> at >>>>>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> FilterHandler.java:132) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter >>>>>>>>> .d >>>>>>>>> oF >>>>>>>>> ilte >>>>>>>>> r( >>>>>>>>> KeycloakSessionServletFilter.java:40) >>>>>>>>> >>>>>>>>> ... 31 more >>>>>>>>> >>>>>>>>> Caused by: java.lang.NullPointerException >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu >>>>>>>>> eU >>>>>>>>> se >>>>>>>>> rInf >>>>>>>>> o( >>>>>>>>> UserInfoEndpoint.java:128) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issu >>>>>>>>> eU >>>>>>>>> se >>>>>>>>> rInf >>>>>>>>> oG >>>>>>>>> et(UserInfoEndpoint.java:101) >>>>>>>>> >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>> Method) >>>>>>>>> >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown >>>>>>>>> Source) >>>>>>>>> >>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodIn >>>>>>>>> je >>>>>>>>> ct >>>>>>>>> orIm >>>>>>>>> pl >>>>>>>>> .java:137) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarg >>>>>>>>> et >>>>>>>>> (R >>>>>>>>> esou >>>>>>>>> rc >>>>>>>>> eMethodInvoker.java:296) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resou >>>>>>>>> rc >>>>>>>>> eM >>>>>>>>> etho >>>>>>>>> dI >>>>>>>>> nvoker.java:250) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar >>>>>>>>> ge >>>>>>>>> tO >>>>>>>>> bjec >>>>>>>>> t( >>>>>>>>> ResourceLocatorInvoker.java:140) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso >>>>>>>>> ur >>>>>>>>> ce >>>>>>>>> Loca >>>>>>>>> to >>>>>>>>> rInvoker.java:109) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTar >>>>>>>>> ge >>>>>>>>> tO >>>>>>>>> bjec >>>>>>>>> t( >>>>>>>>> ResourceLocatorInvoker.java:135) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Reso >>>>>>>>> ur >>>>>>>>> ce >>>>>>>>> Loca >>>>>>>>> to >>>>>>>>> rInvoker.java:103) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synch >>>>>>>>> ro >>>>>>>>> no >>>>>>>>> usDi >>>>>>>>> sp >>>>>>>>> atcher.java:356) >>>>>>>>> >>>>>>>>> ... 42 more >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The user guide says ? >>>>>>>>> >>>>>>>>> If you need to prevent node failures from requiring users to >>>>>>>>> log in again, set the owners attribute to 2 or more for the >>>>>>>>> sessions cache >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Questions - >>>>>>>>> >>>>>>>>> 1. Have we configured Infinispan incorrectly? We don?t want >>>>>>>>> the users to login again if any of the nodes in the cluster go >>>>>>>>> down. >>>>>>>>> >>>>>>>>> 2. Will changing distributed-cache to replicated-cache help in >>>>>>>>> this scenario? >>>>>>>>> >>>>>>>>> 3. Any way we can see the contents of the cache? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Rajat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 srossillo at smartling.com Fri Aug 7 12:42:44 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 7 Aug 2015 12:42:44 -0400 Subject: [keycloak-user] User attributes as custom claims? In-Reply-To: <55C4C270.2090708@redhat.com> References: <4289D25C-FCE7-4ABD-8D77-13B0C8ABE784@smartling.com> <55C4C270.2090708@redhat.com> Message-ID: Works like a charm! Thanks Bill! ~ Scott > On Aug 7, 2015, at 10:36 AM, Bill Burke wrote: > > Define a mapper to map the user attribute to a claim. Look in the > Client "mapper" tab. > > On 8/7/2015 10:03 AM, Scott Rossillo wrote: >> Hi, >> >> Is there a way to get user attributes returned from Keycloak by requesting it as a claim or some other method? The only way I can get user attributes right now is via an admin api call for a user resource. Am I missing something? >> >> Thanks, >> Scott >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From stian at redhat.com Mon Aug 10 03:08:22 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 10 Aug 2015 03:08:22 -0400 (EDT) Subject: [keycloak-user] JBoss BPM Suite integration with Keycloak In-Reply-To: References: Message-ID: <1308123449.7615629.1439190502782.JavaMail.zimbra@redhat.com> The error you are getting is caused by the fact that you're either not including the redirect_uri param in the code -> token request, or you are including an invalid value. According to the spec if redirect_uri was included in the authorization request it also needs to be included (and match) in the access token request. ----- Original Message ----- > From: "Paulo Jer?nimo" > To: keycloak-user at lists.jboss.org > Sent: Monday, 3 August, 2015 1:24:34 PM > Subject: [keycloak-user] JBoss BPM Suite integration with Keycloak > > Hello! > > I need to make the Business Center and the Dashbuilder (JBoss BPM Suite) to > authenticate using a realm created in Keycloak. I have all the necessary > settings. My steps can be reproduced with an script. The Keycloak 1.4.0 > examples are successfully executed in this instance configured JBoss BPM > Suite. It is configured with patches for JBoss EAP 6.4.2 and, also, with > patches for JBoss BPM Suite 6.1.1. The datasources are configured for a > Oracle instance. I exported the realm for myapp-realm.json file and I'm > starting the JBoss BPM Suite. I can log into Dashbuilder but in the Central > Business I am getting the following error: > > https://github.com/paulojeronimo/gerador-jboss-bpmsuite-keycloak/blob/master/problemas/01/a.log > > My JBoss BPM Suite integration project with Keycloak is public and available: > > https://github.com/paulojeronimo/gerador-jboss-bpmsuite-keycloak > > Can help me solve this problem? > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From stian at redhat.com Mon Aug 10 03:12:47 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 10 Aug 2015 03:12:47 -0400 (EDT) Subject: [keycloak-user] WG: AW: AW: multi tenant configuration with 1.3.1? In-Reply-To: <1CBE59D9C302B841A9562E1A3A6F5B7333083E6A@LAXEX004.oebb.at> References: <1CBE59D9C302B841A9562E1A3A6F5B7333076AED@LAXEX004.oebb.at> <980465831.2641731.1437564183052.JavaMail.zimbra@redhat.com> <1CBE59D9C302B841A9562E1A3A6F5B7333076B48@LAXEX004.oebb.at> <913052916.2646145.1437564831858.JavaMail.zimbra@redhat.com> <1CBE59D9C302B841A9562E1A3A6F5B7333076B6D@LAXEX004.oebb.at> <1781006219.2656792.1437565562724.JavaMail.zimbra@redhat.com> <1CBE59D9C302B841A9562E1A3A6F5B7333083E6A@LAXEX004.oebb.at> Message-ID: <1098353545.7617937.1439190767267.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > To: keycloak-user at lists.jboss.org > Sent: Monday, 3 August, 2015 2:31:16 PM > Subject: [keycloak-user] WG: AW: AW: multi tenant configuration with 1.3.1? > > > > > > > > In our current setup, each tenant is using several realms. Each tenant is > using it?s own database. This setup fits exactly to our needs. However, we?d > need 1.3.1 features, so I?m searching for the best fitting new setup. For those scenarios we assume the use of separate Keycloak instances using for example OpenShift or Docker. It's very unlikely that we'd support configuring different databases for different realms or bringing in additional concepts of tenants than a realm. > > > > @ multi-tenancy example: after following the steps mentioned in the example, > I see the urls configured in the ?tenant-realm? > > > > > > The url of the client-id multi-tenant brings 404 > > The url of the client-id security-admin-console and account brings the login > page, but the user user-tenant1 cannot login (we?re sorry ? no access) Did you follow the readme for the multi-tenancy example? It specifies the urls to visit for each "tenant". > > > > > > > > -----Urspr?ngliche Nachricht----- > Von: Stian Thorgersen [ mailto:stian at redhat.com ] > Gesendet: Mittwoch, 22. Juli 2015 13:46 > An: Hipfinger Martin (BCC.?BB.TicketShop.MA) > Betreff: Re: AW: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > > > Yes, multi-tenancy is based on realms. Why would we need two levels of > multi-tenancy? > > > > I'd need more info about what your problem is to be able to help you out with > the multi-tenancy example > > > > ----- Original Message ----- > > > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > > > < Martin.Hipfinger at oebb.at > > > > To: "Stian Thorgersen" < stian at redhat.com > > > > Sent: Wednesday, 22 July, 2015 1:41:05 PM > > > Subject: AW: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > > > > > But i don't understand the multi tenancy concept then - is it based > > > just on realms? However, I couldn't get this example working either > > > https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant > > > > > > -----Urspr?ngliche Nachricht----- > > > Von: Stian Thorgersen [ mailto:stian at redhat.com ] > > > Gesendet: Mittwoch, 22. Juli 2015 13:34 > > > An: Hipfinger Martin (BCC.?BB.TicketShop.MA) > > > Betreff: Re: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > > > > > Ah, sorry thought you where talking about providers. We don't support > > > overlays and really never have, it was an experimental feature. You > > > should configure Keycloak through > > standalone/configuration/keycloak-server.json. > > > > > > ----- Original Message ----- > > > > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > > > > < Martin.Hipfinger at oebb.at > > > > > To: "Stian Thorgersen" < stian at redhat.com > > > > > Sent: Wednesday, 22 July, 2015 1:30:12 PM > > > > Subject: AW: [keycloak-user] multi tenant configuration with 1.3.1? > > > > > > > > Hi, > > > > > > > > i've already done that for sure - but cannot see the necessary > > > > steps; would you please be so kind and point me to the right direction? > > > > > > > > br, > > > > Martin > > > > > > > > -----Urspr?ngliche Nachricht----- > > > > Von: Stian Thorgersen [ mailto:stian at redhat.com ] > > > > Gesendet: Mittwoch, 22. Juli 2015 13:23 > > > > An: Hipfinger Martin (BCC.?BB.TicketShop.MA) > > > > Cc: keycloak-user at lists.jboss.org > > > > Betreff: Re: [keycloak-user] multi tenant configuration with 1.3.1? > > > > > > > > Read the manual: > > > > http://keycloak.github.io/docs/userguide/html/Migration_from_older_v > > > > er > > > > sions.html#d4e3319 > > > > > > > > ----- Original Message ----- > > > > > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > > > > > < Martin.Hipfinger at oebb.at > > > > > > To: keycloak-user at lists.jboss.org > > > > > Sent: Wednesday, 22 July, 2015 1:07:54 PM > > > > > Subject: [keycloak-user] multi tenant configuration with 1.3.1? > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > we?re running keycloak 1.1 with several overlays ? in detail: > > > > > > > > > > > > > > > > > > > > - A new datasource per overlay > > > > > > > > > > /opt/keycloak/bin/jboss-cli.sh --commands="connect, data-source > > > > > add --name= xxx DS --connection-url=jdbc:oracle:thin:@ > > > > > xxxxx:1522:xxxxx --jndi-name=java:jboss/datasources/ xxx DS > > > > > --driver-name=ojdbc --password= xxx --user-name= XXX " > > > > > > > > > > > > > > > > > > > > - A new auth-server entry > > > > > > > > > > /opt/keycloak/bin/jboss-cli.sh --commands="connect, > > > > > /subsystem=keycloak/auth-server= xxx -server/:add(web-context= xxx > > > > > , enabled=true)" > > > > > > > > > > > > > > > > > > > > - An own keycloak-server.json > > > > > > > > > > "connectionsJpa": { > > > > > > > > > > "default": { > > > > > > > > > > "dataSource": "java:jboss/datasources/ xxx DS", > > > > > > > > > > "databaseSchema": "update" > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > "connectionsInfinispan": { > > > > > > > > > > "default" : { > > > > > > > > > > "cacheContainer" : "java:jboss/infinispan/ xxx Keycloak" > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > /opt/keycloak/bin/jboss-cli.sh --commands=?connect, > > > > > /subsystem=keycloak/auth-server= xxx > > > > > -server:update-server-config(bytes-to-upload=/opt/keycloak/standal > > > > > on > > > > > e/ > > > > > configuration/keycloak-server- > > > > > xxx .json,overwrite=true)? > > > > > > > > > > > > > > > > > > > > This configuration isn?t supported anymore with 1.3.1 - do you > > > > > have any hint for me, how to achieve a similar config with 1.3.1? > > > > > > > > > > > > > > > > > > > > br, > > > > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 stian at redhat.com Mon Aug 10 03:30:22 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 10 Aug 2015 03:30:22 -0400 (EDT) Subject: [keycloak-user] WebSockets In-Reply-To: <55C21BB0.4000706@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> Message-ID: <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: "Marek Posolda" , "pslegr" , keycloak-user at lists.jboss.org > Sent: Wednesday, 5 August, 2015 4:20:32 PM > Subject: Re: [keycloak-user] WebSockets > > On 08/05/2015 03:39 PM, Marek Posolda wrote: > > Maybe it's > > possible the server will poll the client socket and ask for updated > > token from the client periodically. I am not sure about the possible and > > best option TBH (not have deep websocket knowledge) > > It is possible, but that goes into the "invasive" approach, as it can be > done only with a message going from the server to the client. Doing this > at the Keycloak level means that the application has to know how to > handle (or discard) Keycloak-specific messages. > > Honestly, the more I think about it, the more I realize that the best > solution would be to get an API from Keycloak that would allow me to > validate tokens and extract a principal from it, like what the Request > Authenticators do. Even better if this API could call me back from time > to time, so that my server part could ask the client part for a renewed > token. My client could then send this token in the next payload (not > necessarily a payload *only* with the token). +1 I'm less convinced about including token in URI due to security issues + access tokens are short lived. The better option is to send the access token as a message after the socket is open. If the token is expired the server should return with an appropriate error message so the client knows it needs to refresh the access token and resend to the server. We'd need to support this for multiple languages though :/ > > - Juca. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From stian at redhat.com Mon Aug 10 03:32:09 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 10 Aug 2015 03:32:09 -0400 (EDT) Subject: [keycloak-user] Keycloak 1.4.0.Final - new schema (defined in file keycloak-server.json) In-Reply-To: References: Message-ID: <1544337927.7627044.1439191929829.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Emil Posmyk" > To: keycloak-user at lists.jboss.org > Sent: Thursday, 6 August, 2015 12:31:13 PM > Subject: [keycloak-user] Keycloak 1.4.0.Final - new schema (defined in file keycloak-server.json) > > Hi all > > I did upgrade from keycloak 1.1.0.Final to 1.4.0.Final, but I had some issue. > > When I tried to add "schema": "security" in section "connectionsJpa" to file > keycloak-server.json and run first time server to create everything on > database. I recived an error related with liquibase, "REALM" etc. > > Second time i solved it becouse I created default schema and after it I > changed to schema "security" manually on database and later in file > keycloak-server.json. > > It is possible to change the schema without changing manually schema on > database ? I don't understand your question - but you do first have to create the schema in the database and make sure the user has access to it. Keycloak won't create the database schema for you. > > > thanks > -- > Emil Posmyk > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From tair.sabirgaliev at bee.kz Mon Aug 10 04:54:05 2015 From: tair.sabirgaliev at bee.kz (Tair Sabirgaliev) Date: Mon, 10 Aug 2015 14:54:05 +0600 Subject: [keycloak-user] User attribute value length in SQL database Message-ID: Hi, When configuring Keycloak to use Active Directory we found that some attributes could not fit into user_attributes.value column in Postgresql. The problematic values are Cyrillic text. As I suspect, they are encoded using ASCII charset, thus get longer and don?t fit into default 255 length. Workaround was to change the column data type: alter table user_attribute alter COLUMN value type text; Is this the right thing to do considering database evolutions when migrating from version to version? Can this workaround be incorporated into Keycloak codebase? At least for Postgresql it is considered safe performance-wise, references here: 1. http://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying 2. http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/ Thank you! -- Tair Sabirgaliev Bee Software, LLP From bburke at redhat.com Mon Aug 10 09:26:23 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 10 Aug 2015 09:26:23 -0400 Subject: [keycloak-user] WebSockets In-Reply-To: <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> Message-ID: <55C8A67F.6010605@redhat.com> On 8/10/2015 3:30 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Juraci Paix?o Kr?hling" >> To: "Marek Posolda" , "pslegr" , keycloak-user at lists.jboss.org >> Sent: Wednesday, 5 August, 2015 4:20:32 PM >> Subject: Re: [keycloak-user] WebSockets >> >> On 08/05/2015 03:39 PM, Marek Posolda wrote: >>> Maybe it's >>> possible the server will poll the client socket and ask for updated >>> token from the client periodically. I am not sure about the possible and >>> best option TBH (not have deep websocket knowledge) >> >> It is possible, but that goes into the "invasive" approach, as it can be >> done only with a message going from the server to the client. Doing this >> at the Keycloak level means that the application has to know how to >> handle (or discard) Keycloak-specific messages. >> >> Honestly, the more I think about it, the more I realize that the best >> solution would be to get an API from Keycloak that would allow me to >> validate tokens and extract a principal from it, like what the Request >> Authenticators do. Even better if this API could call me back from time >> to time, so that my server part could ask the client part for a renewed >> token. My client could then send this token in the next payload (not >> necessarily a payload *only* with the token). > > +1 > > I'm less convinced about including token in URI due to security issues + access tokens are short lived. The better option is to send the access token as a message after the socket is open. If the token is expired the server should return with an appropriate error message so the client knows it needs to refresh the access token and resend to the server. We'd need to support this for multiple languages though :/ > WebSockets is not a protocol. It is just a means to send packets of data and is not any more sophisticated than that. Applications implement their own protocol on top of it. So the only way to provide something OOTB for WebSockets is to embed the token in a query param on HTTP Upgrade requests. Once the WeBSocket is established there is actually no reason to resend the token as the connection/socket remains open. HTTP requests are different. They need to retransmit the token because HTTP is connectionless and assumes every request is a different connection. For browser apps, logout can be handled in the regular way with keycloak.js. Non-browser apps can just rely on non-browser means. All the server needs is a way to validate and unpack the token. Refresh should be handled at the client side through keycloak.js or some other oauth library. For bearer token auth, it is not the responsibility of the server to manage the token. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From juraci at kroehling.de Mon Aug 10 09:48:42 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Mon, 10 Aug 2015 15:48:42 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <55C8A67F.6010605@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> Message-ID: <55C8ABBA.8060502@kroehling.de> On 08/10/2015 03:26 PM, Bill Burke wrote: > Once the WeBSocket is established there is > actually no reason to resend the token as the connection/socket remains > open. HTTP requests are different. They need to retransmit the token > because HTTP is connectionless and assumes every request is a different > connection. For browser apps, logout can be handled in the regular way > with keycloak.js. Non-browser apps can just rely on non-browser means. > > All the server needs is a way to validate and unpack the token. Refresh > should be handled at the client side through keycloak.js or some other > oauth library. For bearer token auth, it is not the responsibility of > the server to manage the token. Not sure I get it. Are you saying that my server endpoint should trust that the client will close the connection once the token expires/is invalidated? - Juca. From mposolda at redhat.com Mon Aug 10 09:49:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 10 Aug 2015 15:49:43 +0200 Subject: [keycloak-user] User attribute value length in SQL database In-Reply-To: References: Message-ID: <55C8ABF7.6040307@redhat.com> Hi, can you try to use "varchar(2048)" instead of "text" ? The potential issue with "text" is, that it's PostgreSQL specific stuff and may not be supported by all databases, which we need to support in Keycloak. Please let me know if it works and feel free to create JIRA. We will then fix Liquibase script (the thing, which we are using to create DB tables and schema) and in Keycloak 1.5 it will be fixed and the length should suffice. If you can fix and test by yourself and send PR to Keycloak master, it will be even better :-) Thanks, Marek On 10.8.2015 10:54, Tair Sabirgaliev wrote: > Hi, > > When configuring Keycloak to use Active Directory we found that some > attributes could not fit into user_attributes.value column in Postgresql. > The problematic values are Cyrillic text. As I suspect, they are encoded > using ASCII charset, thus get longer and don?t fit into default 255 length. > Workaround was to change the column data type: > > alter table user_attribute alter COLUMN value type text; > > Is this the right thing to do considering database evolutions when > migrating from version to version? Can this workaround be incorporated > into Keycloak codebase? At least for Postgresql it is considered safe > performance-wise, references here: > > 1. http://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying > 2. http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/ > > Thank you! > -- > Tair Sabirgaliev > Bee Software, LLP > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From bburke at redhat.com Mon Aug 10 10:10:36 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 10 Aug 2015 10:10:36 -0400 Subject: [keycloak-user] WebSockets In-Reply-To: <55C8ABBA.8060502@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> <55C1CD8C.7070907@redhat.com> <55C1CE80.8090802@redhat.com> <55C1DC0D.3080802@kroehling.de> <55C1F90B.6060409@redhat.com> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> Message-ID: <55C8B0DC.2030704@redhat.com> On 8/10/2015 9:48 AM, Juraci Paix?o Kr?hling wrote: > On 08/10/2015 03:26 PM, Bill Burke wrote: >> Once the WeBSocket is established there is >> actually no reason to resend the token as the connection/socket remains >> open. HTTP requests are different. They need to retransmit the token >> because HTTP is connectionless and assumes every request is a different >> connection. For browser apps, logout can be handled in the regular way >> with keycloak.js. Non-browser apps can just rely on non-browser means. >> >> All the server needs is a way to validate and unpack the token. Refresh >> should be handled at the client side through keycloak.js or some other >> oauth library. For bearer token auth, it is not the responsibility of >> the server to manage the token. > > Not sure I get it. Are you saying that my server endpoint should trust > that the client will close the connection once the token expires/is > invalidated? > I didn't say that. You just don't have to retransmit the token every request because in WebSockets the connection is already established. You are going to have to rely on the client to get a new token and reconnect. Keycloak can't support every single pet protocol implemented on top of WebSockets. We can only offer token validation on HTTP Upgrade out-of-the-box plus an API to unpack and validate a token. Anything more and you'll have to implement it yourself. IMO, abort with an error code, the client destroys the WebSocket, refreshes the token via OAuth, and reestablishes the WebSocket. Its the simplest way and we can provide support for it OOTB with Keycloak's adapter lib. Otherwise you'll have to implement anything more complex yourself. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From tair.sabirgaliev at bee.kz Mon Aug 10 10:44:34 2015 From: tair.sabirgaliev at bee.kz (Tair Sabirgaliev) Date: Mon, 10 Aug 2015 20:44:34 +0600 Subject: [keycloak-user] User attribute value length in SQL database In-Reply-To: <55C8ABF7.6040307@redhat.com> References: <55C8ABF7.6040307@redhat.com> Message-ID: Do you object something like this: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? issue with "text" is, that it's PostgreSQL specific stuff and may not be > supported by all databases, which we need to support in Keycloak. > > Please let me know if it works and feel free to create JIRA. We will > then fix Liquibase script (the thing, which we are using to create DB > tables and schema) and in Keycloak 1.5 it will be fixed and the length > should suffice. If you can fix and test by yourself and send PR to > Keycloak master, it will be even better :-) > > Thanks, > Marek > > On 10.8.2015 10:54, Tair Sabirgaliev wrote: > > Hi, > > > > When configuring Keycloak to use Active Directory we found that some > > attributes could not fit into user_attributes.value column in Postgresql. > > The problematic values are Cyrillic text. As I suspect, they are encoded > > using ASCII charset, thus get longer and don?t fit into default 255 length. > > Workaround was to change the column data type: > > > > alter table user_attribute alter COLUMN value type text; > > > > Is this the right thing to do considering database evolutions when > > migrating from version to version? Can this workaround be incorporated > > into Keycloak codebase? At least for Postgresql it is considered safe > > performance-wise, references here: > > > > 1. http://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying > > 2. http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/ > > > > Thank you! > > -- > > Tair Sabirgaliev > > Bee Software, LLP > > > > > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > From mposolda at redhat.com Mon Aug 10 11:20:08 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 10 Aug 2015 17:20:08 +0200 Subject: [keycloak-user] User attribute value length in SQL database In-Reply-To: References: <55C8ABF7.6040307@redhat.com> Message-ID: <55C8C128.50108@redhat.com> In my opinion, it will be better to add something like: in current jpa-changelog-1.5.0.xml in latest master. This won't require any PostgreSQL specific code and it will work for users of other databases (like MySQL etc), which will have similar issue like you and need attributes of bigger length. Or varchar(2048) doesn't work for you? Marek On 10.8.2015 16:44, Tair Sabirgaliev wrote: > Do you object something like this: > > xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.8" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.8 > http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.8.xsd"> > > > > > > > columnName=?value" > newDataType=?text" > schemaName="public" > tableName="user_attribute?/> > > > > > The most interesting part is > http://www.liquibase.org/documentation/preconditions.html > > > -- > Tair Sabirgaliev > Bee Software, LLP > > > > On August 10, 2015 at 19:49:48, Marek Posolda (mposolda at redhat.com(mailto:mposolda at redhat.com)) wrote: > >> Hi, >> >> can you try to use "varchar(2048)" instead of "text" ? The potential >> issue with "text" is, that it's PostgreSQL specific stuff and may not be >> supported by all databases, which we need to support in Keycloak. >> >> Please let me know if it works and feel free to create JIRA. We will >> then fix Liquibase script (the thing, which we are using to create DB >> tables and schema) and in Keycloak 1.5 it will be fixed and the length >> should suffice. If you can fix and test by yourself and send PR to >> Keycloak master, it will be even better :-) >> >> Thanks, >> Marek >> >> On 10.8.2015 10:54, Tair Sabirgaliev wrote: >>> Hi, >>> >>> When configuring Keycloak to use Active Directory we found that some >>> attributes could not fit into user_attributes.value column in Postgresql. >>> The problematic values are Cyrillic text. As I suspect, they are encoded >>> using ASCII charset, thus get longer and don?t fit into default 255 length. >>> Workaround was to change the column data type: >>> >>> alter table user_attribute alter COLUMN value type text; >>> >>> Is this the right thing to do considering database evolutions when >>> migrating from version to version? Can this workaround be incorporated >>> into Keycloak codebase? At least for Postgresql it is considered safe >>> performance-wise, references here: >>> >>> 1. http://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying >>> 2. http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/ >>> >>> Thank you! >>> -- >>> Tair Sabirgaliev >>> Bee Software, LLP >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> From stian at redhat.com Tue Aug 11 01:23:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 11 Aug 2015 01:23:46 -0400 (EDT) Subject: [keycloak-user] WebSockets In-Reply-To: <55C8B0DC.2030704@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> <55C8B0DC.2030704@redhat.com> Message-ID: <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-user at lists.jboss.org > Sent: Monday, 10 August, 2015 4:10:36 PM > Subject: Re: [keycloak-user] WebSockets > > > > On 8/10/2015 9:48 AM, Juraci Paix?o Kr?hling wrote: > > On 08/10/2015 03:26 PM, Bill Burke wrote: > >> Once the WeBSocket is established there is > >> actually no reason to resend the token as the connection/socket remains > >> open. HTTP requests are different. They need to retransmit the token > >> because HTTP is connectionless and assumes every request is a different > >> connection. For browser apps, logout can be handled in the regular way > >> with keycloak.js. Non-browser apps can just rely on non-browser means. > >> > >> All the server needs is a way to validate and unpack the token. Refresh > >> should be handled at the client side through keycloak.js or some other > >> oauth library. For bearer token auth, it is not the responsibility of > >> the server to manage the token. > > > > Not sure I get it. Are you saying that my server endpoint should trust > > that the client will close the connection once the token expires/is > > invalidated? > > > > I didn't say that. You just don't have to retransmit the token every > request because in WebSockets the connection is already established. > > You are going to have to rely on the client to get a new token and > reconnect. Keycloak can't support every single pet protocol implemented > on top of WebSockets. We can only offer token validation on HTTP > Upgrade out-of-the-box plus an API to unpack and validate a token. > Anything more and you'll have to implement it yourself. > > IMO, abort with an error code, the client destroys the WebSocket, > refreshes the token via OAuth, and reestablishes the WebSocket. Its > the simplest way and we can provide support for it OOTB with Keycloak's > adapter lib. Otherwise you'll have to implement anything more complex > yourself. I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From stian at redhat.com Tue Aug 11 01:27:14 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 11 Aug 2015 01:27:14 -0400 (EDT) Subject: [keycloak-user] User attribute value length in SQL database In-Reply-To: References: <55C8ABF7.6040307@redhat.com> Message-ID: <321270227.8483984.1439270834443.JavaMail.zimbra@redhat.com> Yes, I object to that. That only fixes the issue for those that uses PostgreSQL. Even if you added preconditions for every database with the correct data type it would not be maintainable by us in the long run. What Marek proposes is the best option IMO. Alternative is we can introduce a new data type mapper in Liquibase that maps text for those databases that don't support it to varchar(max), blob, or whatever it's suitable, but that's really not something we want to do as it would be a maintenance headache for us. ----- Original Message ----- > From: "Tair Sabirgaliev" > To: keycloak-user at lists.jboss.org, "Marek Posolda" > Sent: Monday, 10 August, 2015 4:44:34 PM > Subject: Re: [keycloak-user] User attribute value length in SQL database > > Do you object something like this: > > ? xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.8" > ? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > ? xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.8 > ? ? ? ? ?http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.8.xsd"> > ? ? > > ? ? ? ? > ? ? ? ? ? ? > ? ? ? ? > > ? ? ? ? ? ? ? ? ? ? columnName=?value" > ? ? ? ? ? ? newDataType=?text" > ? ? ? ? ? ? schemaName="public" > ? ? ? ? ? ? tableName="user_attribute?/> > ? ? > > > > The most interesting part is > http://www.liquibase.org/documentation/preconditions.html > ? > > -- > Tair Sabirgaliev > Bee Software, LLP > > > > On August 10, 2015 at 19:49:48, Marek Posolda > (mposolda at redhat.com(mailto:mposolda at redhat.com)) wrote: > > > Hi, > > > > can you try to use "varchar(2048)" instead of "text" ? The potential > > issue with "text" is, that it's PostgreSQL specific stuff and may not be > > supported by all databases, which we need to support in Keycloak. > > > > Please let me know if it works and feel free to create JIRA. We will > > then fix Liquibase script (the thing, which we are using to create DB > > tables and schema) and in Keycloak 1.5 it will be fixed and the length > > should suffice. If you can fix and test by yourself and send PR to > > Keycloak master, it will be even better :-) > > > > Thanks, > > Marek > > > > On 10.8.2015 10:54, Tair Sabirgaliev wrote: > > > Hi, > > > > > > When configuring Keycloak to use Active Directory we found that some > > > attributes could not fit into user_attributes.value column in Postgresql. > > > The problematic values are Cyrillic text. As I suspect, they are encoded > > > using ASCII charset, thus get longer and don?t fit into default 255 > > > length. > > > Workaround was to change the column data type: > > > > > > alter table user_attribute alter COLUMN value type text; > > > > > > Is this the right thing to do considering database evolutions when > > > migrating from version to version? Can this workaround be incorporated > > > into Keycloak codebase? At least for Postgresql it is considered safe > > > performance-wise, references here: > > > > > > 1. > > > http://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying > > > 2. http://www.depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/ > > > > > > Thank you! > > > -- > > > Tair Sabirgaliev > > > Bee Software, LLP > > > > > > > > > > > > > > > _______________________________________________ > > > 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 juraci at kroehling.de Tue Aug 11 03:56:25 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 11 Aug 2015 09:56:25 +0200 Subject: [keycloak-user] WebSockets In-Reply-To: <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> <55C8B0DC.2030704@redhat.com> <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> Message-ID: <55C9AAA9.5020304@kroehling.de> On 08/11/2015 07:23 AM, Stian Thorgersen wrote: > I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat. Just to be clear: Keycloak would not listen to or send messages, right? It's all part of an API that Keycloak would provide, so that server endpoints can validate/check tokens when needed. If so, I could then start some PoC for that. - Juca. From stian at redhat.com Tue Aug 11 04:01:45 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 11 Aug 2015 04:01:45 -0400 (EDT) Subject: [keycloak-user] WebSockets In-Reply-To: <55C9AAA9.5020304@kroehling.de> References: <55C0CFE5.3080108@kroehling.de> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> <55C8B0DC.2030704@redhat.com> <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> <55C9AAA9.5020304@kroehling.de> Message-ID: <570301502.8524084.1439280105793.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-user at lists.jboss.org > Sent: Tuesday, 11 August, 2015 9:56:25 AM > Subject: Re: [keycloak-user] WebSockets > > On 08/11/2015 07:23 AM, Stian Thorgersen wrote: > > I know there's no standard protocol, but I still think the token should be > > sent through the socket itself not as part of the url. I don't like > > sending it as the url for one, secondly having to drop and re-create the > > socket every time the token expires negates the purpose of web sockets > > somewhat. > > Just to be clear: Keycloak would not listen to or send messages, right? > It's all part of an API that Keycloak would provide, so that server > endpoints can validate/check tokens when needed. Yep - there's no way for KC to listen/send to message unless we only support some specific protocols on top of web sockets. We should already have the utilities available to parse and verify the tokens on the server end. On the client end keycloak.js should cover what's needed as you can get the token and refresh it as well. > > If so, I could then start some PoC for that. > > - Juca. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From christopher.james.davies at gmail.com Tue Aug 11 06:31:19 2015 From: christopher.james.davies at gmail.com (Christopher Davies) Date: Tue, 11 Aug 2015 10:31:19 +0000 Subject: [keycloak-user] Desktop Apps Message-ID: I am looking to use KeyCloak to authenticate our software. Some of our the components of our software are java desktop applications. I know that I can send an openid connection from my application to KeyCloak to get a JWT. Looking at this protocol, it seems only to support username/password. Is there a recommended way to use Kerberose, to authenticate so that my windows users do not need to type username/password if they are logged in correctly to their desktops ? Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150811/a7903af4/attachment.html From bmcwhirt at redhat.com Tue Aug 11 08:15:15 2015 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Tue, 11 Aug 2015 08:15:15 -0400 Subject: [keycloak-user] WebSockets In-Reply-To: <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> <55C8B0DC.2030704@redhat.com> <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> Message-ID: For at least opening the web socket, assuming the user has the cookie or bearer token already, it can go with the initial HTTP upgrade request. Browsers send cookies on the WebSocket connect, and I think you can add the bearer token if that?s how you?re flying. Subsequent re-auth, as Bill said, should be up to the user and how he?s using the socket. -Bob > On Aug 11, 2015, at 1:23 AM, Stian Thorgersen wrote: > > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-user at lists.jboss.org >> Sent: Monday, 10 August, 2015 4:10:36 PM >> Subject: Re: [keycloak-user] WebSockets >> >> >> >> On 8/10/2015 9:48 AM, Juraci Paix?o Kr?hling wrote: >>> On 08/10/2015 03:26 PM, Bill Burke wrote: >>>> Once the WeBSocket is established there is >>>> actually no reason to resend the token as the connection/socket remains >>>> open. HTTP requests are different. They need to retransmit the token >>>> because HTTP is connectionless and assumes every request is a different >>>> connection. For browser apps, logout can be handled in the regular way >>>> with keycloak.js. Non-browser apps can just rely on non-browser means. >>>> >>>> All the server needs is a way to validate and unpack the token. Refresh >>>> should be handled at the client side through keycloak.js or some other >>>> oauth library. For bearer token auth, it is not the responsibility of >>>> the server to manage the token. >>> >>> Not sure I get it. Are you saying that my server endpoint should trust >>> that the client will close the connection once the token expires/is >>> invalidated? >>> >> >> I didn't say that. You just don't have to retransmit the token every >> request because in WebSockets the connection is already established. >> >> You are going to have to rely on the client to get a new token and >> reconnect. Keycloak can't support every single pet protocol implemented >> on top of WebSockets. We can only offer token validation on HTTP >> Upgrade out-of-the-box plus an API to unpack and validate a token. >> Anything more and you'll have to implement it yourself. >> >> IMO, abort with an error code, the client destroys the WebSocket, >> refreshes the token via OAuth, and reestablishes the WebSocket. Its >> the simplest way and we can provide support for it OOTB with Keycloak's >> adapter lib. Otherwise you'll have to implement anything more complex >> yourself. > > I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat. > >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150811/89cf3208/attachment.html From bburke at redhat.com Tue Aug 11 10:22:18 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 11 Aug 2015 10:22:18 -0400 Subject: [keycloak-user] WebSockets In-Reply-To: <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C209DE.6080000@kroehling.de> <55C211FB.4070805@redhat.com> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> <55C8B0DC.2030704@redhat.com> <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> Message-ID: <55CA051A.5050501@redhat.com> On 8/11/2015 1:23 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-user at lists.jboss.org >> Sent: Monday, 10 August, 2015 4:10:36 PM >> Subject: Re: [keycloak-user] WebSockets >> >> >> >> On 8/10/2015 9:48 AM, Juraci Paix?o Kr?hling wrote: >>> On 08/10/2015 03:26 PM, Bill Burke wrote: >>>> Once the WeBSocket is established there is >>>> actually no reason to resend the token as the connection/socket remains >>>> open. HTTP requests are different. They need to retransmit the token >>>> because HTTP is connectionless and assumes every request is a different >>>> connection. For browser apps, logout can be handled in the regular way >>>> with keycloak.js. Non-browser apps can just rely on non-browser means. >>>> >>>> All the server needs is a way to validate and unpack the token. Refresh >>>> should be handled at the client side through keycloak.js or some other >>>> oauth library. For bearer token auth, it is not the responsibility of >>>> the server to manage the token. >>> >>> Not sure I get it. Are you saying that my server endpoint should trust >>> that the client will close the connection once the token expires/is >>> invalidated? >>> >> >> I didn't say that. You just don't have to retransmit the token every >> request because in WebSockets the connection is already established. >> >> You are going to have to rely on the client to get a new token and >> reconnect. Keycloak can't support every single pet protocol implemented >> on top of WebSockets. We can only offer token validation on HTTP >> Upgrade out-of-the-box plus an API to unpack and validate a token. >> Anything more and you'll have to implement it yourself. >> >> IMO, abort with an error code, the client destroys the WebSocket, >> refreshes the token via OAuth, and reestablishes the WebSocket. Its >> the simplest way and we can provide support for it OOTB with Keycloak's >> adapter lib. Otherwise you'll have to implement anything more complex >> yourself. > > I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat. > I just don't see how this is feasible beyond providing a simple servlet-aware helper class on the server side that would be used only on connection setup. But you still have the problem of when the access token expires. That would have to be handled by the application because the protocol would be app specific. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From Martin.Hipfinger at oebb.at Tue Aug 11 10:24:22 2015 From: Martin.Hipfinger at oebb.at (=?iso-8859-1?Q?Hipfinger_Martin_=28BCC=2E=D6BB=2ETicketShop=2EMA=29?=) Date: Tue, 11 Aug 2015 14:24:22 +0000 Subject: [keycloak-user] Updating Oracle database schema to 1.3.1 fails Message-ID: <1CBE59D9C302B841A9562E1A3A6F5B7333087118@LAXEX004.oebb.at> i have a working setup with keycloak 1.1.0 using Oracle. When I try to upgrade schema using Keycloak 1.3.1.Final it fails. Setting in keycloak-server.json "connectionsJpa": { "default": { "dataSource": "java:jboss/datasources/myDS", "databaseSchema": "update" } } upgrade to 1.2.0: 15:35:35,309 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (MSC service thread 1-2) Change Set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com failed. Error: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) at liquibase.Liquibase.update(Liquibase.java:200) at liquibase.Liquibase.update(Liquibase.java:181) at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) [keycloak-connections-jpa-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) [keycloak-connections-jpa-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) [keycloak-connections-jpa-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) [keycloak-model-jpa-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) [keycloak-model-jpa-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) [keycloak-invalidation-cache-model-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) [keycloak-invalidation-cache-model-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:155) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_40] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_40] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_40] at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_40] at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) [resteasy-jaxrs-3.0.10.Final.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-3.0.10.Final.jar:] at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) ... 43 more Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] ... 45 more 15:35:35,344 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) 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: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] Caused by: java.lang.RuntimeException: 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:160) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) 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:79) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] ... 3 more Caused by: java.lang.RuntimeException: Failed to update database at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) at org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:155) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_40] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_40] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_40] at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_40] at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) ... 18 more Caused by: liquibase.exception.MigrationFailedException: Migration failed for change set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: Reason: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.changelog.ChangeSet.execute(ChangeSet.java:586) at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) at liquibase.Liquibase.update(Liquibase.java:200) at liquibase.Liquibase.update(Liquibase.java:181) at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) ... 36 more Caused by: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) ... 41 more Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) at org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) ... 43 more Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) ... 45 more 15:35:35,366 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "main-auth-server.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./auth" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: Failed to start service Caused by: java.lang.RuntimeException: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: Failed to update database Caused by: liquibase.exception.MigrationFailedException: Migration failed for change set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: Reason: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version Caused by: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long"}} upgrade to 1.3.1: 14:40:00,682 INFO [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool - 61) Updating database 14:40:01,905 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool - 61) Change Set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com failed. Error: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) at liquibase.Liquibase.update(Liquibase.java:200) at liquibase.Liquibase.update(Liquibase.java:181) at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) at org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:157) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:87) 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:422) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) 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:230) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) 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) Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) at org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) ... 44 more Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) ... 46 more 14:40:01,930 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool - 61) 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: 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: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: java.lang.RuntimeException: 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:160) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) 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:230) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) 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: java.lang.RuntimeException: Failed to update database at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) at org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:157) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:87) 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:422) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) ... 19 more Caused by: liquibase.exception.MigrationFailedException: Migration failed for change set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: Reason: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.changelog.ChangeSet.execute(ChangeSet.java:586) at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) at liquibase.Liquibase.update(Liquibase.java:200) at liquibase.Liquibase.update(Liquibase.java:181) at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) ... 37 more Caused by: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) ... 42 more Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) at org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) at liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) ... 44 more Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) at org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) ... 46 more 14:40:01,945 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"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: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: Failed to update database Caused by: liquibase.exception.MigrationFailedException: Migration failed for change set META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: Reason: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version Caused by: liquibase.exception.UnexpectedLiquibaseException: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version Caused by: liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: Exception when updating data from previous version Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Long"}} Thx for your help! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150811/573b1f07/attachment-0001.html From mposolda at redhat.com Tue Aug 11 10:39:46 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 11 Aug 2015 16:39:46 +0200 Subject: [keycloak-user] Updating Oracle database schema to 1.3.1 fails In-Reply-To: <1CBE59D9C302B841A9562E1A3A6F5B7333087118@LAXEX004.oebb.at> References: <1CBE59D9C302B841A9562E1A3A6F5B7333087118@LAXEX004.oebb.at> Message-ID: <55CA0932.4020004@redhat.com> This issue was reported few days back in different mail http://lists.jboss.org/pipermail/keycloak-user/2015-August/002762.html . As you can see there is already JIRA https://issues.jboss.org/browse/KEYCLOAK-1725, which was fixed in keycloak master and will be available in 1.5 release, so upgrading from 1.1.0 to 1.5 should be hopefully fine. Marek On 11.8.2015 16:24, Hipfinger Martin (BCC.?BB.TicketShop.MA) wrote: > > i have a working setup with keycloak 1.1.0 using Oracle. > > When I try to upgrade schema using Keycloak 1.3.1.Final it fails. > > Setting in keycloak-server.json > "connectionsJpa": { > "default": > > { "dataSource": "java:jboss/datasources/myDS", "databaseSchema": > "update" } > > } > > upgrade to 1.2.0: > > 15:35:35,309 ERROR > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (MSC service thread 1-2) Change Set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com > failed. Error: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version: > liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) > at > liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) > at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) > at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) > at liquibase.Liquibase.update(Liquibase.java:200) > at liquibase.Liquibase.update(Liquibase.java:181) > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) > [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) > [keycloak-connections-jpa-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) > [keycloak-connections-jpa-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) > [keycloak-connections-jpa-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) > [keycloak-model-jpa-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) > [keycloak-model-jpa-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) > [keycloak-invalidation-cache-model-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > [keycloak-invalidation-cache-model-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:155) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) [rt.jar:1.8.0_40] > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > [rt.jar:1.8.0_40] > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > [rt.jar:1.8.0_40] > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > [rt.jar:1.8.0_40] > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > [resteasy-jaxrs-3.0.10.Final.jar:] > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_40] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) > [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) > [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) > ... 43 more > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot > be cast to java.lang.Long > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) > [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) > [keycloak-connections-jpa-liquibase-1.2.0.Final.jar:1.2.0.Final] > ... 45 more > > 15:35:35,344 ERROR [org.jboss.msc.service.fail] (MSC service thread > 1-2) 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: Failed to > start service > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_40] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > Caused by: java.lang.RuntimeException: 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:160) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > 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:79) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > Caused by: java.lang.RuntimeException: Failed to update database > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > at > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:155) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) [rt.jar:1.8.0_40] > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > [rt.jar:1.8.0_40] > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > [rt.jar:1.8.0_40] > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > [rt.jar:1.8.0_40] > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > ... 18 more > Caused by: liquibase.exception.MigrationFailedException: Migration > failed for change set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: > Reason: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:586) > at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) > at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) > at liquibase.Liquibase.update(Liquibase.java:200) > at liquibase.Liquibase.update(Liquibase.java:181) > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) > ... 36 more > Caused by: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) > at > liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) > ... 41 more > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) > at > org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) > ... 43 more > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot > be cast to java.lang.Long > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) > ... 45 more > > 15:35:35,366 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) JBAS014613: Operation ("add") failed - > address: ([("deployment" => "main-auth-server.war")]) - failure > description: {"JBAS014671: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth" => > "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: Failed to > start service > Caused by: java.lang.RuntimeException: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.RuntimeException: Failed to update database > Caused by: liquibase.exception.MigrationFailedException: Migration > failed for change set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: > Reason: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > Caused by: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot > be cast to java.lang.Long"}} > > upgrade to 1.3.1: > > 14:40:00,682 INFO > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (ServerService Thread Pool ? 61) Updating database > 14:40:01,905 ERROR > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (ServerService Thread Pool ? 61) Change Set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com > failed. Error: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version: > liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) > at > liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) > at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) > at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) > at liquibase.Liquibase.update(Liquibase.java:200) > at liquibase.Liquibase.update(Liquibase.java:181) > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > at > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:157) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:87) > 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:422) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > 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:230) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) > 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) > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) > at > org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) > ... 44 more > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot > be cast to java.lang.Long > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) > ... 46 more > > 14:40:01,930 ERROR [org.jboss.msc.service.fail] (ServerService Thread > Pool ? 61) 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: 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: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: java.lang.RuntimeException: 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:160) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > 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:230) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) > 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: java.lang.RuntimeException: Failed to update database > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:143) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:35) > at > org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:25) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34) > at > org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:99) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:70) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > at > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:157) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:87) > 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:422) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > ... 19 more > Caused by: liquibase.exception.MigrationFailedException: Migration > failed for change set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: > Reason: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:586) > at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:43) > at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73) > at liquibase.Liquibase.update(Liquibase.java:200) > at liquibase.Liquibase.update(Liquibase.java:181) > at > org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84) > ... 37 more > Caused by: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:185) > at > liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1208) > at liquibase.changelog.ChangeSet.execute(ChangeSet.java:550) > ... 42 more > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:43) > at > org.keycloak.connections.jpa.updater.liquibase.custom.CustomKeycloakTask.generateStatements(CustomKeycloakTask.java:79) > at > liquibase.change.custom.CustomChangeWrapper.generateStatements(CustomChangeWrapper.java:178) > ... 44 more > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot > be cast to java.lang.Long > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.addDefaultProtocolMappers(JpaUpdate1_2_0_Beta1.java:296) > at > org.keycloak.connections.jpa.updater.liquibase.custom.JpaUpdate1_2_0_Beta1.generateStatementsImpl(JpaUpdate1_2_0_Beta1.java:41) > ... 46 more > > 14:40:01,945 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([("deployment" => "keycloak-server.war")]) - failure > description: {"WFLYCTL0080: Failed services" => > {"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: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.RuntimeException: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.RuntimeException: Failed to update database > Caused by: liquibase.exception.MigrationFailedException: Migration > failed for change set > META-INF/jpa-changelog-1.2.0.Beta1.xml::1.2.0.Beta1::psilva at redhat.com: > Reason: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > Caused by: liquibase.exception.UnexpectedLiquibaseException: > liquibase.exception.CustomChangeException: Update 1.2.0.Beta1: > Exception when updating data from previous version > Caused by: liquibase.exception.CustomChangeException: Update > 1.2.0.Beta1: Exception when updating data from previous version > Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot > be cast to java.lang.Long"}} > > Thx for your help! > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150811/99eaabe7/attachment-0001.html From stian at redhat.com Tue Aug 11 11:04:26 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 11 Aug 2015 11:04:26 -0400 (EDT) Subject: [keycloak-user] WebSockets In-Reply-To: <55CA051A.5050501@redhat.com> References: <55C0CFE5.3080108@kroehling.de> <55C21BB0.4000706@kroehling.de> <1149432971.7626105.1439191822009.JavaMail.zimbra@redhat.com> <55C8A67F.6010605@redhat.com> <55C8ABBA.8060502@kroehling.de> <55C8B0DC.2030704@redhat.com> <1041886856.8483388.1439270626681.JavaMail.zimbra@redhat.com> <55CA051A.5050501@redhat.com> Message-ID: <775162293.8809924.1439305466832.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-user at lists.jboss.org > Sent: Tuesday, 11 August, 2015 4:22:18 PM > Subject: Re: [keycloak-user] WebSockets > > > > On 8/11/2015 1:23 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-user at lists.jboss.org > >> Sent: Monday, 10 August, 2015 4:10:36 PM > >> Subject: Re: [keycloak-user] WebSockets > >> > >> > >> > >> On 8/10/2015 9:48 AM, Juraci Paix?o Kr?hling wrote: > >>> On 08/10/2015 03:26 PM, Bill Burke wrote: > >>>> Once the WeBSocket is established there is > >>>> actually no reason to resend the token as the connection/socket remains > >>>> open. HTTP requests are different. They need to retransmit the token > >>>> because HTTP is connectionless and assumes every request is a different > >>>> connection. For browser apps, logout can be handled in the regular way > >>>> with keycloak.js. Non-browser apps can just rely on non-browser means. > >>>> > >>>> All the server needs is a way to validate and unpack the token. Refresh > >>>> should be handled at the client side through keycloak.js or some other > >>>> oauth library. For bearer token auth, it is not the responsibility of > >>>> the server to manage the token. > >>> > >>> Not sure I get it. Are you saying that my server endpoint should trust > >>> that the client will close the connection once the token expires/is > >>> invalidated? > >>> > >> > >> I didn't say that. You just don't have to retransmit the token every > >> request because in WebSockets the connection is already established. > >> > >> You are going to have to rely on the client to get a new token and > >> reconnect. Keycloak can't support every single pet protocol implemented > >> on top of WebSockets. We can only offer token validation on HTTP > >> Upgrade out-of-the-box plus an API to unpack and validate a token. > >> Anything more and you'll have to implement it yourself. > >> > >> IMO, abort with an error code, the client destroys the WebSocket, > >> refreshes the token via OAuth, and reestablishes the WebSocket. Its > >> the simplest way and we can provide support for it OOTB with Keycloak's > >> adapter lib. Otherwise you'll have to implement anything more complex > >> yourself. > > > > I know there's no standard protocol, but I still think the token should be > > sent through the socket itself not as part of the url. I don't like > > sending it as the url for one, secondly having to drop and re-create the > > socket every time the token expires negates the purpose of web sockets > > somewhat. > > > > I just don't see how this is feasible beyond providing a simple > servlet-aware helper class on the server side that would be used only on > connection setup. But you still have the problem of when the access > token expires. That would have to be handled by the application because > the protocol would be app specific. Yes - it would be handled by the application, but we'd provide some helper classes on both the server-side and the client-side to do it > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From mposolda at redhat.com Tue Aug 11 12:51:05 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 11 Aug 2015 18:51:05 +0200 Subject: [keycloak-user] Desktop Apps In-Reply-To: References: Message-ID: <55CA27F9.5090902@redhat.com> We don't have support for this yet, but we may add it. Just not sure when... I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-1751 . We may need to create utility, which will start GSSAPI client interaction ( initSecContext ) and will use the kerberos ticket from the desktop cache , which will be send in the direct grant request. Then on keycloak side, we will have DirectGrantAuthenticator implementation, which will be able to call "acceptSecContext" and validate token sent from client. Marek On 11.8.2015 12:31, Christopher Davies wrote: > I am looking to use KeyCloak to authenticate our software. > Some of our the components of our software are java desktop applications. > > I know that I can send an openid connection from my application to > KeyCloak to get a JWT. Looking at this protocol, it seems only to > support username/password. Is there a recommended way to use > Kerberose, to authenticate so that my windows users do not need to > type username/password if they are logged in correctly to their desktops ? > > Chris > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150811/f6071a08/attachment.html From eugene.chow.ct at gmail.com Wed Aug 12 03:27:59 2015 From: eugene.chow.ct at gmail.com (Eugene Chow) Date: Wed, 12 Aug 2015 15:27:59 +0800 Subject: [keycloak-user] JGRP000010 Version Mismatch errors from running in HA mode Message-ID: Hi guys, I?m running a Keycloak cluster testbed and I keep getting this message even though only 1 instance of Keycloak is running in HA mode. The Keycloak instances are running in KVM containers on a single host machine. > 04:08:36,494 WARNING [org.jgroups.protocols.UDP] (Incoming-4,ee,keycloak1) JGRP000010: packet from 192.168.122.1:1029 has different version (3.4.5) than ours (3.6.4); packet is discarded > 07:16:46,508 WARNING [org.jgroups.protocols.UDP] (Incoming-2,ee,keycloak1) JGRP000010: packet from 192.168.122.1:45688 has different version (3.4.5) than ours (3.6.4); packet is discarded It seems like Keycloak/Infinispan is sending malformed (ie. version mismatch) multicast packets that it would reject. Is there a way to fix this? Thanks in advance! From stian at redhat.com Wed Aug 12 04:04:50 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 12 Aug 2015 04:04:50 -0400 (EDT) Subject: [keycloak-user] JGRP000010 Version Mismatch errors from running in HA mode In-Reply-To: References: Message-ID: <998545072.9165927.1439366690052.JavaMail.zimbra@redhat.com> If you only have 1 single instance running it should not be sending any packets at all. Are you sure there are no other Keycloak or WildFly instances on your network? ----- Original Message ----- > From: "Eugene Chow" > To: keycloak-user at lists.jboss.org > Sent: Wednesday, 12 August, 2015 9:27:59 AM > Subject: [keycloak-user] JGRP000010 Version Mismatch errors from running in HA mode > > Hi guys, > > I?m running a Keycloak cluster testbed and I keep getting this message even > though only 1 instance of Keycloak is running in HA mode. The Keycloak > instances are running in KVM containers on a single host machine. > > > 04:08:36,494 WARNING [org.jgroups.protocols.UDP] (Incoming-4,ee,keycloak1) > > JGRP000010: packet from 192.168.122.1:1029 has different version (3.4.5) > > than ours (3.6.4); packet is discarded > > 07:16:46,508 WARNING [org.jgroups.protocols.UDP] (Incoming-2,ee,keycloak1) > > JGRP000010: packet from 192.168.122.1:45688 has different version (3.4.5) > > than ours (3.6.4); packet is discarded > > > > It seems like Keycloak/Infinispan is sending malformed (ie. version mismatch) > multicast packets that it would reject. Is there a way to fix this? > > > Thanks in advance! > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From eugene.chow.ct at gmail.com Wed Aug 12 05:39:42 2015 From: eugene.chow.ct at gmail.com (Eugene Chow) Date: Wed, 12 Aug 2015 17:39:42 +0800 Subject: [keycloak-user] JGRP000010 Version Mismatch errors from running in HA mode In-Reply-To: <998545072.9165927.1439366690052.JavaMail.zimbra@redhat.com> References: <998545072.9165927.1439366690052.JavaMail.zimbra@redhat.com> Message-ID: <4C9E7EDD-2FD7-4F83-9522-2119DA9C82CF@gmail.com> Hi Stian, You?re right. There?s an older instance of it running in another VM. The reported IP address misled me for a moment. Thanks! > On 12 Aug 2015, at 16:04, Stian Thorgersen wrote: > > If you only have 1 single instance running it should not be sending any packets at all. Are you sure there are no other Keycloak or WildFly instances on your network? > > ----- Original Message ----- >> From: "Eugene Chow" >> To: keycloak-user at lists.jboss.org >> Sent: Wednesday, 12 August, 2015 9:27:59 AM >> Subject: [keycloak-user] JGRP000010 Version Mismatch errors from running in HA mode >> >> Hi guys, >> >> I?m running a Keycloak cluster testbed and I keep getting this message even >> though only 1 instance of Keycloak is running in HA mode. The Keycloak >> instances are running in KVM containers on a single host machine. >> >>> 04:08:36,494 WARNING [org.jgroups.protocols.UDP] (Incoming-4,ee,keycloak1) >>> JGRP000010: packet from 192.168.122.1:1029 has different version (3.4.5) >>> than ours (3.6.4); packet is discarded >>> 07:16:46,508 WARNING [org.jgroups.protocols.UDP] (Incoming-2,ee,keycloak1) >>> JGRP000010: packet from 192.168.122.1:45688 has different version (3.4.5) >>> than ours (3.6.4); packet is discarded >> >> >> >> It seems like Keycloak/Infinispan is sending malformed (ie. version mismatch) >> multicast packets that it would reject. Is there a way to fix this? >> >> >> Thanks in advance! >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user From christopher.james.davies at gmail.com Wed Aug 12 12:56:14 2015 From: christopher.james.davies at gmail.com (Christopher Davies) Date: Wed, 12 Aug 2015 16:56:14 +0000 Subject: [keycloak-user] Direct Access to KeyCloak Message-ID: I am trying to write a test harness for out application which uses KeyCloak. In order to run my tests I need to manipulate KeyCloak. I am able to get data out of KeyCloak using the REST API. However I am unclear what I should send to KeyCloak to change a setting. I was trying to set the role for a user and wrote the script at the bottom of the email. I get back an error of org.codehaus.jackson.map.JsonMappingException: Can not deserialize instance of java.util.ArrayList out of START_OBJECT token at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 73cda37e; line: 1, column: 1] I have obviously missed a key point in the format of my data, but cannot see what it is. Chris --------------------------------------- #!/bin/bash host=192.168.10.221:8088 realm=ATS-ci t=$(curl -X POST http://${host}/auth/realms/${realm}/protocol/openid-connect/token --data "username=${1}" --data "password=${2}" --data "grant_type=password" --data "client_id=client" 2>/dev/null | jq -r ".id_token") client=$(curl http://${host}/auth/admin/realms/${realm}/clients -H "Accept: application/json" -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | select(.name == \"client\").id") user=$(curl http://${host}/auth/admin/realms/${realm}/users -H "Accept: application/json" -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | select(.username == \"${3}\").id") echo ${client} echo ${user} echo "Roles" curl http://${host}/auth/admin/realms/${realm}/clients/${client}/roles \ -H "Accept: application/json" \ -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | {id, name }" echo "" echo "Roles:${3}" curl http://${host}/auth/admin/realms/${realm}/users/${user}/role-mappings/clients/${client} \ -H "Accept: application/json" \ -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | {id, name }" curl http://${host}/auth/admin/realms/${realm}/users/${user}/role-mappings/clients/${client} \ -X POST \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "Authorization: Bearer ${t}" \ --data "{'realm': 'ATS-${realm}', 'id': '${user}', 'client': '${client}', '\$entity': [ 'operator' ] }" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150812/4b81ee41/attachment.html From mposolda at redhat.com Thu Aug 13 02:26:51 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 13 Aug 2015 08:26:51 +0200 Subject: [keycloak-user] Direct Access to KeyCloak In-Reply-To: References: Message-ID: <55CC38AB.8000400@redhat.com> Hi, I think you're supposed to send the list of roles (JSON array), but you're instead sending the object. I think the stuff like "realm", "id" and "client" is not needed in your last request, just send the list of roles instead. Btv. you can take a look at docs http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/clients/%7Bclient%7D/index.html#POST . What should help is also to install some plugin to decode requests to your browser (like Firebug in Firefox) and then do some actions in keycloak admin console (like assign some client role to some user) and then analyze how the request for assign roles should look like, what's the format of data etc. Admin console is angular application, which uses REST requests to admin REST API under the hood. Marek On 12.8.2015 18:56, Christopher Davies wrote: > I am trying to write a test harness for out application which uses > KeyCloak. > In order to run my tests I need to manipulate KeyCloak. > > I am able to get data out of KeyCloak using the REST API. However I am > unclear what I should send to KeyCloak to change a setting. > > I was trying to set the role for a user and wrote the script at the > bottom of the email. > > I get back an error of org.codehaus.jackson.map.JsonMappingException: > Can not deserialize instance of java.util.ArrayList out of > START_OBJECT token > at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 73cda37e; > line: 1, column: 1] > > I have obviously missed a key point in the format of my data, but > cannot see what it is. > > > Chris > > > > > --------------------------------------- > #!/bin/bash > > host=192.168.10.221:8088 > realm=ATS-ci > > > t=$(curl -X POST > http://${host}/auth/realms/${realm}/protocol/openid-connect/token > --data "username=${1}" --data "password=${2}" --data > "grant_type=password" --data "client_id=client" 2>/dev/null | jq -r > ".id_token") > > client=$(curl http://${host}/auth/admin/realms/${realm}/clients -H > "Accept: application/json" -H "Authorization: Bearer ${t}" 2>/dev/null > | jq -r ".[] | select(.name == \"client\").id") > user=$(curl http://${host}/auth/admin/realms/${realm}/users -H > "Accept: application/json" -H "Authorization: Bearer ${t}" 2>/dev/null > | jq -r ".[] | select(.username == \"${3}\").id") > > echo ${client} > echo ${user} > > echo "Roles" > curl http://${host}/auth/admin/realms/${realm}/clients/${client}/roles \ > -H "Accept: application/json" \ > -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | {id, name }" > > echo "" > echo "Roles:${3}" > curl > http://${host}/auth/admin/realms/${realm}/users/${user}/role-mappings/clients/${client} > \ > -H "Accept: application/json" \ > -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | {id, name }" > > > curl > http://${host}/auth/admin/realms/${realm}/users/${user}/role-mappings/clients/${client} > \ > -X POST \ > -H "Content-Type: application/json" \ > -H "Accept: application/json" \ > -H "Authorization: Bearer ${t}" \ > --data "{'realm': 'ATS-${realm}', 'id': '${user}', 'client': > '${client}', '\$entity': [ 'operator' ] }" > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150813/d2b7a111/attachment-0001.html From christopher.james.davies at gmail.com Thu Aug 13 02:42:05 2015 From: christopher.james.davies at gmail.com (Christopher Davies) Date: Thu, 13 Aug 2015 06:42:05 +0000 Subject: [keycloak-user] Direct Access to KeyCloak In-Reply-To: <55CC38AB.8000400@redhat.com> References: <55CC38AB.8000400@redhat.com> Message-ID: Thanks will try that. I can see how I got confused. More questions to cone ... However thanks for a fast response and a great product. On Thu, Aug 13, 2015 at 7:26 AM Marek Posolda wrote: > Hi, > > I think you're supposed to send the list of roles (JSON array), but you're > instead sending the object. I think the stuff like "realm", "id" and > "client" is not needed in your last request, just send the list of roles > instead. > > Btv. you can take a look at docs > http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/role-mappings/clients/%7Bclient%7D/index.html#POST > . What should help is also to install some plugin to decode requests to > your browser (like Firebug in Firefox) and then do some actions in keycloak > admin console (like assign some client role to some user) and then analyze > how the request for assign roles should look like, what's the format of > data etc. Admin console is angular application, which uses REST requests to > admin REST API under the hood. > > Marek > > > On 12.8.2015 18:56, Christopher Davies wrote: > > I am trying to write a test harness for out application which uses > KeyCloak. > In order to run my tests I need to manipulate KeyCloak. > > I am able to get data out of KeyCloak using the REST API. However I am > unclear what I should send to KeyCloak to change a setting. > > I was trying to set the role for a user and wrote the script at the bottom > of the email. > > I get back an error of org.codehaus.jackson.map.JsonMappingException: Can > not deserialize instance of java.util.ArrayList out of START_OBJECT token > at [Source: io.undertow.servlet.spec.ServletInputStreamImpl at 73cda37e; > line: 1, column: 1] > > I have obviously missed a key point in the format of my data, but cannot > see what it is. > > > Chris > > > > > --------------------------------------- > #!/bin/bash > > host=192.168.10.221:8088 > realm=ATS-ci > > > t=$(curl -X POST http://${host}/auth/realms/${realm}/protocol/openid-connect/token > --data "username=${1}" --data "password=${2}" --data "grant_type=password" > --data "client_id=client" 2>/dev/null | jq -r ".id_token") > > client=$(curl http://${host}/auth/admin/realms/${realm}/clients -H > "Accept: application/json" -H "Authorization: Bearer ${t}" 2>/dev/null | jq > -r ".[] | select(.name == \"client\").id") > user=$(curl http://${host}/auth/admin/realms/${realm}/users -H "Accept: > application/json" -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] > | select(.username == \"${3}\").id") > > echo ${client} > echo ${user} > > echo "Roles" > curl http://${host}/auth/admin/realms/${realm}/clients/${client}/roles \ > -H "Accept: application/json" \ > -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | {id, name }" > > echo "" > echo "Roles:${3}" > curl http://${host}/auth/admin/realms/${realm}/users/${user}/role-mappings/clients/${client} > \ > -H "Accept: application/json" \ > -H "Authorization: Bearer ${t}" 2>/dev/null | jq -r ".[] | {id, name }" > > > curl http://${host}/auth/admin/realms/${realm}/users/${user}/role-mappings/clients/${client} > \ > -X POST \ > -H "Content-Type: application/json" \ > -H "Accept: application/json" \ > -H "Authorization: Bearer ${t}" \ > --data "{'realm': 'ATS-${realm}', 'id': '${user}', 'client': '${client}', > '\$entity': [ 'operator' ] }" > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150813/be18d280/attachment.html From tristan.paddock at gmail.com Thu Aug 13 16:39:20 2015 From: tristan.paddock at gmail.com (Tristan Paddock) Date: Thu, 13 Aug 2015 16:39:20 -0400 Subject: [keycloak-user] User Federation Entity Manager Access Message-ID: Hi All, I am trying to write a custom User Federation to a RDBMS and would like to use an entity manager over straight JDBC. My code for creating a EntityManagerFactory takes a lot from DefaultJpaConnectionProviderFactory.java. The issue I am running into is that my persistance.xml (under META-INF of my jar) does not seem to be getting picked up. It appears to be picking up the persistence-unit from JpaConnection, but not mine. Does any one have thoughts on this or a sold strategy for creating an EntityManagerFactory in a custom User Federation? Thanks, Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150813/cefd6a40/attachment.html From ed.hillmann at gmail.com Thu Aug 13 21:28:12 2015 From: ed.hillmann at gmail.com (Ed Hillmann) Date: Fri, 14 Aug 2015 11:28:12 +1000 Subject: [keycloak-user] Keycloak working with Spring Boot / Spring Security OAuth? Message-ID: Hi. I am trying to get this sample application working against a local keycloak instance https://github.com/spring-cloud-samples/sso As I understand it, it's a Spring Boot application using Spring Security to support SSO. And I can't get it (as the client) to interact with the KeyCloak authentication server. If I just add the configuration for the Spring Boot adapter alone, it attempts to call out to KeyCloak but the url always includes a redirect_uri parameter, which Keycloak doesn't like and displays an error instead of a login screen. I've then tried to add, in addition to the Spring Boot configuration, the integration with Spring Security (the next section in the KeyCloak documentation). When I that, however, the server complains because it cannot find the keycloak.json file. Which isn't there because I've added the details to the application.yml file (as directed by the Spring Boot config) Is there some last step that I need to do to get these working? I'm new to Spring Boot. so I'm not sure I know how to step through it's configuration to see why it insists on sending the redirect_uri, and including Spring Security seems like a miss. Thanks for any help, Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150814/c39785ac/attachment.html From srossillo at smartling.com Thu Aug 13 22:30:46 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 13 Aug 2015 22:30:46 -0400 Subject: [keycloak-user] Keycloak working with Spring Boot / Spring Security OAuth? In-Reply-To: References: Message-ID: <13120048-E159-461D-A0C4-3E040423171F@smartling.com> Hi Ed, I?d recommend not using the Spring Boot adapter for now and sticking with the Spring Security adapter, even for Spring Boot apps. You?ll still need a keycloak.json file, which you can put in your src/main/resources folder. Here?s an repositories with examples of how to use Spring Security rules and run with Spring Boot: https://github.com/foo4u/keycloak-spring-demo Take a look at this configuration for a confidential app: https://github.com/foo4u/keycloak-spring-demo/blob/master/customer-app/src/main/java/org/keycloak/example/spring/customer/config/SecurityConfig.java Or this configuration for a bearer-only app: https://github.com/foo4u/keycloak-spring-demo/blob/master/database-service/src/main/java/org/keycloak/example/spring/config/SecurityConfig.java Hope that helps. We?ll try to align the Spring Boot module with the Spring Security module in the coming months. For now, the two modules are mutually exclusive. Ideally, the Spring Boot module would simply add sensible defaults and configuration via application config to the Spring Security adapter. Best, Scott > On Aug 13, 2015, at 9:28 PM, Ed Hillmann wrote: > > Hi. I am trying to get this sample application working against a local keycloak instance > > https://github.com/spring-cloud-samples/sso > > As I understand it, it's a Spring Boot application using Spring Security to support SSO. And I can't get it (as the client) to interact with the KeyCloak authentication server. > > If I just add the configuration for the Spring Boot adapter alone, it attempts to call out to KeyCloak but the url always includes a redirect_uri parameter, which Keycloak doesn't like and displays an error instead of a login screen. > > I've then tried to add, in addition to the Spring Boot configuration, the integration with Spring Security (the next section in the KeyCloak documentation). When I that, however, the server complains because it cannot find the keycloak.json file. Which isn't there because I've added the details to the application.yml file (as directed by the Spring Boot config) > > Is there some last step that I need to do to get these working? I'm new to Spring Boot. so I'm not sure I know how to step through it's configuration to see why it insists on sending the redirect_uri, and including Spring Security seems like a miss. > > Thanks for any help, > Ed > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150813/b2877f78/attachment-0001.html From ed.hillmann at gmail.com Thu Aug 13 22:39:44 2015 From: ed.hillmann at gmail.com (Ed Hillmann) Date: Fri, 14 Aug 2015 12:39:44 +1000 Subject: [keycloak-user] Keycloak working with Spring Boot / Spring Security OAuth? In-Reply-To: <13120048-E159-461D-A0C4-3E040423171F@smartling.com> References: <13120048-E159-461D-A0C4-3E040423171F@smartling.com> Message-ID: Thanks Scott. I'll give that a try. For the record, I progressed past that error by updating the application.yml to set useCurrentUri to false when defining the client configuration. But that just got me to the next error of too many redirects. So, I'll try using Spring Security on it's own for now. Thanks heaps for the help. Thanks again, Ed On Fri, Aug 14, 2015 at 12:30 PM, Scott Rossillo wrote: > Hi Ed, > > I?d recommend not using the Spring Boot adapter for now and sticking with > the Spring Security adapter, even for Spring Boot apps. You?ll still need a > keycloak.json file, which you can put in your src/main/resources folder. > > Here?s an repositories with examples of how to use Spring Security rules > and run with Spring Boot: > > https://github.com/foo4u/keycloak-spring-demo > > Take a look at this configuration for a confidential app: > > > https://github.com/foo4u/keycloak-spring-demo/blob/master/customer-app/src/main/java/org/keycloak/example/spring/customer/config/SecurityConfig.java > > Or this configuration for a bearer-only app: > > > https://github.com/foo4u/keycloak-spring-demo/blob/master/database-service/src/main/java/org/keycloak/example/spring/config/SecurityConfig.java > > Hope that helps. > > We?ll try to align the Spring Boot module with the Spring > Security module in the coming months. For now, the two modules are mutually > exclusive. Ideally, the Spring Boot module would simply add sensible > defaults and configuration via application config to the Spring Security > adapter. > > Best, > Scott > > > > > On Aug 13, 2015, at 9:28 PM, Ed Hillmann wrote: > > Hi. I am trying to get this sample application working against a local > keycloak instance > > https://github.com/spring-cloud-samples/sso > > As I understand it, it's a Spring Boot application using Spring Security > to support SSO. And I can't get it (as the client) to interact with the > KeyCloak authentication server. > > If I just add the configuration for the Spring Boot adapter alone, it > attempts to call out to KeyCloak but the url always includes a redirect_uri > parameter, which Keycloak doesn't like and displays an error instead of a > login screen. > > I've then tried to add, in addition to the Spring Boot configuration, the > integration with Spring Security (the next section in the KeyCloak > documentation). When I that, however, the server complains because it > cannot find the keycloak.json file. Which isn't there because I've added > the details to the application.yml file (as directed by the Spring Boot > config) > > Is there some last step that I need to do to get these working? I'm new > to Spring Boot. so I'm not sure I know how to step through it's > configuration to see why it insists on sending the redirect_uri, and > including Spring Security seems like a miss. > > Thanks for any help, > Ed > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150814/deb7043c/attachment.html From davidillsley at gmail.com Fri Aug 14 03:42:44 2015 From: davidillsley at gmail.com (David Illsley) Date: Fri, 14 Aug 2015 08:42:44 +0100 Subject: [keycloak-user] Would like to deprecate/remove JPA/Mongo UserSessions In-Reply-To: <55C0EEE0.9050307@redhat.com> References: <55C0EEE0.9050307@redhat.com> Message-ID: I'd really like to be able to run Keycloak without relying on JavaEE style clustering, and instead rely on modern 12-factor approaches. I was planning to do that by implementing a bunch of interfaces to use redis rather than JPA/Mongo/Infinispan, so I'm keen that you don't tie things too tightly to infinispan (not that I think you would. infinispan and redis effectively provide simple key/value stores). On Tue, Aug 4, 2015 at 5:57 PM, Bill Burke